Thanks Justin - I was pleased to see your message a few weeks ago indicating that it actually worked; that is one way that I was considering, though I cut the text mentioning it from my message. :)
On Mar 9, 2013, at 5:51 PM, Justin Pettit <jpet...@cs.stanford.edu> wrote: > If you only run network namespaces, it's pretty easy to run multiple > instances of OVS. I touched on it briefly a couple of weeks ago on the > ovs-discuss mailing list: > > http://openvswitch.org/pipermail/discuss/2013-February/009157.html > > As you mentioned, you'll need to have each ovsdb-server and ovs-vswitchd pair > use a separate rundir, config files, etc, since they'll be in the same > process and file namespaces. > > Also, Ramana, please don't cross-post mailing lists in the future. > > --Justin > > > On Mar 9, 2013, at 12:27 AM, Bob Lantz <rla...@cs.stanford.edu> wrote: > >> To clarify, I believe the default configuration of the OVS daemons uses unix >> domain sockets, which is a perfectly good idea but may break when your >> switch and daemons are in different namespaces. >> >> On Mar 9, 2013, at 12:19 AM, Bob Lantz <rla...@cs.stanford.edu> wrote: >> >>> Mininet doesn't currently support that configuration because I wasn't able >>> to come up with an easy way to make it work out of the box with the Ubuntu >>> OVS packages. I suspect one problem could be that unix domain sockets don't >>> work across network namespaces, even with a shared filesystem, and >>> openvswitch-switch uses them to communicate with ovs-vswitchd and >>> ovsdb-server. If that's the case, then a) it doesn't seem like correct >>> kernel behavior to me, b) it could also be the root cause of the annoying >>> x11 forwarding breakage, and c) there could be workarounds like using a >>> network connection on the virtual control network, but it probably requires >>> further investigation and my understanding of all of the relevant pieces is >>> incomplete and possibly in error. >>> >>> Very few people have asked me about this - I think emulating a virtual >>> control network (controlled by OpenFlow no less - turtles all the way >>> down!) is not a popular thing to do on Mininet, although it can certainly >>> be done as evidenced by the --innamespace command line option. >>> >>> -Bob >>> >>> On Mar 8, 2013, at 10:40 PM, Ramana Reddy <gtvrre...@gmail.com> wrote: >>> >>>> Hi All, >>>> I want to put switches in their own name space in mininet using open >>>> Vswitch. >>>> But mininet website telling that open Vswitch does not support this >>>> feature. >>>> >>>> http://mininet.github.com/walkthrough/#everything-in-its-own-namespace-user-switch-only >>>> >>>> $ sudo mn --innamespace --switch user >>>> Instead of using loopback, the switches will talk to the controller >>>> through a separately bridged control connection. By itself, this option is >>>> not terribly useful, but it does provide an example of how to isolate >>>> different switches. >>>> >>>> Note that this option does not (as of 11/19/12) work with Open vSwitch. >>>> >>>> I want to know which version of open Vswitch supports this feature. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Ramana. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> openflow-discuss mailing list >>>> openflow-discuss@lists.stanford.edu >>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> >> _______________________________________________ >> discuss mailing list >> disc...@openvswitch.org >> http://openvswitch.org/mailman/listinfo/discuss > > _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
