Page History

...

• dvSwitch / vDS - VMware vNetwork Distributed Virtual Switch.
• vSwitch - VMware vNetwork Standard Virtual Switch.
• dvPort - Distributed Virtual Port (member of dvPortGroup).
• dvPortGroup - Distributed Virtual Port Group

Feature Specifications

• *This feature enables VMware distributed vSwitch in CloudStack to configure and manage virtual networks over dvSwitch instances in datacenter of the managed cluster.
  *list what is deliberately not supported or what the feature will not offer - to clear any prospective ambiguities
• PVLANs
User-defined resource pools

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)

• 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.
• explain configuration characteristics:
  • configuration parameters or files introduced/changed
    New configuration parameter - "vmware.use.dvswitch" of type Boolean. Possible values are "true" or "false". Default value is "false".
  • branding parameters or files introduced/changed - NA
  • highlight parameters for performance tweaking - NA
  • highlight how installation/upgrade scenarios change
• deployment requirements (fresh install vs. upgrade) if any
  • VMware dvSwitch must be already created/configured in the vCenter datacenter deployment.
  • All the host/clusterresources should be added to dvSwitch before adding the cluster to CloudStack's pod cluster.

...

CloudStack reads physical traffic labels to understand the designated virtual switches to use for virtual network orchestration. Also virtual switch type is added to existing list of custom properties of cluster to enable a cluster level override option for virtual switch type. A cluster level option would precede over virtual switch type specified in zone level physical traffic label.

...

1. 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)
2. Highlight architectural patterns being used (queues, async/sync, state machines, etc) - N/A
3. Talk about main algorithms used
   1. Isolated network configuration using VLAN over dvSwitch. CloudStack manages dvPortGroup configured with a designated VLAN ID.
   2. The scenarios to be covered are,
      1. Adding host/compute resource to podcluster. Create necessary cloudstack managed virtual networks on designated dvSwitch.
      2. Livemigration
      3. All VM life cycle operations which might need instantiation of guest network etc.
      4. Network operations like network creation, network destroy etc.
4. Port binding would be static binding.
5. Performance implications: what are the improvements or risks introduced to capacity, response time, resources usage and other relevant KPIs•In vSphere 5.0, we will use "AutoExpand" support to configure dvPorts per dvPortGroup. This ensures that we don't pre-allocate unnecessary dvPorts so that they
6. Packages that encapsulates the code changes,
   ##core
   1. core package (VmwareManager, VmwareResource)
   ##server
   1. server package
   ##vmware
   1. vmware-base package mo and util packages

   Web Services APIs

   Changes to existing web services APIs - AddClusterCmd
   Adding an optional parameter named 'virtulSwitchType' which can have values 'vmwaresvs' or 'vmwaredvs' or 'nexusdvs'.
   New APIs introduced - N/A

   ...