[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?
From: |
Liraz Siri |
Subject: |
Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu? |
Date: |
Wed, 24 Dec 2008 22:52:22 +0200 |
User-agent: |
Thunderbird 2.0.0.12 (X11/20080227) |
Anthony Liguori wrote:
> FWIW, we could simplify bridged networking in QEMU but it would require
> root privileges or a setuid helper.
A setuid helper would probably do the trick. You need root privileges to:
1) create the tap device (with appropriate ownership)
2) bridge it to your NIC
Once you take care of that qemu will happily connect to the user-end of
the configured tap device without requiring any special privileges::
qemu -net nic -net tap,ifname=tap0
> All someone has to do is write an /etc/qemu-ifup and /etc/qemu-ifdown
> that create a bridged interface. I'd be happy to take patches to pass
> additional parameters to the script. For instance, you could do:
>
> -net tap,mode=bridging,if=eth0
The KVM package on Ubuntu is configured to run this tap configuration
script by default::
#!/bin/sh
switch=$(ip route ls | awk '/^default / { for(i=0;i<NF;i++) { if
($(i) == "dev") print $(i+1) }}')
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif ${switch} $1
exit 0
Trouble is, that doesn't work without root privileges, and I understand
running qemu with root privileges isn't a really good idea given it's
complexity.
> And it could Just Work. /etc/qemu-ifup and /etc/qemu-ifdown would have
> to be setuid helpers of course and they should enforce some sort of
> group access control.
If I understand correctly even if qemu-ifup/qemu-ifdown were setuid
helpers qemu would still need root privileges to create tap devices. You
have to set that up before you launch qemu.
> AFAIK, VDE doesn't actually get a tap file descriptor. Instead it sends
> all traffic to a daemon for processing. This implies that performance
> will never be as good as tap.
Thats true. The file descriptor VDE passes to qemu is to a unix socket
connected to an instance of the vde_switch daemon.
In most usage scenarios vde_switch handling packets in userspace is
probably not going to be the bottleneck. In a simple test (e.g., ping -f
-s 31000) I manage to shovel 90Mbit/s full duplex through a single VDE
switch. Granted if I connect the guest directly to the tap interface my
test maxes out at 160Mbit/s full duplex so there is definitely a
performance penalty involved.
Cheers,
Liraz
- [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Liraz Siri, 2008/12/24
- Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Samuel Thibault, 2008/12/24
- Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Alexey Eremenko, 2008/12/24
- Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Paul Brook, 2008/12/24
- Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, C . W . Betts, 2008/12/24
- Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Avi Kivity, 2008/12/25
- Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Avi Kivity, 2008/12/25
- Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Liraz Siri, 2008/12/25
- Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Avi Kivity, 2008/12/25
- Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Avi Kivity, 2008/12/25
Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Jamie Lokier, 2008/12/24
Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?, Anthony Liguori, 2008/12/24