On Thu, Mar 23, 2017 at 12:56:10 -0500, Eric Blake wrote:
On 03/15/2017 11:37 AM, Peter Krempa wrote:
> The new API can be used to configure the threshold when
> VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD should be fired.
> ---
[...]
> + * This event allows to use thin-provisioned storage which
needs management
> + * tools to grow it without the need for polling of the data.
> + *
> + * Returns 0 if the operation has started, -1 on failure.
> + */
> +int
> +virDomainSetBlockThreshold(virDomainPtr domain,
> + const char *dev,
> + unsigned long long threshold,
> + unsigned int flags)
Hmm. Because the threshold resets once the event fires, we don't have a
handy way to say 'set a threshold 100M or 10% further out than the last
limit). That would be a reason for using flags, although I don't think
we need to worry about it for now.
Does setting the threshold lower than the current high-water mark (as
reported by polling block status information) immediately fire an event,
or will an event never fire in that situation?
It will fire once the hypervisor writes beyond the threshold. If you set
it lower than the previous event, it will fire on the next write.
> @@ -6048,6 +6056,13 @@ enum remote_procedure {
> * @generate: both
> * @acl: none
> */
> - REMOTE_PROC_DOMAIN_EVENT_BLOCK_THRESHOLD = 385
> + REMOTE_PROC_DOMAIN_EVENT_BLOCK_THRESHOLD = 385,
> +
> + /**
> + * @generate: both
> + * @acl: domain:write
This doesn't modify the domain. Why does it need domain:write; wouldn't
domain:read be sufficient (namely, the same privileges you already
require for polling block status information to learn the current high
water mark)?
Since this api is setting the watermark level I don't feel it's right to
allow it using read-only connection.