cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: VXLANs and Cisco Nexus 1000v
Date Mon, 08 Apr 2013 17:52:05 GMT
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...  ;-)


View raw message