On Thu, Mar 23, 2017 at 14:34:04 -0500, Eric Blake wrote: > On 03/15/2017 11:37 AM, Peter Krempa wrote: > > Add a simple wrapper which will allow to set the threshold for > > delivering the event. > > --- > > tools/virsh-domain.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > tools/virsh.pod | 8 +++++++ > > 2 files changed, 72 insertions(+) [...] > > +=item B<domblkthreshold> I<domain> I<dev> I<threshold> > > + > > +Set the threshold value for delivering the block-threshold event. I<dev> > > +specifies the disk device target or backing chain element of given device using > > +the 'target[1]' syntax. I<threshold> is a scaled value of the offset. If the > > +block device should write beyond that offset the event will be delivered. > > + > > Should virsh check that the event is actually available from the server > (that is, that a registration for the event succeeds) before trying the > threshold? Or are we not worried about that? At the lower level, it is > reasonable to assume that any driver will either implement all or none > of the threshold setting and event in the same release, so if the > command succeeds, then you are right that the event should work. Hypervisors which don't support the event don't have this API implemented. Additionally the qemu implementation checks the capability prior to returning success here. This would catch only the case where somebody would do a botched backport of this. Since it's not a good idea to backport APIs I don't think that situation will ever happen.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
