From: Liraz Siri <liraz@turnkeylinux.org>
To: qemu-devel@nongnu.org
Cc: turnkey-discuss@lists.turnkeylinux.org,
Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?
Date: Wed, 24 Dec 2008 22:52:22 +0200 [thread overview]
Message-ID: <4952A106.3050305@turnkeylinux.org> (raw)
In-Reply-To: <49525808.9080002@codemonkey.ws>
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
next prev parent reply other threads:[~2008-12-24 20:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-24 12:48 [Qemu-devel] Merging improvements from VirtualBox OSE into qemu? Liraz Siri
2008-12-24 13:17 ` Samuel Thibault
2008-12-24 13:26 ` Alexey Eremenko
2008-12-24 13:31 ` Alexey Eremenko
2008-12-24 13:36 ` Paul Brook
2008-12-24 14:33 ` Liraz Siri
2008-12-24 14:51 ` Jernej Simončič
2008-12-24 15:02 ` Paul Brook
2008-12-24 15:29 ` Liraz Siri
2008-12-24 15:40 ` Anthony Liguori
2008-12-24 20:52 ` Liraz Siri [this message]
2008-12-25 4:37 ` C.W. Betts
2008-12-25 4:37 ` C.W. Betts
2008-12-25 7:06 ` Avi Kivity
2008-12-25 7:07 ` Avi Kivity
2008-12-25 7:08 ` Avi Kivity
2008-12-25 14:51 ` Liraz Siri
2008-12-25 16:14 ` Avi Kivity
2008-12-24 23:18 ` Jamie Lokier
2008-12-25 7:11 ` Avi Kivity
2008-12-24 15:23 ` Anthony Liguori
2008-12-24 20:21 ` Liraz Siri
2008-12-24 20:55 ` Liraz Siri
2009-01-05 21:12 ` Frank Mehnert
2009-01-05 22:03 ` Stefan Weil
2009-01-05 23:58 ` Anthony Liguori
2009-01-06 7:41 ` Frank Mehnert
2009-01-06 15:46 ` Blue Swirl
2009-01-06 17:33 ` Anthony Liguori
2009-01-06 20:40 ` Frank Mehnert
2009-01-06 22:17 ` Jamie Lokier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4952A106.3050305@turnkeylinux.org \
--to=liraz@turnkeylinux.org \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
--cc=turnkey-discuss@lists.turnkeylinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.