[
https://issues.apache.org/jira/browse/CLOUDSTACK-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603774#comment-13603774
]
ilya musayev edited comment on CLOUDSTACK-657 at 3/15/13 8:04 PM:
------------------------------------------------------------------
Sudha and Sateesh
To summarize, this feature has 2 noticed bugs:
1) vmware.ports.per.dvportgroup setting is not read or used. In my case, i set
it to 512, while it fails back to 256 - no matter what i tried.
* The 512 value stays set in CloudStack, however in vmware dvs under portgroup
number of ports, it does not change and uses default 256.
I made a test and set a static variable of numPorts = 512 in
vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java and it
took the static entry without issues.
Please double check this part.
2) Please revise this portion of the code in
vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java
if (vid != null) {
vlanSpec = createDVPortVlanIdSpec(vid);
} else {
vlanSpec = createDVPortVlanSpec();
}
This code does not take into account PortGroups on DVS that are untagged. This
issue was particularly hard to identify as stack trace would only show up on
the hypervisor hostd.log and VC error is was vary vague. the hostd.log on
hypervisor indicate that vlanSpec is invalid for PortGroups that are untagged
(or the ID is left blank).
2013-03-14T20:32:12.351Z [41D16B90 info 'Vmomi' opID=786a44c8-8d] Throw
vim.fault.DvsApplyOperationFault
2013-03-14T20:32:12.352Z [41D16B90 info 'Vmomi' opID=786a44c8-8d] Result:
--> (vim.fault.DvsApplyOperationFault) {
--> dynamicType = <unset>,
--> faultCause = (vmodl.MethodFault) null,
--> objectFault = (vim.fault.DvsApplyOperationFault.FaultOnObject) [
--> (vim.fault.DvsApplyOperationFault.FaultOnObject) {
--> dynamicType = <unset>,
--> objectId = "2442",
--> type = "vim.dvs.DistributedVirtualPort",
--> fault = (vmodl.fault.InvalidArgument) {
--> dynamicType = <unset>,
--> faultCause = (vmodl.MethodFault) null,
--> invalidProperty = "vlanSpec",
--> msg = "",
--> },
--> }
--> ],
--> msg = "",
--> }
Technically we can try setting the
if untagged vlan = true
vid = 0
This last part i need to confirm.
Otherwise, if you add tagged portgroups into DVS, it works.
Going through hopefully the final test now.
Thanks
ilya
was (Author: serverchief):
Sudha and Sateesh
To summarize, this feature has 2 noticed bugs:
1) vmware.ports.per.dvportgroup setting is not read or used. In my case, i set
it to 512, while it fails back to 256 - no matter what i tried.
I made a test and set a static variable of numPorts = 512 in
vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java and it
took the static entry without issues.
2) Please revise this portion of the code in
vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java
if (vid != null) {
vlanSpec = createDVPortVlanIdSpec(vid);
} else {
vlanSpec = createDVPortVlanSpec();
}
This code does not take into account PortGroups on DVS that are untagged. This
issue was particularly hard to identify as stack trace would only show up on
the hypervisor hostd.log and VC error is was vary vague. the hostd.log on
hypervisor indicate that vlanSpec is invalid for PortGroups that are untagged
(or left tag ID is left blank).
2013-03-14T20:32:12.351Z [41D16B90 info 'Vmomi' opID=786a44c8-8d] Throw
vim.fault.DvsApplyOperationFault
2013-03-14T20:32:12.352Z [41D16B90 info 'Vmomi' opID=786a44c8-8d] Result:
--> (vim.fault.DvsApplyOperationFault) {
--> dynamicType = <unset>,
--> faultCause = (vmodl.MethodFault) null,
--> objectFault = (vim.fault.DvsApplyOperationFault.FaultOnObject) [
--> (vim.fault.DvsApplyOperationFault.FaultOnObject) {
--> dynamicType = <unset>,
--> objectId = "2442",
--> type = "vim.dvs.DistributedVirtualPort",
--> fault = (vmodl.fault.InvalidArgument) {
--> dynamicType = <unset>,
--> faultCause = (vmodl.MethodFault) null,
--> invalidProperty = "vlanSpec",
--> msg = "",
--> },
--> }
--> ],
--> msg = "",
--> }
Technically we can try setting the
if untagged vlan = true
vid = 0
This last part i need to confirm.
Otherwise, if you add tagged portgroups into DVS, it works.
Thanks
ilya
> VMware vNetwork Distributed Virtual Switch support in CloudStack
> ----------------------------------------------------------------
>
> Key: CLOUDSTACK-657
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-657
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
> Environment: VMware vSphere 4.1/5.0/5.1
> Reporter: Sateesh Chodapuneedi
> Assignee: Sateesh Chodapuneedi
> Fix For: 4.2.0
>
>
> Need to integrate the functionality of VMware dvSwitch with CloudStack. This
> enables orchestration of virtual networks in VMware environment over
> distributed virtual switch inside vCenter.
> Background:-
> -----------------
> VMware Distributed Switch is an aggregation of per-host virtual switches
> presented and controlled as a single distributed switch through vCenter
> Server at the Datacenter level. vDS abstracts configuration of individual
> virtual switches and enables centralized provisioning, administration, and
> monitoring.
> vDS is integral component of vCenter. Hence the native vDS support makes
> sense for wider and larger deployments of Cloudstack over vSphere.
> Each Standard vSwitch represents an independent point of configuration that
> needs to be managed and monitored. The management of virtual networks
> required by instances in the cloud is tedious when virtual networks have to
> span across large number of hosts. Using distributed vSwitch (vDS) simplifies
> the configuration and monitoring.
> Being standalone implementations, standard vSwitches do not provide any
> support for virtual machine mobility. So there needed a component to ensure
> that the network configurations on the source and the destination virtual
> switch are consistent and will allow the VM to operate without breaking
> connectivity or network policies. Particularly during migration of VM across
> hosts, the sync up among peers need to be taken care. However in case of
> distributed vSwitch during VMotion, the vCenter server, would update the
> vSwitch modules on the hosts in cluster accordingly.
> Following features are available with a Distributed Switch over and above
> Standard vSwitch of vSphere.
> 1. Shaping of inbound (RX) traffic
> 2. Supports a central unified management interface through vCenter Server
> 3. Supports Private VLANs (PVLANs)
> 4. Provides potential customization of Data and Control Planes
> 5. Increased visibility of inter-virtual machine traffic through Netflow
> 6. Improved monitoring through port mirroring (dvMirror)
> 7. Support for LLDP (Link Layer Discovery Protocol), a vendor-neutral
> protocol.
> Release Planning:
> Dev list discussions:
> http://markmail.org/message/eehzokoniwssrx5d
> http://markmail.org/message/ow7za62d3qmnjd2h
> Functional Spec:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Integration+of+CloudStack+with+VMware+DVS
> Feature branch: reviewboard submission
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
