Thanks a lot , that's def the way i was thinking this works. I'll be working with it , I'll let you know.
Thanks On Mon, Apr 8, 2013 at 12:52 PM, Chip Childers <chip.child...@sungard.com>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 >
