[libvirt] RFC: exposing qemu's block-set-write-threshold

[Daniel P. Berrange]

On Mon, May 18, 2015 at 02:28:09PM -0600, Eric Blake wrote:
> I'm trying to wire up libvirt to do event reporting based on qemu 2.3's
> BLOCK_WRITE_THRESHOLD event. Doing this will allow management
> applications to do event-based notification on when to enlarge LVM (or
> other) storage underlying a qcow2 volume, rather than their current
> requirement to frequently poll block statistics.  But I'm stuck on the
> best way to expose the new parameter:
> 
> One idea is to treat it as part of the domain XML, and have
> virDomainSetBlockIoTune add one more typed parameter for a disk's
> current write threshold.  Doing this could allow setting a threshold
> even for an offline domain (although the threshold is only meaningful
> for a running domain), but might get weird because qemu's event is
> one-shot (you have to re-arm a new threshold every time an existing
> threshold fires - so every time it fires, the domain XML is rewritten,
> even though it is not guest-visible ABI that was changing).  At least
> with this approach, it is also easy for a client to poll the current
> setting of the threshold, via virDomainGetBlockIoTune.  But the
> threshold isn't quite a tuning parameter (it isn't throttling how fast
> the guest can write to the block device, only how full the host side can
> get in order to allow transparent resizing of the host storage prior to
> running out of space).

The issue of re-arming strongly suggests to me that setting in the
XML is not appropriate, /unless/ we have it somehow described such
that libvirt itself is able to automatically re-arm, but I don't
see an obvious way to do that without encoding a policy in libvirt.
So it feels more like something that should merely be a runtime
tunable with APIs to set/get against a running guest, and leave
the XML out of it.

> I'm also worried about what happens across libvirtd restarts - if the
> qemu event fires while libvirtd is unconnected, should libvirt be
> tracking that a threshold was registered in the XML, and upon
> reconnection check if qemu still has the threshold?  If qemu no longer
> has a threshold, then libvirt can assume it missed the event, and
> generate one as part of reconnecting to the domain.

If libvirtd restarts, applications have to reconnect to libvirt. We
could say that the application is required to re-register any thresholds
it wants, even if the guest is still running, but it might be more
pleasant for libvirt to take care of this and emit any missed event
itself.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|