You can clone with
Kernel 3.3 provides the openvswitch module but not brcompat-mod. Please read my wikipage here:
First, thanks for the continuing work on this and the great deal and thought and effort that has gone into the rc.d script.
I feel that for a modern kernel (and user-land), the brcompat module is a distraction. It's not necessary, at least for qemu / kvm / libvirt and causes loading to fail on a 3.4 kernel system as brcompat fails to build.
I would recommend / wish that one of the following happens:
a. Split out br_compat into a separate rc.d file. If I don't want it then I can ignore it, or;
b. Allow the user to define via /etc/conf.d/openvswitch whether brcompat would be loaded and its daemon started.
Given the complexity of the new rc.d script, I expect (a) is the easiest option.
At the moment it doesn't really work for many use cases and in order to have in kernel openvswitch.ko and no brcompat.ko, no brcompat daemon, I have to hack the rc.d script into submission.
Hi, thanks for your message, I appreciate it. The script is indeed elaborate, I "composed" it in a day or two and the technique is a bit of a stretch. It works fine for kernels up to 3.3, yesterday I tested it with 3.4 and found the dkms compiling routine to fail indeed... I didn't notice that this was caused by brcompat alone?
About the necessity of the module -- from what I understand brcompat is especially convenient with "fake bridges" (man openvswitch), in short the fake bridge is a bridge where all ports are de facto in a VLAN. However, I use openvswitch exclusively with Xen and I do not require fake bridges myself. Instead I I simply hack the various xen python scripts so that they are able to pass a 'vtag' variable that I can put in the host config files. The scripts themselves use ovs-vsctl instead of brctl.
Then the openvswitch init script. It's actually easy to do B, I'd prefer that so I'll be implementing that. Unless of course you (or anyone) has a good argument for why A would be better/preferred.
B is fine with me too. May I propose options to
Ack. The first idea (use only the in-kernel module) is a challenge but I'll accept it. The second idea will be implemented as optional and will have to be exclusively enabled after installation, i suppose that has your preference and it does make the most sense. :)
Look forward to trying the next version.
Updated it on AUR, will push it to the openvswitch-next branch now. Let me hear what you think :-)
Neat, really good. Many thanks.