See my comments inline > -----Original Message----- > From: Devdeep Singh > Sent: Monday, April 22, 2013 1:56 PM > To: [email protected]; 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: [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
