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 <b...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev