[libvirt PATCH 00/16] Add support for persistent mediated devices

[Daniel P. Berrangé]

On Fri, Jul 17, 2020 at 10:08:59AM +0200, Erik Skultety wrote:
> On Thu, Jul 16, 2020 at 05:21:30PM -0500, Jonathon Jongsma wrote:
> > This patch series follows the previously-merged series which added support for
> > transient mediated devices. This series expands mdev support to include
> > persistent device definitions. Again, it relies on mdevctl as the backend.
> >
> > It follows the common libvirt pattern of APIs by adding the following new APIs
> > for node devices:
> >     - virNodeDeviceDefineXML() - defines a persistent device
> >     - virNodeDeviceUndefine() - undefines a persistent device
> >     - virNodeDeviceCreate() - starts a previously-defined device
> >
> > It also adds virsh commands mapping to these new APIs: nodedev-define,
> > nodedev-undefine, and nodedev-start.
> >
> > The method of staying up-to-date with devices defined by mdevctl is currently a
> > little bit crude due to the fact that mdevctl does not emit any events when new
> > devices are added or removed. As a workaround, we create a file monitor for the
> > mdevctl config directory and re-query mdevctl when we detect changes within
> > that directory. In the future, mdevctl may introduce a more elegant solution.
> 
> In general, I don't think it is desirable for libvirt to monitor the
> configuration directory for changes made outside of libvirt and expect libvirt
> to keep up with the new configuration and still be able manage the device.
> I'd say that we only manage devices that we created and have control over.
> Everything else is outside libvirt's scope to handle (the same goes for
> persistent device removals).
> If a device cannot be created, because mdevctl already has a colliding device
> that was created outside of libvirt, we should document that the user is
> expected to remove the device configuration and re-create it with libvirt -
> let's say mdevctl adds support for an alternative config dir, how does libvirt
> know it should monitor that one instead /etc/mdev.d?

On daemon startup, libvirt is going to scan the directory and detect
everything in it regardless who/what created it. So that would mean
we need a restart to pick up externally made changes. This is already
true for config files libvirt owns of course in /etc/libvirt, but it
is not unreasonable to use file monitor to do live updates.

It is unlikely people will be using both libvirt and direct mdevctl
to create devices - they're likely to exclusively use one or the other.
IN particular there's likely already apps that exist and call mdevctl
directly to persist devices, and it is fairly desirable that libvirt
can see those I think, even if we think the apps should switch to using
these new libvirt aps.

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