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