Hi, Some review comments on the test plan.
1. The listHostsForMigration and listStoragePoolsForMigration apis have been renamed to findHostsForMigration and findStoragePoolsForMigration. The updated FS has these details. This was done to address the review comments shared here [1]. 2. Test case 7 (SXM_VM_migrate_sameSR). For migrating a vm without its volumes the existing migrateVirtualMachine api has to be used. If migrateVmWithVolume is called to migrate a vm and it doesn't require storage motion, the api will report an error. 3. Test case 15 (SXM_VM_operations_while_migration). When a vm is migrating other operations like stopping the vm etc. shouldn't be allowed on it. 4. Test case 16 (SXM_VM_migrate_src_dest_diff_offerings). Can you clarify what do you mean by different offerings on the destination? 5. Test case 17 (SXM_VM_migrate_dest_SR_not_available). Can you elaborate more on this scenario? 6. Test case 20 (SXM_VM_migrate_dest_xs6.0.2_host_listHostsForMigration). Just FYI/clarification, the findHostsForMigration shouldn't return a 6.0.2 xenserver host to be suitable for storage motion. If migrateVmWithVolume is called giving a 6.0.2 host as destination, the api should report an error saying the destination is unsuitable for storage motion. 7. Suggestion, instead of using the term resource pool in the test cases, should we use the term cluster as it is more relevant to cloudstack. Some additional test cases to consider. These add more details to what test cases 10, 11, 12 and 13 should test. findHostsForMigration api. 1. A vm is created with an offering which uses host tags and it gets deployed on a host with an appropriate tag. Hosts that are available for migration are listed using the api. Only the hosts that have an appropriate (matching) tag get listed as suitable. 2. The above test case can be extended to verify that if a vm is created using an offering that doesn't have any tags, only the hosts that have not been tagged should be listed as suitable. 3. When hosts are listed for migration, if migration to a hosts requires moving the volumes of a vm; the requiresstoragemotion flag in the response should be true. 4. Create a vm and attach a disk to it created using a disk offering that requires local storage. A host that doesn't have storage pool of type local attached to it, shouldn't be listed. migrateVirtualMachineWithVolume api. 1. If only the vmid and destination are passed as parameters, appropriate pools are picked up for each volume of the vm. If there isn't an appropriate pool available migration fails and it is reported and logged. Examples of why an appropriate pool isn't available, the tags on the disk offering with which a volume is created doesn't match the storage pools available on the destination host. A volume may have been created with shared or local disk offering and such a storage pool isn't available on the destination host. 2. Adding to the above test case, each volume should be placed on a storage pool with which the tags and type (shared/local) match. 3. 'migrateto' option parameter (volume to pool mapping) is passed. If any of the storage pools aren't available on the destination host, a failure is reported and logged. 4. 'migrateto' option parameter (volume to pool mapping) is passed. If the tags on the destination storage pool do not match the disk offering with which a volume is created; migration is allowed. 5. 'migrateto' option parameter (volume to pool mapping) is passed. If the type (shared/local) of the destination storage pool do not match the disk offering with which a volume is created; migration fails and is reported and logged. 6. Verify when migration of vm with its volumes is taking place, the vm and the volumes being migrated are placed in migrating state. 7. If any of volumes of the vm that has to be migrated is not in ready state; e.g,. snapshot in progress; migration isn't initiated and reported. 8. Take a snapshot of a volume of a vm. Migrate the vm along with its volumes. Try taking a snapshot of the volume again. It should be successful. findStorgePoolsForMigration api. 1. If a volume is created using a disk offering requiring a local storage, the api should return an empty set. A volume on local storage cannot be migrated while the vm continues to run on the same host. 2. If a volume has been created using a disk offering requiring certain tags on the volume, the storage pools that do not have the right tags are reported as unsuitable. A storage pool that has the right tags is reported as suitable. The same applies to a volume created with a disk offering with no tags. migrateVolume api. 1. migration of a volume to a storage pool with which the tags do not match is allowed. 2. migration of a volume to a storage pool with which the type (shared/local) do not match is not allowed and is reported and logged. 3. Take snapshots of a volume. Migrate the volume to another storage pool. Try taking snapshots of the volume again. It should be successful. [1] http://permalink.gmane.org/gmane.comp.apache.cloudstack.devel/20365 Regards, Devdeep From: Srikanteswararao Talluri Sent: Friday, April 19, 2013 4:46 PM To: [email protected] Cc: Devdeep Singh Subject: ReviewRequest: Storage XenMotion Test Plan Please review the test plan for Storage XenMotion and post your comments if any. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Xenmotion+Test+Plan Thanks, ~Talluri
