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 vif-common.sh): regex='^tap[0-9]+$' if [[ "$dev" =~ $regex ]];then exit 0 fi
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 vif2.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?
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
My br1 settings comes from /etc/conf.d/net: tuntap_tap0="tap" config_tap0="null" mac_tap0="4e:4e:71:f9:c3:e9" tuntap_tap1="tap" config_tap1="null" mac_tap1="4e:4e:71:f9:c3:ea" rc_need_br1="net.tap0 net.tap1" bridge_br1="tap0 tap1" config_br1="10.101.30.30/24" routes_br1="" Also something else is really fishy here, brctl show says the following: bridge name bridge id STP enabled interfaces br0 8000.001999a7f851 no eth0 tap3.0 vif3.0 br1 8000.4e4e71f9c3e9 no tap0 tap1 tap3.1 vif3.1 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 vif-common.sh 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)?
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 back. Clearly they are of xen kernel backend tap device origin. tuntap_tap1="tap" config_tap1="null" I strongly suggest is helping them on their way. Keep testing, re-post
