Re: [libvirt] Redesigning Libvirt: Exploding the libvirtd architecture

The solution(s) =============== As noted above, we made some baby-steps towards a modular daemon architecture when we introduced virtlockd and virlogd. It is now time to fully commit to a modular design and explode libvirtd into a swarm of daemons each responsible for a clearly demarked task. Such a decomposition would naturally fall across the internal driver boundaries, giving a virtnwfilterd, virtnetworkd, virtstoraged, virtnodedevd, etc. We have to maintain compatibility with our existing client API implementation though. This libvirtd would have to still accept connections from the client and route the RPC request directly onto the modular daemon. We could also enhance the client API to directly know how to connect to the modular daemons, bypassing libvirtd. If we restricted the modular daemons to only concern themselves with local UNIX domain socket usage, we could then provide libvirtd as the bridge to remote TCP access, and for backcompat with legacy client library impls. [app] -> [libvirt.so] -> [libvirtd] becomes [app] -> [libvirt.so] -> [virthypervisord] +> [virtnetworkd] +> [virtstoraged] ...etc