Page History

...

• 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 migrating a volume from one storage pool to another, only the shared storage pools within the cluster should be listed.
• 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.
• 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.

Negative

• functional
• non functional: performance, scalability, stability, overload scenarios, etc
• corner cases and boundary conditions
negative usage scenarios
• specify supportability 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
  • graceful failure and recovery scenarios
  • possible fallback or work around route if feature does not work as expected, if those workarounds do exist ofcourse.
  • if feature depends other run-time environment related requirements, provide sanity check list for support people to run
• explain configuration characteristics:
  • configuration parameters or files introduced/changed
  • branding parameters or files introduced/changed
  • highlight parameters for performance tweaking
  • highlight how installation/upgrade scenarios change
• deployment requirements (fresh install vs. upgrade) if any
• system requirements: memory, CPU, desk space, etc
• interoperability and compatibility requirements:
  • OS
  • xenserver, hypervisors
  • storage, networks, other
• list localization and internationalization specifications 
• explain the impact and possible upgrade/migration solution introduced by the feature 
• explain performance & scalability implications when feature is used from small scale to large scale
• explain levels or types of users communities of this feature (e.g. admin, user, etc)

Use cases

No new apis have been 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.put the relevant use case/stories to explain how the feature is going to be used/work

Architecture and Design description

...