[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Tap Devices

From: Mike Lovell
Subject: Re: [Qemu-discuss] Tap Devices
Date: Thu, 29 Nov 2012 23:02:57 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 11/29/2012 01:59 PM, Frans de Boer wrote:
I have made the solution. Remember that OpenvSwitch is part of the issue. The part initializing OpenvSwitch is not discussed here, but I needed to take the next steps:

Involved programs are: ifconfig, tunctl, ovs-vsctl.
These programs are set to system group 'qemu' (make it yourself)
The programs have the suid (sorry, not sgid!) bit set.
Also, /dev/net/tun has already the (default) 666 mode settings and there is no need to change the group from root to qemu.

having ifconfig, tunctl, and ovs-vsctl all suid is probably a really bad idea. that would allow anyone, or anything, on the system to reconfigure the networking on the host without security checking and possibly without the ability to know who made the changes.

Use the next example script nipped to create the tap device:

# Create the tap device with the proper group and user id's
sTAPID=$(/sbin/tunctl -b -g qemu -u `who -m|sed -r -e 's/[[:space:]]+.*$//'`)

kudos on the who+sed but you probably could have also just used `whoami`. :)

qemu-system-x86_64 -machine type=pc,accel=kvm,kernel_irqchip=on --enable-kvm -cpu coreduo -smp 2 -vga std -soundhw ac97 -net tap,vlan=0,ifname=$sTAPID,script=/etc/openvswitch/ovs-ifup,downscript=/etc/openvswitch/ovs-ifdown -net nic,model=virtio,vlan=0,macaddr=52:54:00:00:FB:02 -m 2048 -localtime -name VWinXP-nl -boot c -monitor vc:1680x1050 -usb -usbdevice tablet -alt-grab -drive file=/media/raidarray/vms/vwinxpnl.raw,index=0,media=disk,if=virtio,cache=writeback -no-frame -cdrom /dev/null

The programs ifconfig and ovs-vsctl are used by the ovs-if[up|down] scripts when the tap device is initialized.

do you use ifconfig, tunctl, or ovs-vsctl for operations other than bring the tap interface up, creating a tap interface, and adding the tap to the openvswitch bridge?

if that is all you are using them for then it is possible to use qemu-bridge-helper. without access to those utilities, it can create a tap device, bring the interface up, and connect it to a bridge. the potentially hard part is that the operation to connect the tap to the bridge is through the standard bridge interface and so it wouldn't be able to directly manipulate openvswitch. it is possible to do this when also using the openvswitch brcompat module and daemon. these make it so the standard bridge interfaces will manipulate openvswitch bridges. see INSTALL.bridge in the openvswitch source for setting it up.

i set up openvswitch on a box i had laying around and got the brcompat support working. after doing that, i was able to use openvswitch with the qemu-bridge-helper. 'qemu-system-x86_64 -net nic -net bridge,helper=/usr/lib/qemu-bridge-helper,br=br0' was able to start a vm and checking 'ovs-vsctl list-ports br0' showed a new tap device connected to the openvswitch bridge.

if the scripts you are using do more than just creating the tap interface, connecting it to the bridge, and bringing up the interface then the qemu-bridge-helper probably wouldn't work as is. if that is case, i would recommend writing some set of scripts that include sudo and adding the sudo commands to sudoers. something like this might work

sudo ifconfig $1 up
sudo ovs-vsctl add-port $BRIDGE $1

sudo ifconfig $1 down
sudo ovs-vsctl del-port $BRIDGE $1

sTAPID=`sudo tunctl -b -u $USER`
qemu-system-x86_64 -machine type=pc,accel=kvm,kernel_irqchip=on --enable-kvm -cpu coreduo -smp 2 -vga std -soundhw ac97 -net tap,vlan=0,ifname=$sTAPID,script=sudo-ovs-ifup,downscript=sudo-ovs-ifdown -net nic,model=virtio,vlan=0,macaddr=52:54:00:00:FB:02 -m 2048 -localtime -name VWinXP-nl -boot c -monitor vc:1680x1050 -usb -usbdevice tablet -alt-grab -drive file=/media/raidarray/vms/vwinxpnl.raw,index=0,media=disk,if=virtio,cache=writeback -no-frame -cdrom /dev/null

then add something like "%qemu ALL= NOPASSWD: /sbin/ifconfig,/usr/bin/ovs-vsctl,/usr/sbin/tunctl " in sudoers. i just typed this in the email and not tested so typos or slight errors might exist but the general idea should work.

Note: the script as well as the disk image should have the same (qemu) group settings.

So, using OpenvSwitch has cost me much work - as opposed to using VDE who's documentation is far richer - but it pays off by a 20-30% faster net throughput.

VDE is definitely useful in some scenarios and i have a couple rigs using it. it does seem to be slower but in the places i'm using it the performance was 'good enough.' also, how does using just the standard linux bridge compare? i thought the performance difference between them was pretty low and the advantages of openvswitch were the additional features.

hopefully this doesn't sound like me keeping to push a particular solution but, if you are doing the simple use case, i think qemu-bridge-helper will help and be a little more secure.

That's all...pfffff.

i'm sorry about the frustrations. it took me a long time to wrap my head around things and i'm still learning new things. the documentation that is out there can be very annoying sometimes. hopefully this also doesn't sound like rambling at this point. what i expected to be a short email ended up being a longer one.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]