cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeronimo Garcia <>
Subject Re: VXLANs and Cisco Nexus 1000v
Date Mon, 08 Apr 2013 18:11:01 GMT
Thanks a lot , that's def the way i was thinking this works.

I'll be working with it , I'll let you know.


On Mon, Apr 8, 2013 at 12:52 PM, Chip Childers <>wrote:

> On Mon, Apr 08, 2013 at 12:38:24PM -0500, Jeronimo Garcia wrote:
> > I think I'm getting it wrong tho ,  if i want to use VXLANS , i would be
> > replacing "bridges" with nexus 1000v right and not the default virtual
> > router.
> >
> > It's got to be layer 2 inide a layer 3 udp packet .. , therefore it's got
> > to be a switch or something like that .
> >
> > Thanks
> Yes, I think you may be confusing things.
> The 1KV has two parts:
> 1 - The in-hypervisor switch (called the VEM, or Virtual Ethernet
> Module).  In vSphere this is a kernel module loaded within the
> hypervisors participating in the DVS.
> 2 - The external VM that acts as the control point (called the VSM, or
> Virtual Supervisor Module).  In most implementations, this lives outside
> of the environment where the DVS is actually controlling switching.
> My experience with it is based on vSphere, not KVM or Xen, but I think
> it's probably very similar in general implementation terms.  I'm also
> not familiar with any L3 functions that it might provide, but VXLAN is
> basically a mechanism to create an L2 overlay encapsulated in IP.  This
> means that it's primary use-case within CloudStack would be to provide
> the network isolation method.
> This is what was mentioned earlier...  CloudStack doesn't currently have
> support for VXLAN as the isolation type.  That would have to be built,
> and I'd also assume that the first target environment would be for vSphere.
> If you want to help us implement it for 1KV and KVM, then that would be
> great!  And if you work on it, you could certainly implement it before a
> vSphere implementation happens, since there really wouldn't be a
> dependency one way or the other.
> I assume the image you are referring to is the VSM's image.  The VSM is
> simply a control system for the distributed VEMs.
> The CloudStack Virtual Router (VR) isn't the same thing.  It's the
> device that would provide the L3 services in your environment, and would
> actually be a tenant of the underpinning VXLAN overlay network (just
> like the user VMs).  The VR would be given virtual interface(s) within
> VXLAN overlay networks, and would continue to act as the DHCP server,
> firewall, gateway, etc...  like it does in a VLAN isolation model.
> At least, that's how I understand it...  ;-)
> -chip

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message