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

Daniel P. Berrange berrange at redhat.com
Wed May 20 12:28:10 UTC 2015

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

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

More information about the libvir-list mailing list