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: Anthony Liguori
Subject: Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?
Date: Wed, 24 Dec 2008 09:40:56 -0600
User-agent: Thunderbird 2.0.0.17 (X11/20080925)

Liraz Siri wrote:
Paul Brook wrote:

You need root privileges to load the random kernel modules required to d this. Not going to happen for qemu.

There's at least one counter-precedent. qemu takes advantage of kqemu
which is also a "random kernel module". How would supporting a kernel
module that simplified a bridged networking be any different?

I would object strongly to any new code in QEMU that was relying on a kernel module that had no chance of making it upstream.

FWIW, we could simplify bridged networking in QEMU but it would require root privileges or a setuid helper.

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

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.

Also, qemu seems to require root privileges to setup tap devices, so it
wouldn't be a first.

It does, but there's no reason we could extend tap just a little bit so that it got a file descriptor from the /etc/qemu-ifup script.

BTW, we don't need this for our own use. We setup VDE + tap devices
bridged to the network interface. Works great, at least for NICs that
support bridging.

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.

Regards,

Anthony Liguori




reply via email to

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