[libvirt] Redesigning Libvirt: Exploding the libvirtd architecture

[Daniel P. Berrange]

On Thu, Nov 23, 2017 at 11:32:14AM +0100, Michal Privoznik wrote:
> On 11/14/2017 06:26 PM, Daniel P. Berrange wrote:
> > 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
> > 
> 
> So what about remote connections? Say hostA is running my KVMs and hostB
> is where mgmt app lives. If hostB is connecting to hostA's libvirt I
> guess it's still going to be libvirtd which will then multiplex RPC
> calls and redirect them to correct daemon? IOW, if hostB calls
> virStoragePoolGetXMLDesc() how is this request going to end up at
> hostA's virstoraged?

Yes, for back-compat, we must aways have the single libvirtd around and
capable of acting as a pass-through proxy, even in the local-only case.
For the remote case, I think it is compelling to have libvirtd there
forever, such that libvirtd is the only daemon that uses TCP, TLS, etc
The modular daemons would be UNIX domain sockets only. This gives a
strong barrier between the functional areas and the remote RPC access.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|