You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Bug Reference

https://issues.apache.org/jira/browse/CLOUDSTACK-657

Branch

master, 4.1.0

Introduction

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.

Purpose

This is functional specification of feature "CloudStack integration with VMware dvSwitch" which has Jira ID CS-657

References

Document History

Author

Description

Date

Sateesh Chodapuneedi

Initial Revision

12/31/2012

Glossary

  • dvSwitch / vDS - VMware vNetwork Distributed Virtual Switch.
  • vSwitch - VMware vNetwork Standard Virtual Switch.
  • dvPort - Distributed Virtual Port (member of dvPortGroup).
  • dvPortGroup - Distributed Virtual Port Group

Feature Specifications

  • put a summary or a brief description of the feature in question 
  • list what is deliberately not supported or what the feature will not offer - to clear any prospective ambiguities
  • quality risks (test guidelines)
    • functional*
      ***Live migration of VM
      ***Deployment of virtual router
      ***Deployment of VM
    • non functional: performance, scalability, stability, overload scenarios, etc*
      ***Large number of VMs and isolated networks need to be tested for performance specific results.
    • negative usage scenarios - NA
    • what are the audit events *
      ***All virtul network orchestration events
      ***VM migration events
    • graceful failure and recovery scenarios
    • possible fallback or work around route if feature does not work as expected, if those workarounds do exist ofcourse.
  • explain configuration characteristics:
    • configuration parameters or files introduced/changed
      New configuration parameter - "vmware.use.dvswitch" of type Boolean. Possible values are "true" or "false". Default value is "false".
    • branding parameters or files introduced/changed - NA
    • highlight parameters for performance tweaking - NA
    • highlight how installation/upgrade scenarios change
  • deployment requirements (fresh install vs. upgrade) if any
    • VMware dvSwitch must be already created/configured in the vCenter datacenter deployment.
    • All the host/clusterresources should be added to dvSwitch before adding the cluster to CloudStack's pod cluster.
  • interoperability and compatibility requirements:
    • Hypervisors - VMware vSphere 4.1 or later
  • list localization and internationalization specifications 
    • UI changes in "Add Cluster" wizard. See the section "UI Flow".
  • explain the impact and possible upgrade/migration solution introduced by the feature 
  • explain performance & scalability implications when feature is used from small scale to large scale
  • explain marketing specifications
  • explain levels or types of users communities of this feature (e.g. admin, user, etc)
    • admin - Administrators would be target audience for this feature as this is at infrastructure level.

Use cases

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.

Supportability characteristics

Logging

All virtual network orchestration activities involving dvSwitch would be logged at different log levels in management server log file.

  • INFO (all the successful operations)
  • ERROR (all exceptions/failures)
  • DEBUG (all other checks)

Debugging/Monitoring

In addition to looking at the management server logs, administrators can look up the following,

  • vCenter logs for analysis.
  • Warnings and Alerts associated with specific cluster in vCenter
  • dvPort status (to see if port is configured correctly and is active or not) displayed in network configuration screen of vSphere native/web client UI.

Architecture and Design description

  • discussion of alternatives amongst design ideas, their resources/time tradeoffs and limitations. Explain why a certain design idea is chosen over others
  • highlight architectural patterns being used (queues, async/sync, state machines, etc)
  • talk about main algorithms used
  • explain what components are being changed and what the dependent components are
  • regarding database: talk about tables being added/modified
  • performance implications: what are the improvements or risks introduced to capacity, response time, resources usage and other relevant KPIs
  • preferably show class diagrams, sequence diagrams and state diagrams
  • if possible, publish signatures of all methods classes and interfaces implement, and the explain the object information of different classes

Web Services APIs

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

UI flow

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.

  • 1. "VMware vNetwork Standard Virtual Switch"
    Action to perform if this option is selected:-
    Add a parameter to parameter list of AddClusterCmd API call.
    Parameter name: "vswitchtype"
    Parameter value: "vmwaresvs"
  • 2. "VMware vNetwork Distributed Virtual Switch"
    Action to perform if this option is selected:-
    Add a parameter to parameter list of AddClusterCmd API call.
    Parameter name: "vswitchtype"
    Parameter value: "vmwaredvs"
  • 3. "Cisco Nexus 1000v Distributed Virtual Switch"
    Action to perform if this option is selected:-
    Add a parameter to parameter list of AddClusterCmd API call.
    Parameter name: "vswitchtype"
    Parameter value: "nexusdvs"
  • List Box label - "Virtual Switch Type"
  • Default option - "VMware vNetwork Standard Virtual Switch"

Appendix

Appendix A:

Appendix B:

  • No labels