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. 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. 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 ? Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
