Page History

...

• quality risks (test guidelines)
  • functional*
• * Live migration of VM
• * Deployment of virtual router
• * Deployment of VM
  • non functional: performance, scalability, stability, overload scenarios, etc*
• * Large number of VMs and isolated networks need to be tested for performance specific results.
• negative usage scenarios - NA
• what are the audit events *
  • All virtul network orchestration events
  • VM migration events
  • 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 some guest network doesn't work correctly or if CloudStack fails to create guest network required by a VM then administrator can (re)configure dvPortGroup in relation to respective network in CloudStack.
• * If guest network instantiation fails to due to lack of network resources, then administrator is expected to ensure that more resources/capacity employed. E.g. If number of dvPorts in a dvPortGroup get exhausted, that results in a situation that no more VM can join that network. Hence administrator can go ahead and re-configure dvPortGroup to increase the number of dvPorts to accommodate more VMs in that guest network. This is applicable to vSphere 4.1 only. Because from vSphere 5.0 onwards, there is auto expand support, so that automatic provisioning of dvPorts takes place as required.
• * If many dvPortGroups are created and cleanup doesn't happen as expected, then administrator needs to check for unused dvPortGroups on dvSwitch and do clean up using vCenter UI.

• • if feature depends on other run-time environment related requirements, provide sanity check list for support people to run
• # 1. Basic sanity testing over dvSwitch can be done. It might be ping operation from one VM to another VM in the same network. Make sure VLAN configuration is done in that network and verify isolation is achived or not.
• # 2. Verify if traffic shaping policy configured is applied and working.

...