Skip to content
This repository

openvswitch package and kernel 3.3 #1

Closed
slacks42 opened this Issue April 27, 2012 · 8 comments

2 participants

slacks42 stronnag
slacks42
Owner

Kernel 3.3 provides the openvswitch module but not brcompat-mod. Please read my wikipage here:

https://github.com/slacks42/arch-pkgbuilds/wiki/openvswitch-and-Archlinux

stronnag

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.

slacks42
Owner

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.

stronnag

B is fine with me too. May I propose options to

  • Only use the upstream kernel module
  • No brcompat

regards,

slacks42
Owner

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. :)

stronnag

Look forward to trying the next version.

slacks42
Owner

Updated it on AUR, will push it to the openvswitch-next branch now. Let me hear what you think :-)

stronnag

Neat, really good. Many thanks.

slacks42
Owner

Awesome.

slacks42 slacks42 closed this June 09, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.