Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of imusayev@webmd.net designates
 213.199.154.142 as permitted sender)
Received-SPF: softfail (mail49-db3: transitioning domain of webmd.net does not
 designate 207.138.251.40 as permitted sender) client-ip=207.138.251.40;
 envelope-from=imusayev@webmd.net;
 helo=exht02l-crp-03.webmdhealth.net ;mdhealth.net ;
From: "Musayev, Ilya" <imusayev@webmd.net>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Subject: RE: [ACS41][DISCUSS] Adding support for VMware dvSwitch
Thread-Topic: [ACS41][DISCUSS] Adding support for VMware dvSwitch
Thread-Index: 
 Ac3dPxwp91LycJM9TvCAMAM7bTskHwLXVcTQAETOYIAAAIvFgAAXgbCAAD229QAAUVYdgw==
Date: Sun, 6 Jan 2013 20:27:29 +0000
Message-ID: <c87qn0glkx6kjoxnoj2i6udk.1357503974153@email.android.com>
References: 
 <35F04D4C394874409D9BE4BF45AC5EA9010B2854B982@BANPMAILBOX01.citrite.net>
 <CD0B1744.3EDB4%chiradeep.vittal@citrix.com>,<35F04D4C394874409D9BE4BF45AC5EA9010B2854BC46@BANPMAILBOX01.citrite.net>
In-Reply-To: 
 <35F04D4C394874409D9BE4BF45AC5EA9010B2854BC46@BANPMAILBOX01.citrite.net>
Reply-To: "Musayev, Ilya" <imusayev@webmd.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_c87qn0glkx6kjoxnoj2i6udk1357503974153emailandroidcom_"
MIME-Version: 1.0

--_000_c87qn0glkx6kjoxnoj2i6udk1357503974153emailandroidcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Sateesh

Is this work in progress or there is something we can test?

Thanks
Ilya

Sateesh Chodapuneedi <sateesh.chodapuneedi@citrix.com> wrote:
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: 04 January 2013 00:40
> To: CloudStack DeveloperList
> Subject: Re: [ACS41][DISCUSS] Adding support for VMware dvSwitch
>

> Does this mean that zones with both standard vSwitch clusters and
> dvSwitch clusters will not be supported?

No, zones with both standard vSwitch clusters and
dvSwitch clusters will be supported.
Physical network traffic label will be used to dictate the
virtual switch type at zone level. This (virtual switch type) can be
overridden at cluster level. AddClusterCmd takes an optional parameter
'vSwitchType' to override the setting. This allows the administrator
to choose virtual switch type at various levels (zone and cluster).
This granularity can be extended to per traffic type
(public traffic can be on vswitch and guest traffic can be on dvswitch)
provided each traffic type is over a separate physical network
because dvswitch cannot share same physical network with another vswitch.

> Can you not discover the type of vSwitch when the cluster is added?

Not possible with name of vSwitch as the input. Because the namespace is di=
fferent
across all types of virtual switches at vmware datacenter. Currently
CloudStack takes vSwitch name as input. To elaborate, there can be a vSwitc=
h with name
"vSwitch0" in a host X (which is in datacenter Y) and a dvSwitch with same =
name in
the datacenter Y and host X is part of that dvSwitch.

That said, possible alternatives I can think of are,
1) Provide unambiguous input while specifying vSwitch (whatever type it is =
of). This
would bring usability issue as administrator need to lookup vcenter's inter=
nal object
references to get to this.
Ex:- Unique object UUID or Managed object reference of that vSwitch
2) Specify physical nic along with vSwitch name to remove ambiguity due to =
namespace.
Given a physical nic we can arrive at correct instance of vSwitch meant by =
the provided
vSwitch name because a dvSwitch and vSwitch are mutually exclusive across p=
hysical nics.


>
> On 1/2/13 11:57 PM, "Sateesh Chodapuneedi"
> <sateesh.chodapuneedi@citrix.com> wrote:
>
> >> -----Original Message-----
> >> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> >> Sent: 03 January 2013 13:12
> >> To: CloudStack DeveloperList
> >> Subject: Re: [ACS41][DISCUSS] Adding support for VMware dvSwitch
> >>
> >> Why the need for the "vmware.use.dvswitch" if the AddCluster api
> >> already requires this?
> >
> >The purpose of the global parameter "vmware.use.dvswitch" is to use it
> >as a switch to enable / disable the feature.
> >
> >Disable the feature in the sense,
> >* All the new UI elements related to the feature would not be displayed
> >if switch is off (parameter is set to 'false')
> >* All the new API parameters (all have to be optional parameters, if
> >any of the new parameters introduced are necessary then the feature
> >can't be
> >hidden/disabled) would be ignored.
> >
> >>
> >>
> >> On 1/1/13 9:03 PM, "Sateesh Chodapuneedi"
> >> <sateesh.chodapuneedi@citrix.com> wrote:
> >>
> >> >I have created an initial draft of the FS here,
> >> >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Integration+o
> >> >f+C
> >> >lou
> >> >dStack+with+VMware+DVS
> >> >I'll keep updating it based on discussion and comments.
> >> >
> >> >Regards,
> >> >Sateesh
> >> >
> >> >> -----Original Message-----
> >> >> From: Sateesh Chodapuneedi
> >> >> [mailto:sateesh.chodapuneedi@citrix.com]
> >> >> Sent: 19 December 2012 09:27
> >> >> To: cloudstack-dev@incubator.apache.org
> >> >> Subject: RE: [ACS41][DISCUSS] Adding support for VMware dvSwitch
> >> >>
> >> >> Changed category from [ASF41] to [ACS41] in subject line
> >> >>
> >> >> > -----Original Message-----
> >> >> > From: Musayev, Ilya [mailto:imusayev@webmd.net]
> >> >> > Sent: 18 December 2012 01:33
> >> >> > To: cloudstack-dev@incubator.apache.org
> >> >> > Subject: RE: [ASF41][DISCUSS] Adding support for VMware dvSwitch
> >> >> >
> >> >> > Sateesh
> >> >> >
> >> >> > As mentioned before I have a good number of vSphere environments
> >> >> > using dvSwitches that I can't roll into CS just yet.
> >> >> >
> >> >> > Whenever you are ready to test something or have a proof of
> >> >> > concept code to try - I can assist.
> >> >> >
> >> >> That would be great! Sure, I will get in touch as soon as the
> >> >> branch is ready.
> >> >> Thanks.
> >> >>
> >> >> > I've been meaning to ask - are you planning to build any
> >> >> > controls that are available via VCenter for dvSwitches - or is
> >> >> > it  strictly support and enablement?
> >> >>
> >> >> CloudStack will provide the option to choose dvSwitch in VMware
> >> >> environment and uses vSphere API (talk to vCenter) when a virtual
> >> >> network needs orchestration (create, modify, destroy cycle).
> >> >>
> >> >> >
> >> >> > Thank you
> >> >> > -ilya
> >> >> >
> >> >> > -----Original Message-----
> >> >> > From: Sateesh Chodapuneedi
> >> >> > [mailto:sateesh.chodapuneedi@citrix.com]
> >> >> > Sent: Monday, December 17, 2012 2:41 PM
> >> >> > To: cloudstack-dev@incubator.apache.org
> >> >> > Subject: [ASF41][DISCUSS] Adding support for VMware dvSwitch
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> >
> >> >> >
> >> >> > I am planning to work on enabling support for VMware native
> >> >> > dvSwitch in CloudStack. Filed a jira ticket for it, see [1].
> >> >> >
> >> >> >
> >> >> >
> >> >> > Integration of VMware dvSwitch with CloudStack 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.
> >> >> >
> >> >> >
> >> >> >
> >> >> > I'll share an FS for this in the next few days.
> >> >> >
> >> >> > Please do let me know your thoughts/concerns.
> >> >> >
> >> >> >
> >> >> >
> >> >> > [1] CLOUDSTACK-657 - "VMware vNetwork Distributed Virtual Switch
> >> >> > support in CloudStack"
> >> >> >
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Sateesh
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >
> >


--_000_c87qn0glkx6kjoxnoj2i6udk1357503974153emailandroidcom_--