Page History

...

1. CloudStack does following,
   1. Create dvPortGroup over designated dvSwitch
   2. Modify dvPortGroup over designated dvSwitch
   3. Delete dvPortGroup over designated dvSwitch
2. CloudStack doesn't do following,
   1. Create dvSwitch
   2. Add host to dvSwitch
   3. Dynamic migration of virtual adapters of existing VMs across differnt types of virtual switches in scenarios in which co-existance of multiple types of virtual switches (Cisco's Nexus 1000v or VMware standard vSwitch and dvSwitch) is possible. Instead this is left to administrator to decide.
   4. Configuration of PVLAN
   5. Configuration dvPort mirror
   6. Configuration of user defined network resource pools for Network I/O Control (NIOC)
3. quality risks (test guidelines)
   1. functional
      1. Live migration of VM
      2. Deployment of virtual router
      3. Deployment of VM
   2. non functional: performance, scalability, stability, overload scenarios, etc
      1. Large number of VMs and isolated networks need to be tested for performance specific results.
         negative usage scenarios - NA
4. what are the audit events  *
   1. All virtul network orchestration events
   2. VM migration events
5. graceful failure and recovery scenarios
6. possible fallback or work around route if feature does not work as expected, if those workarounds do exist ofcourse.
   1. 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.
   2. 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.
   3. 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.
7. 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.
8. explain Explain configuration characteristics:
   1. configuration Cconfiguration parameters or files introduced/changed
      ###New configuration parameter - "vmware.use.dvswitch" of type Boolean. Possible values are "true" or "false". Default value is "false".
9. branding Branding parameters or files introduced/changed - NA
10. highlight Highlight parameters for performance tweaking - NA
11. highlight Highlight how installation/upgrade scenarios change
12. deployment requirements (fresh install vs. upgrade) if any
    1. VMware dvSwitch must be already created/configured in the vCenter datacenter deployment.
    2. All the host/clusterresources should be added to dvSwitch before adding the cluster to CloudStack's pod cluster.
13. interoperability Interoperability and compatibility requirements:
    1. Hypervisors - VMware vSphere 4.1 or later
14. list List localization and internationalization specifications 
    1. UI changes in "Add Cluster" wizard. See the section "UI Flow".
15. explain Explain the impact and possible upgrade/migration solution introduced by the feature 
16. explain Explain performance & scalability implications when feature is used from small scale to large scale
    1. In case of vSphere 4.1 dvPortGroup need to be created with specific number of dvPorts. In large scale deployment optimum use of dvPorts may not be possible due to this pre-allocation. In case of vSphere 5.0 the autoexpand feature helps in auto increment of number of dvPorts.
    2. Network switches (including the vSwitch in ESXi host) keep a distinct forwarding table for each VLAN; this could lead to an increased overhead in packet forwarding when a considerable number of isolated networks, each one with a significant number of virtual machines, is configured in a data centre.
17. explain Explain marketing specifications
    1. Supporting VMware dvSwitch entitle CloudStack
    2. For better monitoring and simpler administration of the virtual network infrastructure in Cloud.
    3. Configuration and management of several vSwitches across large deployments in tedious.
    4. Seamless network vMotion support
    5. Better traffic shaping and efficient network bandwidth utilization is possible.
18. explain Explain levels or types of users communities of this feature (e.g. admin, user, etc)
    1. admin - Administrators would be target audience for this feature as this is at infrastructure level.

...