https://issues.apache.org/jira/browse/CLOUDSTACK-657
master, 4.1.0
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.
This is functional specification of feature "CloudStack integration with VMware dvSwitch" which has Jira ID CS-657
Author |
Description |
Date |
---|---|---|
Sateesh Chodapuneedi |
Initial Revision |
12/31/2012 |
1. There is a datacenter running vSphere clusters which are using dvSwitches for virtual networking. Migrate those servers into CloudStack cloud.CloudStack should be able to manage virtual networks over dvSwitches seamlessly.
2. Virtual network orchestration during VM lifecycle operations in cloud should use the dvSwitch designated for specified traffic. This includes configuration/re-configuration of distributed virtual port groups associated with the VM over the designated dvSwitch.
3. Live migration of VM within cluster. The traffic shaping policies and port statistics should be intact even after migration to another host within that cluster.
All virtual network orchestration activities involving dvSwitch would be logged at different log levels in management server log file.
In addition to looking at the management server logs, administrators can look up the following,
•CloudStack assumes dvSwitch is already created in customer's datacenter. This ensures CloudStack's doesn't have to deal with dynamic migration of virtual adapters or networks across other vSwitch. As co-existance of multiple types of virtual switches like Cisco's Nexus 1000v or VMware standard vSwitch and dvSwitch makes it difficult for configuration. Instead administrator can decide where to configure which type of network etc. or migration (say from vSwitch to dvSwitch) and does it with more reliably.
•Highlight architectural patterns being used (queues, async/sync, state machines, etc) - N/A
•Talk about main algorithms used•VLAN configuration over dvSwitch (as we are doing with vSwitch right now)
•The scenarios to be covered are,•Adding host/compute resource to podcluster
•Iterate through the configuration specs (management dvPortGroup – with name prefix as “cloud.private”)and configure & prepare cloud networks on dvSwitch
•Livemigration
•VM life cycle operations which might need instantiation of guest network etc.
•Network operations like network shutdown, network creation, network destroy etc.
•Port binding would be static binding.
•Create dvPortGroup with open dvPorts
•Explain what components are being changed and what the dependent components are
•VmwareResource and VmwareManager (server)
•Regarding database: talk about tables being added/modified - N/A
•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 exhaust quicker.
•Preferably show class diagrams, sequence diagrams and state diagrams - N/A
•If possible, publish signatures of all methods classes and interfaces implement, and the explain the object information of different classes
•core package (VmwareManager, VmwareResource)
•server package
•vmware-base package mo and util packages
Changes to existing web services APIs - AddClusterCmd
Adding an optional parameter named 'virtulSwitchType' which can have values 'vmwaresvs' or 'vmwaredvs' or 'nexusdvs'.
New APIs introduced - N/A
Add cluster wizard
If hypervisor is VMware and global configuration parameter "vmware.use.dvswitch" is set to true, then display a list box that
has 3 options with following labels.
Appendix A:
Appendix B: