Re: [Qemu-discuss] Tap Devices

[Mike Lovell]

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

#qemu-ifup
sudo ifconfig $1 0.0.0.0 up
sudo ovs-vsctl add-port $BRIDGE $1

#qemu-ifdown
sudo ifconfig $1 0.0.0.0 down
sudo ovs-vsctl del-port $BRIDGE $1

#!/bin/sh
USER=`whoami`
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.

mike