qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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]
     [not found]     ` <E71DFB2B-0B73-46AE-B423-0BF605A9D679@hotmail.com>
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).