[ovs-discuss] Connecting OVSs and hosts running on different VMs

David Gabriel davidgab283 at gmail.com
Mon Nov 23 20:28:15 UTC 2015


Dear Scott and,

Could you please detail the procedure to ensure the connection between the
different components of my topology ?
I will opt to the tools you recommand.

Thanks in advance.
Regards

2015-11-23 17:57 GMT+01:00 Scott Lowe <scott.lowe at scottlowe.org>:

> Please see my responses inline, prefixed by [SL].
>
>
> > On Nov 23, 2015, at 9:40 AM, David Gabriel <davidgab283 at gmail.com>
> wrote:
> >
> > Your analysis is very good !
> > What I want to get is that VM-A (or VM-B,C,D) runs on a separate VM  but
> if it is not feasible, I can adapt my scenario to the last figure you made :
> > VM-A      VM-B          VM-C      VM-D
> >   |        |              |        |
> > HostMachineVM1          HostMachineVM2
> >   w/ OVS                  w/ OVS
> >     |                        |
> >     |                        |
> >     +-------Hypervisor-------+
> > I am using Ubuntu and VirtualBox. If you recommand other
> distribution/tool I will change my environment.
> > Now could you please tell me how shall I proceed to ensure the
> connection in my topology?
>
>
> [SL] Ubuntu+VirtualBox doesn't support nested virtualization, so you can't
> build this topology. You'd need to switch to Ubuntu+KVM (and configure KVM
> to use nested virtualization, which AFAIK is not the default) or use VMware
> Workstation on Linux (which does support nested virtualization). You are
> running Ubuntu on the host, so it's possible to go the Ubuntu+KVM route
> (but a fair amount more work, TBH). Unless you're really familiar with
> Ubuntu+KVM+Libvirt, the easiest route is probably to switch to VMware
> Workstation, which would allow you to build this topology used nested
> virtualization support.
>
> There *may* be a way to break out VM-A/B/C/D into separate VMs, but as I
> pointed out to Hassan in a separate reply that would involve using bridges
> to connect VMs to where OVS was running, and that's not a configuration
> I've ever tested/used/verified.
>
>
>
> > 2015-11-23 17:11 GMT+01:00 Scott Lowe <scott.lowe at scottlowe.org>:
> > Please see my responses inline, prefixed by [SL].
> >
> >
> > > On Nov 23, 2015, at 8:59 AM, David Gabriel <davidgab283 at gmail.com>
> wrote:
> > >
> > > Dear Scott,
> > >
> > > Thanks for reactivity.
> > > Since I have only one physical machine so I want to create inside it :
> > > 1- One VM representing OVS switch #1
> > > 2- One VM representing OVS switch #2
> > > 3- One VM representing the host machine #1 connected to OVS switch #1
> > > 4- One VM representing the host machine #2 connected to OVS switch #2
> > >
> > > Then I have to ensure the connection between my 2 switches in one
> hand. On the other hand I have to connect switch #1 to host #1. And I have
> to do same witch switch 2 and host2
> > > My scenario may be unusual but I have a limitation regarding physical
> equipment availability.
> > >
> > >     c1                  c2
> > >        |                  |
> > >        |                  |
> > >        |                |
> > >     |ovs1|--------------|ovs2|
> > >        |                  |
> > >        |                  |
> > >        |                  |
> > > HostMachine1   HostMachine2
> >
> >
> > [SL] Before we go any further let's make sure we understand that OVS
> generally exists *inside* the hosts, so your diagram would typically look
> something more like this:
> >
> > HostMachine1            HostMachine2
> >   w/ OVS                  w/ OVS
> >     |                        |
> >     |                        |
> >     +----Physical network----+
> >
> > In your case, you want to run all this virtual because you have limited
> physical hardware. No problem. The diagram shifts slightly to look like
> this:
> >
> > HostMachineVM1          HostMachineVM2
> >   w/ OVS                  w/ OVS
> >     |                        |
> >     |                        |
> >     +-------Hypervisor-------+
> >
> > In this case, "hypervisor" could be Linux+KVM, Linux+Xen, ESXi, or any
> number of hosted type 2 hypervisors (VirtualBox, Fusion, Workstation,
> etc.). *IF* the hypervisor is a Linux variant, then you can use OVS there
> to provide connectivity between the VMs; otherwise, you are limited to
> whatever the hypervisor provides.
> >
> > Taking this to the next level...*IF* your hypervisor supports what is
> known as nested virtualization, then you can run VMs inside the VMs so it
> looks something like this:
> >
> > VM-A      VM-B          VM-C      VM-D
> >   |        |              |        |
> > HostMachineVM1          HostMachineVM2
> >   w/ OVS                  w/ OVS
> >     |                        |
> >     |                        |
> >     +-------Hypervisor-------+
> >
> > In this sort of configuration, you can use OVS (inside HostMachineVM1
> and HostMachineVM2) to provide networking connectivity to the nested VMs
> (VM-A through VM-D).
> >
> > I *think* this last scenario is probably what you're seeking to do, but
> I could be wrong.
> >
> > Does this help at all?
> >
> >
> >
> > > 2015-11-23 16:42 GMT+01:00 Scott Lowe <scott.lowe at scottlowe.org>:
> > > Please see my response below.
> > >
> > >
> > > On Nov 23, 2015, at 8:37 AM, David Gabriel <davidgab283 at gmail.com>
> wrote:
> > >>
> > >> Dears,
> > >>
> > >> I am lookig to define a basic topology including 2 OVS switches and 2
> hosts (each host is connected to one switch). These 4 components (switches
> ans hosts) are running in one separate VM. Please tell me how to connect
> them in order to ensure the communication in my basic network.
> > >> I checked so many links in the Internet but I didn't find a holistic
> tutorial ...
> > >> Regarding the controller I learn how to set it.
> > >
> > >
> > > Generally speaking, OVS runs *in* the host, so I'm a bit unclear on
> what you're trying to achieve. Can you elaborate so that we can try to help
> you?
>
> --
> Scott
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20151123/80e0bce6/attachment-0002.html>


More information about the discuss mailing list