[libvirt] Libvirt daemon split / VM shim progress

[Daniel P. Berrangé]

A update on progress splitting libvirtd into multiple daemons....

 * General refactoring of the RPC client/server

   This is about allowing libvirtd daemon to forward API calls to
   other daemons when there is no built-in driver. It also involves
   the remote client learning how to connect to other daemons.

   Working proof of concept which splits the secret driver into a
   separate daemon is available:

    https://www.redhat.com/archives/libvir-list/2018-April/msg01977.html

   The storage driver, interface driver and nodedev drivers can
   all also be split at this time. The nwfilter & network drivers
   require some work before they can be split.

   Still needs work around config files, and creating daemons for other
   drivers. I'm not proposing to merge this until all drivers are ready.
   I want to avoid a hybrid state where some drivers are split and some
   are not as that will be confusing and make upgrade path harder.

   Need to also consider if we'll mandate splitting of libvirtd, or
   provide a compile time option to continue  building a monolithic
   driver. We'll probably need the latter for at least a few years
   to avoid forcing a major architectural change on long-life distros
   that like to rebase.


 * Untangle storage driver from virt drivers

   This involved more the storage file code into separate loadable modules.
   This is merged and working

    https://www.redhat.com/archives/libvir-list/2018-April/msg02423.html


 * Untangle nwfilter driver from the virt drivers

   This involved creating new public APIs to provide the concept of a filter
   binding. This allows nwfilter driver to track all filters it has created.
   The virt drivers only talk to the nwfilter driver via the public API
   after this is done.

   Latest patch series is here:

    https://www.redhat.com/archives/libvir-list/2018-May/msg01145.html

   A few loose ends and testing needed, but largely feature complete and
   hopefully soon mergable


 * Untangle network driver from virt driver

   The virt drivers currently call into the network driver via a
   back channel using callbacks, rather than the public API. We
   will need to define some public APIs to allow creation and
   deletion of "network ports" from the virt driver. This will
   allow unprivilegd virt drivers to have real network access
   via privileged network driver.

   Also likely want to make the network driver responsible to
   setting up network filters when this is done. ie the virt
   driver will no longer directly use the nwfilter driver,
   instead the network driver will talk to the nwfilter driver.
   This will allow privileged network driver to enforce the
   use of nwfilters when giving ports to unprivileged virt
   drivers.

   No work started, but this what I'll tackle now the nwfilter stuff
   is largely wrapped up.


 * Move host device tracking into the node dev driver

   Currently we have a src/util/virhostdev.c file that tracks the
   state of SCSI, SCIVHost PCI, MDev, USB devices that are assigned
   to guests. This is part of the virt driver and needs to move into
   the node device driver in some way. Principally this will allow
   an unprivileged virt driver to use host devices via a privileged
   nodedev driver.

   Probably will involve creating some new virNodeDeviceXXXX APIs
   to deal with the operations required. Unclear exactly what they
   will look like, but need to be much simpler than the huge number
   of APIs that are in virhostdev.h currently.

   No work started, but Laine has indicated an interest in working
   on it. If not, I'll work on it once network stuff is under control


With all the above done we'll be able to have many daemons, one per
driver, with split privilege levels.

The virt driver daemons, however, would still be monolithic. The step
after that would be to look at how to allow a launching VMs via a simple
shim daemon, that then associates with the main virt daemon. We had done
some POC demos around that in the past, with some positive results

  https://www.redhat.com/archives/libvir-list/2017-December/msg00728.html

With the splitting of libvirtd, the need for a shim feels less urgent,
because the penalty of running one virtqemud per guest is lower than
the penalty of running one libvirtd per guest. None the less I still
think we want to try to build a shim, so that apps can directly connect
to the shim to run API operations, and just use the virtqemud for
central aggregation views. I'm not expecting todo anything on this
until the libvirtd is split, because that makes it easier todo the
shim without loosing functionality in the shim.

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 :|