Page History

...

1. Highlight architectural patterns being used (queues, async/sync, state machines, etc) - N/A
2. Traffic label format is ["Name of vSwitch/dvSwitch/EthernetPortProfile"[,"VLAN ID"[,"vSwitch Type"]]]
   1. Description
   2. All the 3 fields are optional
   3. Default values for the 3 fields are as below
      1. 1st field - 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. epp0 if type of virtual switch is "Cisco Nexus 1000v distributed virtual switch"
      2. 2nd field - VLAN ID to be used for this traffic where ever applicable. This field would be used for only public traffic as of now. In case of guest traffic this field would be ignored and could be left empty for guest traffic.
         1. By default empty string would be assumed which translates to untagged VLAN for that specific traffic type.
      3. 3rd field - Type of virtual switch specified as string. Possible valid values are vmwaredvs, vmwaresvs, nexusdvs. Each translates as follows.
         1. "vmwaresvs" represents "VMware vNetwork Standard virtual switch"
         2. "vmwaredvs" represents "VMware vNetwork distributed virtual switch"
         3. "nexusdvs" represents "Cisco Nexus 1000v distributed virtual switch"
         4. If nothing is specified (left empty) that means zone level default virtual switch (based on value of global parameters) would be assumed. Following are the global configuration parameters.
            1. vmware.use.dvswitch - This should be true to enable any kind (VMware DVS / Cisco Nexus 1000v DVS) of distributed virtual switch in cloudstack deployment. If this is false that means default virtual switch in that cloudstack deployment is "standard virtual switch" only.
            2. vmware.use.nexus.vswitch - This parameter would be ignored unless "vmware.use.dvswitch" is true. Set this to "true" to enable Cisco Nexus 1000v distributed virtual switch in a cloudstack deployment.
   4. As per above mentioned format, furnishing few possible values for networkLabel,
      1. "" (empty string)
      2. dvSwitch0
      3. dvSwitch0,200
      4. dvSwitch0,300,vmwaredvs
      5. myEthernetPortProfile,,nexusdvs
      6. dvSwitch0,,vmwaredvs

1. 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.
2. Port binding would be static binding.
3. 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
4. Packages that encapsulates the code changes,
   1. core package (VmwareManager, VmwareResource)
   2. server package
   3. vmware-base package mo and util packages

...