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

[Corey Bryant]

On 10/06/2011 02:04 PM, Anthony Liguori wrote:
> 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.

I'll take note of this.  It seems like it would be a nice future 
addition to libvirt.

A slight tangent, but a point on DAC isolation.  The helper enables DAC 
isolation for qemu:///session but we still need some work in libvirt to 
provide DAC isolation for qemu:///system.  This could be done by 
allowing management applications to specify custom user/group IDs when 
creating guests rather than hard coding the IDs in the configuration file.

> > 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

--
Regards,
Corey