Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4E9ADD236 for ; Wed, 19 Dec 2012 03:56:44 +0000 (UTC) Received: (qmail 95078 invoked by uid 500); 19 Dec 2012 03:56:43 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 95031 invoked by uid 500); 19 Dec 2012 03:56:43 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 95022 invoked by uid 99); 19 Dec 2012 03:56:43 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Dec 2012 03:56:43 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sateesh.chodapuneedi@citrix.com designates 203.166.19.134 as permitted sender) Received: from [203.166.19.134] (HELO SMTP.CITRIX.COM.AU) (203.166.19.134) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Dec 2012 03:56:36 +0000 X-IronPort-AV: E=Sophos;i="4.84,313,1355097600"; d="scan'208";a="131655" Received: from banpmailmx02.citrite.net ([10.103.128.74]) by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5; 19 Dec 2012 03:56:13 +0000 Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Wed, 19 Dec 2012 09:26:12 +0530 From: Sateesh Chodapuneedi To: "cloudstack-dev@incubator.apache.org" Date: Wed, 19 Dec 2012 09:26:11 +0530 Subject: RE: [ACS41][DISCUSS] Adding support for VMware dvSwitch (Was: [ASF41][DISCUSS] Adding support for VMware dvSwitch) Thread-Topic: [ACS41][DISCUSS] Adding support for VMware dvSwitch (Was: [ASF41][DISCUSS] Adding support for VMware dvSwitch) Thread-Index: Ac3cjyHifYQo16ZoT1y6tsXq0XE+EgAr2k3w Message-ID: <35F04D4C394874409D9BE4BF45AC5EA9010B2807B62F@BANPMAILBOX01.citrite.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org > -----Original Message----- > From: Chip Childers [mailto:chip.childers@sungard.com] > Sent: 18 December 2012 01:15 > To: cloudstack-dev@incubator.apache.org > Subject: [ACS41][DISCUSS] Adding support for VMware dvSwitch (Was: > [ASF41][DISCUSS] Adding support for VMware dvSwitch) >=20 > (note subject line change) >=20 > On Mon, Dec 17, 2012 at 2:40 PM, Sateesh Chodapuneedi > wrote: > > 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. > > >=20 > +1 on adding this support. Do you intend to keep the implementation > similar to how the Nexus1000v support works (or will after it's fixed)? > I'd prefer that they are at feature parity, given that the 1kv is really > just a replacement for the VMware DVS that gives operators a nice CLI to > work against. >=20 Yes, I am trying to keep the implementation similar to Nexus100v support. The dvSwitch would be an alternative for orchestration of virtual networks = (of VMware servers) in CloudStack. > > > > [1] CLOUDSTACK-657 - "VMware vNetwork Distributed Virtual Switch > support in CloudStack" > > > > > > > > Regards, > > > > Sateesh > > > > > > > > > >