Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 382035 - app-emulation/xen-tools 4.1.1 network management collides with openrc-0.8.3-r1 created TAP devices
Summary: app-emulation/xen-tools 4.1.1 network management collides with openrc-0.8.3-r...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Ian Delaney (RETIRED)
Depends on:
Reported: 2011-09-06 11:06 UTC by Zoltán Halassy
Modified: 2011-09-20 09:25 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Zoltán Halassy 2011-09-06 11:06:27 UTC
xen-tools itself provides tools for network management. I commented them out from xend-config.sxp . The only script I use is to add the new virtual machine interfaces to the proper bridges. But I also use openvpn with persistent tap adapters created by openrc (/etc/conf.d/net). If xenstored is running, issuing an openvpn --dev tap0 --mktun (or similar tun creating command, or creating the interface with config_tap0="null" from /etc/init.d/net.tap0 start) automatically gives the hardware address fe:ff:ff:ff:ff:ff to tap0 and adds it into br0 (which is not desired, as openrc would put tap0 into br1 later).

To workaround the issue I added the following lines into /etc/xen/scripts/vif-bridge (after the inclusion of


if [[ "$dev" =~ $regex ]];then
    exit 0
Comment 1 Ian Delaney (RETIRED) gentoo-dev 2011-09-10 07:48:13 UTC
It's a challenge when you the poster know more than I.
Help me catch up.
gentoo64 idella # brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes

I boot a guest

gentoo64 idella # brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.feffffffffff       yes             tap2.0
Here the setting does not occur until after xen sets the bridge on demand.

"as openrc would put tap0 into br1 later"

what is the source to set your br1?
A also don't know or run openrc.  These couple of lines can easily be added to the xen-tools script?  Is this your request or hope?  How else will it impact?
Comment 2 Ian Delaney (RETIRED) gentoo-dev 2011-09-17 14:16:28 UTC
On doing some checking, have as follows;
although it may be a clash, keep them from clashing.
Select either openrc scripts to do the configuring or allow the xen scripts.
One not both.
You can go the one step further and comment out the setting that calls \
/etc/xen/scripts/vif-bridge in etc/xen/xend-config.sxp
and thus select openrc as the source of configuring the ifaces.
Alternately, simply remove the tap stuff from /etc/conf.d/net and let the xen tools configure it.
One or the other.
Consider it a test request, repost
Comment 3 Zoltán Halassy 2011-09-20 08:00:51 UTC
My br1 settings comes from /etc/conf.d/net:

rc_need_br1="net.tap0 net.tap1"
bridge_br1="tap0 tap1"

Also something else is really fishy here, brctl show says the following:

bridge name     bridge id               STP enabled     interfaces
br0             8000.001999a7f851       no              eth0
br1             8000.4e4e71f9c3e9       no              tap0

vif3.0 and vif3.1 are connected to the virtual machine (hvm windows xp), but what the hell is tap3.0 ant tap3.1, where did they come from (traffic is 0 on them)? If I stop the hvm domU, they vanish; if i restart the domU, they come back. The domU conf simply has this line:

vif = [ 'type=ioemu, bridge=br0', 'type=ioemu, bridge=br1' ]

The changes I made to the solved my problem at least, I just wonder if anyone else has this kind of problem (not sure how many people runs xen AND openvpn sametime).

Also, you noted I should only use one of the managing script, I agree, but how do I tell openrc, to put the newly created interfaces into the bridges, as I don't know their name before creating the domU (stopping domU removes vif3.0 and restarting it creates a vif4.0)?
Comment 4 Ian Delaney (RETIRED) gentoo-dev 2011-09-20 09:25:50 UTC
tap3.0 ant tap3.1, where did they come.

probably from the kernel.  Firstly what is your kernel?  I am guessing 3.0.0 or so.Look at the the xen backend blktap devices.  Look in /dev and see what the xen capable kernel is creating in the way of tap devices.  If they are builtin, consider making them modules so they need be explicitly loaded or blacklisted.

If I stop the hvm domU, they vanish; if i restart the domU, they come

Clearly they are of xen kernel backend tap device origin.


I strongly suggest is helping them on their way.
Keep testing, re-post