cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srikanteswararao Talluri <srikanteswararao.tall...@citrix.com>
Subject RE: ReviewRequest: Storage XenMotion Test Plan
Date Tue, 23 Apr 2013 05:39:26 GMT
See my comments inline
> -----Original Message-----
> From: Devdeep Singh
> Sent: Monday, April 22, 2013 1:56 PM
> To: dev@cloudstack.apache.org; Srikanteswararao Talluri
> Subject: RE: ReviewRequest: Storage XenMotion Test Plan
> 
> 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].

Updated test plan with updated API names.

> 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?
My intention was to use offerings with same tags on destination as source cluster but parameters
not matching.
> 5. Test case 17 (SXM_VM_migrate_dest_SR_not_available). Can you elaborate
> more on this scenario?
I realized now that if suitable SR(shared) is not available on the destination 'findStoragePoolsForMigration'
 
will actually return empty response. I'll modify the test as applicable.

> 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.
Same as above comment, I thought if the findHostsForMigration API  returns XS6.0.2 host.
I need to figure out how do I test this scenario.
> 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.
> 
Modified
I'll split  the test cases 
> 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