qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/4] Add basic version of bridge helper


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 1/4] Add basic version of bridge helper
Date: Thu, 06 Oct 2011 13:04:21 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 10/06/2011 11:41 AM, Daniel P. Berrange wrote:
On Thu, Oct 06, 2011 at 11:38:25AM -0400, Richa Marwaha wrote:
This patch adds a helper that can be used to create a tap device attached to
a bridge device.  Since this helper is minimal in what it does, it can be
given CAP_NET_ADMIN which allows qemu to avoid running as root while still
satisfying the majority of what users tend to want to do with tap devices.

The way this all works is that qemu launches this helper passing a bridge
name and the name of an inherited file descriptor.  The descriptor is one
end of a socketpair() of domain sockets.  This domain socket is used to
transmit a file descriptor of the opened tap device from the helper to qemu.

The helper can then exit and let qemu use the tap device.

When QEMU is run by libvirt, we generally like to use capng to
remove the ability for QEMU to run setuid programs at all. So
obviously it will struggle to run the qemu-bridge-helper binary
in such a scenario.

With the way you transmit the TAP device FD back to the caller,
it looks like libvirt itself could execute the qemu-bridge-helper
receiving the FD, and then pass the FD onto QEMU using the
traditional tap,fd=XX syntax.

Exactly.  This would allow tap-based networking using libvirt session:// URIs.


The TAP device FD is only one FD we normally pass to QEMU. How about
support for vhost net ? Is it reasonable to ask the qemu-bridge-helper
to send back a vhost net FD also.

Absolutely.

Or indeed multiple vhost net FDs
when we get multiqueue NICs.  Should we expect the bridge helper to
be strictly limited to just connecting a TAP dev to a bridge, or is
the expectation that it will grow more&  more functionality over
time ?

I would not expect it to do more than create virtual network interfaces, and add them to bridges. Multiqueue virtual nics, vhost, etc. would all be in scope as they are part of creating a virtual network interface.

Creating the bridges and managing the bridges should be done statically by an administrator and would be out of scope.

Regards,

Anthony Liguori


Daniel




reply via email to

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