11:25 a.m.
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 :|