[ovs-dev] [PATCH] OVS: add some tips for kvm guest env

Ben Pfaff blp at nicira.com
Fri May 31 04:15:31 UTC 2013


On Fri, May 31, 2013 at 10:02:32AM +0800, Zhi Yong Wu wrote:
> On Fri, May 31, 2013 at 7:18 AM, Ben Pfaff <blp at nicira.com> wrote:
> > On Fri, May 31, 2013 at 06:47:34AM +0800, Zhi Yong Wu wrote:
> >> If multiple vswitches exist on the same host, how about the routes
> >> on the host?
> >
> > I don't understand this question.  It appears to ask whether multiple
> ah, sorry for my unclear question. Let me try again:
> e.g. we add multiple virtual bridges on the same host, If we need to change
> the routes on the host in order that all guests attached to different switches
> can access external world based on the advices from FAQ, do you think it
> is convenient to the sys admin or the users? maybe he need to change a lot
> of routes on the host.

This is the first complaint, that I recall.

Your solution also involves changing routes, in fact more of them: in
the common case for the solution that the FAQ suggests, the admin does
not change any routes at all (and only moves an IP address).

> > rules may exist on a host.  The answer to that question is "yes", but

(I meant "routes" here, by the way, not "rules".)

> > I doubt it is the question you meant to ask.
> >
> >> by the way, can i consult another question? Why did OVS introduce two
> >> internal devices for each vswitch?
> >
> > It didn't.  There is one internal device for ovs-system, and one for
> > br0.  If you add a second bridge, you will have three internal
> > devices.
> Why need it to introduce ovs-system? i remember that OVS had no such
> internal device before. I searched some comments, but don't make sure
> to understand it. Can you give some explaination?

We needed to merge all the bridges into a single kernel datapath to make
tunneling work in a sensible way.  The easiest way to do that was to
give that datapath an otherwise unused internal port, since that is how
the kernel identifies a datapath.

Why are you so concerned about this?  It is an implementation detail
that is ordinarily of little interest.



More information about the dev mailing list