qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

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