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". Regards, Jim [1] https://github.com/openstack/quantum -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list