Page History

...

1. CloudStack relies on physical network traffic label of specific traffic to learn the physical network end point of configuration for virtual networks carrying that traffic. Physical network traffic label of each traffic supported by CloudStack can be specified while creating physical network in CloudStack zone. CloudStack uses the physical network end point of specific traffic type, whenever a virtual network of respective traffic type has to be implemented.
2. Hence to support a specific traffic over dvSwitch as network backend, all CloudStack needs to know is the physical network end point of configuration, i.e. name of dvSwitch itself. Here's a how general network entities map to virtual network entities in VMware environment,
   1. Physical NIC(s) ~ dvSwitch
   2. Virtual network ~ dvPortGroup
   3. Virtual NIC ~ dvPort
3. To support management and/or storage traffic over dvSwitch, CloudStack does following,
   1. Reads physical network traffic labels to understand the designated dvSwitch(es). VmwareResource does necessary create or update operation over dvSwitch.
   2. The traffic label information is passed down to VmwareResource as part of NicTO object while executing following Commands.
      1. StartCommand
      2. PlugNicCommand
      3. PrepareForMigrationCommand
      4. MigrationWithStorageCommand
   3. In VmwareResource, from NicTo object, following data members would be fetched,Type of traffic of the virtual network to which vNIC needs to be connected to.
   4. Name of physical network (the traffic label itself)
   In VmwareResource, the method getTargetSwitch would parse the traffic label as from NicTo object as per traffic label format specified below.
   5. In VmwareResource, dvPortGroup (analogous to CloudStack virtual network) would be created over dvSwitch which is obtained by parsing the traffic label fetched in above step.
4. For management and storage traffics the traffic label format is ["Name of vSwitch/dvSwitch"[,"VLAN ID"[,"vSwitch Type"]]]
   1. In the traffic label all the 3 fields are optional.
   2. 1st field (highlighted in blue) - Represents the name of virtual/distributed virtual switch at vCenter. The default value assumed would depend upon the type of virtual switch. Defaults values are as follows.
      1. "vSwitch0" if type of virtual switch is "VMware vNetwork Standard virtual switch"
      2. "dvSwitch0" if type of virtual switch is "VMware vNetwork distributed virtual switch"
   3. 2nd field ((highlighted in green) - VLAN ID to be used for this traffic where ever applicable.
      1. By default empty string would be assumed which translates to untagged VLAN for that specific traffic type.
   4. 3rd field (highlighted in red)- Type of virtual switch specified as string. Possible valid values are vmwaredvs, vmwaresvs. Each translates as follows.
      1. "vmwaresvs" represents "VMware vNetwork Standard virtual switch"
      2. "vmwaredvs" represents "VMware vNetwork distributed virtual switch"
      3. If nothing is specified (left empty) then standard vSwitch would be assumed unless global configuration parameter "vmware.use.dvswitch" is set to "true". By default this parameter is set to false
   5. As per above mentioned format, furnishing few possible values for network label,
      1. "" (empty string)
      2. dvSwitch0
      3. dvSwitch0,200
      4. dvSwitch0,300,vmwaredvs
      5. dvSwitch0,,vmwaredvs
      6. vmwaredvs" represents "VMware vNetwork virtual switch.
   6. Port binding would be of type static
   7. CloudStack creates dvPortGroup with "AutoExpand" enabled such that required number dvPorts are allocated/de-allocated automatically increment/decrement of dvPorts This ensures that we don't pre-allocate unnecessary dvPorts for better resource utilization.
   8. Packages that encapsulates the code changes required by this feature are,
      
      1. cloud-core package (VmwareManager, VmwareResource)
      2. clloud-server package
      3. cloud-plugins-hypervisor-vmware-base package (for mo and util packages)
   9. The scenarios to be covered during developer testing are,
      1. Adding host/compute resource to podcluster.
      2. Create necessary CloudStack managed virtual networks on designated dvSwitch
      3. Deploy/movement of systemvms.
      4. All systemvm life cycle operations which might need orchestration of management/storage network.

...