On Mon, Jul 30, 2012 at 06:33:54PM -0600, Jim Fehlig wrote: > Laine Stump wrote: > > The way that I think the problem should be solved is this: > > > > 1) All of the network-related functionality in the system instance of > > libvirt that is used by the qemu, lxc, etc. drivers internal to libvirt > > (including the nwfilter subsystem, and everything in bridge_driver.c) > > should be in a separate daemon from libvirtd, and made available via RPC > > with a public API that uses policykit for authorization/authentication, > > with separate selinux policies from libvirtd; maybe call it > > "libvirt-networkd". > > > > 2) When the system instance of libvirtd is creating a domain, it should > > call to libvirt-networkd via this API to do things like create a tap > > device, connect it to a bridge, add nwfilter rules, etc. > > > > 3) likewise, when a session (unprivileged) instance of libvirt is > > creating a domain, it also should call the same APIs, which (after > > proper authentication/authorization via policykit) will connect it to > > the privileged libvirt-networkd (or whatever its called) to perform the > > operation. > > > > I wonder if the quantum project [1], which IIUC provides a lot of the > functionality you describe, could be used as "libvirtd-networkd". Not as long its its a big mass of python. On the contrary, Quantum could use libvirt's APIs. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list