[ovs-discuss] 答复: Re: bridge renaming issue with Xen
mark+lists at internecto.net
Fri Mar 9 16:51:31 PST 2012
> > [root at hc_2c519_1_1_7 scripts]# ./network-bridge start netdev=eth0
> > Nothing to flush.
> > Waiting for peth0 to negotiate link.
> > can't add peth0 to bridge eth0: Invalid argument
> What is generating this last line?
I'd just like to jump in and explain the path I am currently
exploring with Xen.
In network-bridge you add one line at line number 2:
Now setup your preferred network without Xen. Setup bridges (wan0, lan0,
whatever) first, using openvswitch. Then use your distribution's
standard networking options if they are flexible enough. Or just write
your own network init script. This was my own preferred method for a
Xen dom0. I chose Arch Linux, not Debian, as dom0 because it proved to
be much easier. It has less frustrating conventions and more room for
So, with network-bridge being disabled and your network back in
orderthe next step is your system's init. Configure it to first start
openvswitch and ovs-brcompatd. After those, add your networking script.
This shouldn't be hard - runlevel scripts are usually far less hard to
understand than this 'network-bridge' monstrosity. The latter does
weird things no one asked it to do: it renames eth0 to peth0 and
creates eth0 as a bridge and then adds peth0 to eth0. Xen doesn't need
to handle that initial system initialisation. Your network script
should handle that.
So the alternative I suggest gives you the option of making a bridge
with openvswitch, you can call it wan0 and then let Xen know this is
the name of the default bridge. Again: in your own network script
- not in Xen's network-bridge. Then add eth0 and don't forget to set the
link state of the devices to up... that one bit me one day.
You can then go even further, by modifying vif-bridge. I copied it to
vif-ovs and rewrote most of it. It allowed me to replace the brctl
commands with all kinds of (better) ovs commands. I rewrote the xm part
of Xen a bit on one box, they're python scripts, and they now pass a
'vtag' variable to vif-ovs where vtag can either be a VLAN number or
the string "trunk."
So now one host config for Xen might contain a line like this:
So with a bit of hackery here and there you can improve Xen
dramatically. Especially when you want it to work perfectly with
openvswitch. All of Xen's scripts (those in /etc/xen/scripts) are hard
to understand imho. I am spending some of my free time at (trying
to) rewrite them. Unfortunately I don't know how to handle this with xl
rather than with xm. But lest I digress too far let me just leave it at
More information about the discuss