----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9189/#review16085 -----------------------------------------------------------
plugins/hypervisors/vmware/src/com/cloud/network/VmwareTrafficLabel.java <https://reviews.apache.org/r/9189/#comment34403> Based on the options that you have provided, parseLabel() (remove _ from method name) will handle cases 4 & 5, what about 1, 2, 3. [1] "" [2] "Name of vSwitch/dvSwitch" [3] "Name of vSwitch/dvSwitch","VLAN ID" [4] "Name of vSwitch/dvSwitch","VLAN ID","vSwitch Type" - Example: dvSwitch0,100,vmwaredvs [5] "Name of vSwitch/dvSwitch",,"vSwitch Type" - Example: dvSwitch0,,vmwaredvs The way you are handling networkLabel doesn't match the description you have provided - Koushik Das On Feb. 5, 2013, 4:09 a.m., Sateesh Chodapuneedi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/9189/ > ----------------------------------------------------------- > > (Updated Feb. 5, 2013, 4:09 a.m.) > > > Review request for cloudstack, Murali Reddy and Kelven Yang. > > > Description > ------- > > This is 1st patch for feature 'Support for VMware dvSwitch in CloudStack'. > This contains 3 newly introduced classes. Added apache license header for all > 3 files. > [1]TrafficLable and [2]VmwareTrafficLabel classes are to define and > encapsulate virtual switch type per traffic type along with other network > label fields (VLAN ID and physical network). > [3]DistributedVirtualSwitchMO class is wrapper class for vSphere API calls > specific to a distributed virtual switch in a vCenter datacenter. > Feature highlights: > Virtual switch type could be chosen at zone level or at cluster level for > specific traffic type. All virtual network orchestration would use the > specified virtual switch. So far CloudStack could use only vSwitch of type > standard vSwitch, with this feature CloudStack can use VMware dvSwitch as > well. Support for VMware dvSwitch is available for guest and public traffic > types. > autoExpand of dvPortGroup is available in code but disabled as its breaking > because vCenter 4.1 does not support autoExpand feature. > > > This addresses bug CLOUDSTACK-657. > > > Diffs > ----- > > api/src/com/cloud/network/TrafficLabel.java PRE-CREATION > plugins/hypervisors/vmware/src/com/cloud/network/VmwareTrafficLabel.java > PRE-CREATION > > vmware-base/src/com/cloud/hypervisor/vmware/mo/DistributedVirtualSwitchMO.java > PRE-CREATION > > Diff: https://reviews.apache.org/r/9189/diff/ > > > Testing > ------- > > Manual testing:- > 1) Tested guest traffic over dvSwitch on a dedicated physical network. In > this case management and public traffic uses standard vSwitch on a common > physical network. > 2) Tested both guest traffic and public traffic over dvSwitch on a physical > network. > 3) Use optional parameters added to AddClusterCmd to override Zone level > network traffic label. Tested 2 clusters, one with standard vSwitch and other > with dvSwitch. > 4) Tested all 3 traffic types on single physical network with global > parameter 'vmware.use.dvswitch' set to false. This is default configuration > scenario. > > > Added following tests, > 1) Test fetching dvSwitch object from vCenter > 2) Test for presence of dvPortGroup > 3) Test presence of dvPortGroup > 4) Test get existing dvPortGroup > 5) fetch dvPortGroup configuration > 6) Test compare dvPortGroup configuration > 7) Test update dvPortGroup configuration > > > Thanks, > > Sateesh Chodapuneedi > >
