rafaelweingartner commented on a change in pull request #2997: Allow KVM VM 
live migration with ROOT volume on file storage type
URL: https://github.com/apache/cloudstack/pull/2997#discussion_r232024215
 
 

 ##########
 File path: 
engine/storage/datamotion/src/main/java/org/apache/cloudstack/storage/motion/KvmNonManagedStorageDataMotionStrategy.java
 ##########
 @@ -0,0 +1,142 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+package org.apache.cloudstack.storage.motion;
+
+import java.util.Map;
+import java.util.Set;
+
+import javax.inject.Inject;
+
+import org.apache.cloudstack.engine.subsystem.api.storage.DataStore;
+import org.apache.cloudstack.engine.subsystem.api.storage.StrategyPriority;
+import org.apache.cloudstack.engine.subsystem.api.storage.TemplateDataFactory;
+import org.apache.cloudstack.engine.subsystem.api.storage.TemplateInfo;
+import org.apache.cloudstack.engine.subsystem.api.storage.VolumeInfo;
+import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
+import org.apache.commons.lang.StringUtils;
+import org.springframework.stereotype.Component;
+
+import com.cloud.agent.api.Answer;
+import com.cloud.agent.api.MigrateCommand;
+import com.cloud.agent.api.MigrateCommand.MigrateDiskInfo;
+import com.cloud.agent.api.storage.CreateAnswer;
+import com.cloud.agent.api.storage.CreateCommand;
+import com.cloud.agent.api.to.VirtualMachineTO;
+import com.cloud.host.Host;
+import com.cloud.hypervisor.Hypervisor.HypervisorType;
+import com.cloud.storage.DataStoreRole;
+import com.cloud.storage.DiskOfferingVO;
+import com.cloud.storage.Storage.StoragePoolType;
+import com.cloud.storage.VolumeVO;
+import com.cloud.utils.exception.CloudRuntimeException;
+import com.cloud.vm.DiskProfile;
+
+/**
+ * Extends {@link StorageSystemDataMotionStrategy}, allowing KVM hosts to 
migrate VMs with the ROOT volume on a non managed local storage pool.
+ * As {@link StorageSystemDataMotionStrategy} is considering KVM, this 
implementation also migrates only from/to KVM hosts.
+ */
+@Component
+public class KvmNonManagedStorageDataMotionStrategy extends 
StorageSystemDataMotionStrategy {
+
+    @Inject
+    private TemplateDataFactory tmplFactory;
+
+    /**
+     * Uses the canHandle from the Super class {@link 
StorageSystemDataMotionStrategy}. If the storage pool is of file and the 
internalCanHandle from {@link StorageSystemDataMotionStrategy} CANT_HANDLE, 
returns the HIGHEST strategy priority. otherwise returns CANT_HANDLE.
+     * Note that the super implementation (overrided) is called by {@link 
#canHandle(Map, Host, Host)} which ensures that {@link #internalCanHandle(Map)} 
will be executed only if the source host is KVM.
+     */
+    @Override
+    protected StrategyPriority internalCanHandle(Map<VolumeInfo, DataStore> 
volumeMap) {
+        if (super.internalCanHandle(volumeMap) == 
StrategyPriority.CANT_HANDLE) {
+            Set<VolumeInfo> volumeInfoSet = volumeMap.keySet();
+
+            for (VolumeInfo volumeInfo : volumeInfoSet) {
+                StoragePoolVO storagePoolVO = 
_storagePoolDao.findById(volumeInfo.getPoolId());
+                if (storagePoolVO.getPoolType() != StoragePoolType.Filesystem) 
{
 
 Review comment:
   Are you sure that it will not work? 
   
   I mean, the XML that described the VM, and that is going to be used in the 
target host will have an entry for a disk that is in a shared volume. 
Therefore, as long as that volume is connected to the host, you should be good 
to go. That is the tricky you are doing here right, because you are dealing 
with local storage, you will need to first move/declare the volume in the 
target host, and then execute a migration command that will take care of the 
"copy/paste" of the local disks contents in the target host.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to