cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Devdeep Singh <devdeep.si...@citrix.com>
Subject RE: ReviewRequest: Storage XenMotion Test Plan
Date Mon, 22 Apr 2013 08:26:28 GMT
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: dev@cloudstack.apache.org
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

Mime
View raw message