> On Feb. 18, 2013, 7:59 a.m., Koushik Das wrote: > > plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/VmwareServerDiscoverer.java, > > line 185 > > <https://reviews.apache.org/r/9210/diff/1/?file=254475#file254475line185> > > > > Is this behavior to default to svs discussed in the FS? If not please > > try to get a closure.
Makes sense to throw error in case of faulty vswitch type specified as parameter. Now addCluster attempt is failed if errorneous vswitch type is supplied. > On Feb. 18, 2013, 7:59 a.m., Koushik Das wrote: > > plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java, > > line 285 > > <https://reviews.apache.org/r/9210/diff/1/?file=254478#file254478line285> > > > > Looks like _nexusVSwitch is no longer getting used Yes, removed it. - Sateesh ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9210/#review16696 ----------------------------------------------------------- On Feb. 25, 2013, 10:06 a.m., Sateesh Chodapuneedi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/9210/ > ----------------------------------------------------------- > > (Updated Feb. 25, 2013, 10:06 a.m.) > > > Review request for cloudstack, Murali Reddy and Kelven Yang. > > > Description > ------- > > This is 5/final patch for feature 'Support for VMware dvSwitch in CloudStack'. > > This patch contains > 1)Changes to addCluster done in vmware discoverer to support vswitch type > provided as parameters. Also performing validation of vswitch type parameter > provided with addCluster api call. Physical network configuration is > validated. > 2)Changes to vmware resource to use specified vswitch type while preparing > network for guest and public traffic types > 3)Changes to vmware manager to introduce new global parameter > vmware.ports.per.dvportgroup. Some cleanup. > Virtual switch type could be chosen at zone level or at cluster level for > specific traffic type. autoExpand of dvPortGroup is available in code but > disabled as its breaking because vCenter 4.1 does not support autoExpand > feature. This would be supported once vSphere SDK 5.1 is added to CloudStack. > > > This addresses bug CLOUDSTACK-657. > > > Diffs > ----- > > > plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/VmwareServerDiscoverer.java > 5d7edce > > plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManager.java > 445b2f0 > > plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java > 70f98cc > > plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java > 5cac253 > server/src/com/cloud/resource/ResourceManagerImpl.java 98044fb > vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java > 50f9541 > > Diff: https://reviews.apache.org/r/9210/diff/ > > > Testing > ------- > > 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 > >
