CLOUDSTACK-657 VMware vNetwork Distributed Virtual Switch support in CloudStack
This is 5th 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. Checks for physical network configuration for vmware cluster is added.
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. Would be enable once vSphere 5.1 SDK support is added to CloudStack.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
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.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Due to incorrect logic the private network traffic label specified was not getting used, instead some default was getting used (vSwitch0 or privateEthernetPortProfile). The fix passes the correct label in the format vSwitchX or vSwitchX,<vlan_id> and based on that the correct switch is used.
and CloudException in one place, and Introduced ApiErrorCode to handle CloudStack API error
code to standard Http code mapping.
Signed-off-by: Min Chen <min.chen@citrix.com>
- Makes plugins self contained so they decide their properties file format
- PluggableService creates the contract that implementing entity will return a
properties map which is apiname:rolemask (both are strings)
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
NetworkManager's exclusive focus is now
- handling plugins during orchestration, and
- to deal with ip address allocation.
Those classes that used to refer to NetworkManager to get access to the datamodel now refer to NetworkModel
Signed-off-by: Chiradeep Vittal <chiradeep@apache.org>
Issue seen during system vm template upgrade and restoreVM command
scenarios for vmware. In these cases CS tries to recreate root disk with
same name as the existing one, in case of vmware this results in creation
of vmdk file with same name for both existing and new root volume.
This results in undesired behavior when storage cleanup thread tries to
cleanup old volume. Made the vmdk file name unique by adding the volume
id to it. This will ensure that during volume recreation in the scenarios
mentioned vmdk will get created with a new name and there will be
no undesired side effects of running the storage cleanup thread.
Mice Xia
sateesh
frank
Bharat Kumar
Edison Su
hongtu_zang
Rohit Yadav
Koushik Das
Marcus Sorensen
Min Chen
Kelven Yang
Sheng Yang
Jayapal
Alex Huang
Chiradeep Vittal
Murali Reddy