Storage motion for Hyper-V

Bug Reference

CLOUDSTACK-6143

Branch

4.4, master

Introduction

Hyper-V 2012 R2 allows migration of volumes (virtual disks) of a virtual machine from one storage to another, while the virtual machine continues to run. It also allows live migration of a virtual machine and its volumes to another host and storage without any downtime.

The intend of this feature is to enable support of live migration of a virtual machines with its volumes across hosts and storage pools. It'll also migration of volumes across storage pools while the volume stays attached to a running virtual machine.

Purpose

This is a feature specification for supporting storage motion on Hyper-V.

References

• Storage motion in cloudstack
• http://blogs.technet.com/b/canitpro/archive/2013/03/21/step-by-step-completing-storage-live-migration-in-hyper-v.aspx
• http://msdn.microsoft.com/en-us/library/hh850079(v=vs.85).aspx

Document History

Glossary

Instance/vm - Virtual machine running on a hypervisor. The terms may be used interchangeably.

Live migration - Migrating a vm from one host to another without any downtime of the vm,

Volume live migration - Migrating a volume of a vm from one storage pool to another without any downtime of the vm.

Feature Specifications

Scenarios

Storage motion operations can only carried out by a CloudStack root administrator. Summary of the operations that storage motion will allow on Hyper-V

• Scenario 1: Live migrating volume of a virtual machine. Virtual machine stays running on the same host.
  
  • A volume deployed on a local storage cannot be migrated to another storage pool. The volume has been created with a 'Disk Offering' as local. It can only reside on a local storage pool. Since the volume is attached to a running vm and is on a local storage it cannot be live migrated to another local storage pool on another host.

  • A volume on a cluster wide shared storage can be migrated to a another cluster wide shared storage within the same CloudStack cluster.
    
    Following table summarizes the scenario

    	Destination Storage type = Local	Destination Storage type = Shared
    Source Storage type = Local	No	No
    Source Storage type = Shared	No	Yes

• Scenario 2: Live migrating a virtual machine with its volumes to another host and storage pool respectively.
  • A vm with its volumes on a local storage storage can be live migrated to another host which has local storage attached. The volume of the vm will be placed on the local storage on the destination host. The host may be within the cluster or in another cluster.
  • A vm with its volumes on a shared storage can be live migrated to another host which a shared storage pool attached to it. The host may be within the cluster or in another cluster.

  • A vm with volumes on both shared and local storage can be live migrated to another host if the destination host has access to both shared and local storage. Source volumes on shared storage will be migrated to shared storage accessible on the destination. Similarly, volumes on local storage will be migrated to local storage on the destination.
    
    Following table summarizes the scenario

    	Destination Storage type = Local	Destination Storage type = Shared
    Source Storage type = Local	Yes	No
    Source Storage type = Shared	No	Yes

    
    

• Unsupported Scenario: A volume on a local storage cannot be live migrated to a volume of shared storage. A volume on local storage is created by a disk offering of  type "Local". Migrating it to a shared storage will conflict with the disk offering. The same applies to not allowing migration of a volume from shared to local storage.

Test Guidelines

Functional

• For live migrating a volume from one storage pool to another, only the shared storage pools within the cluster should be listed.
• If storage tags were used in disk offerings, findStoragePoolsForMigration api should return the storage pools with matching tags as suitable. Other shared storage pools in the cluster should be marked unsuitable.
• Instance with one volume (only Root volume). Migrate volume of an instance from one shared storage pool to another within the cluster. At the end of the operation the volume should be on the destination pool and path updated in the db.
• Instance with multiple volumes (Root and Data volumes). Migrate one volume from one shared storage pool to another. At the end of the operation the volume should be on the destination pool and path updated in the db.
• Live migrating a virtual machine with its volumes, findHostsForMigration should return the list of hosts within the cluster and across cluster to which the vm can be migrated with volumes. The 'requiresStorageMotion' attribute should be set to true in the response.
• If host tags were used in service offering, findHostsForMigration api should return the hosts with matching tags as suitable. Other hosts should be marked as unsuitable.
• Migrate a vm from one host to another (migrateVirtualMachineWithVolume api) that do not have access to the same shared storage. Do not give a volume to pool mapping; that is, do not specify in the api which volume should be placed on which pool. The vm should be successfully live migrated with its volumes. The volumes created with shared disk offering should be placed on a shared storage pool and volumes with local disk offering placed on local storage pool.
• Validate that when a volume to pool mapping is given in migrateVirtualMachineWithVolume api, the volumes of a vm are placed on the given pool id.

Negative

• While migrating a virtual machine with a volume, gave an invalid volume to pool mapping; that is give a mapping for migrating a volume from shared to local or vice-verse. The operation should fail.
• Try live migrating a volume of a vm on a local storage. It should not be allowed.
• Live volume migration or live virtual machine migration with volume is a time consuming operation. When migration is going on, take the destination storage pool offline. Migration should fail and vm and its volume should be retained on the source host and storage pool respectively.

Support-ability Characteristics

• • what new logging (or at least the important one) is introduced
  • how to debug and troubleshoot
  • what are the audit events 
  • list JMX interfaces

Configuration Characteristics

• By default a Hyper-V host allows only 2 simultaneous storage migration requests. The configuration parameter may be configured on a hyper-v host to a higher or lower value; but it is recommended to not to do so.
• After a request is forwarded to a resource; the agent will wait for "wait" *2 (global config parameter) seconds for the request to complete. Storage motion can take a long time and may not complete in "wait" *2 seconds. The global config parameter "wait" can be configured if that is the case.

Users Communities

• Only a root admin can migrate a volume from one storage pool to another.
• Only a root admin can migration a virtual machine with its volume.

Use cases

Architecture and Design description

Web Services APIs

No new apis are added for this feature. Existing apis; explained in Storage motion in cloudstack; will enable storage motion for Hyper-V too. List of apis used for storage motion

• findStoragePoolsForMigration. For listing the suitable storage pools to which a volume of a vm can be live migrated too.
• migrateVolume. For live migrating a volume of a vm to another storage pool. 'livemigrate' parameter to the api should be true.
• findHostsForMigration. For listing the suitable hosts to which a vm can be live migrated along with its volumes. In the response object; HostForMigrationResponse; 'requiresStorageMotion' attribute/flag is set to 'true' if migrating the vm the host requires storage motion.
• migrateVirtualMachineWithVolume. For live migrating a vm with its volumes to a host.

Since these are existing apis; they are not explained here. Please refer to Storage motion in cloudstack for api details.

UI flow

• either demonstrate it visually here or link to relevant mockups

IP Clearance

No IP dependencies are introduced by this feature.

Appendix

Appendix A:

Appendix B: