Re: [libvirt] [PATCH] BlockJob: Support sync/async virDomainBlockJobAbort
----- Original Message -----
From: "Adam Litke" <agl(a)us.ibm.com>
To: "Dave Allan" <dallan(a)redhat.com>
Cc: libvir-list(a)redhat.com
Sent: Friday, January 13, 2012 9:51:23 PM
Subject: [libvirt] [PATCH] BlockJob: Support sync/async virDomainBlockJobAbort
Qemu has changed the semantics of the "block_job_cancel" API.
Originally, the
operation was synchronous (ie. upon command completion, the operation
was
guaranteed to be completely stopped). With the new semantics, a
"block_job_cancel" merely requests that the operation be cancelled
and an event
is triggered once the cancellation request has been honored.
To adopt the new semantics while preserving compatibility I propose
the
following updates to the virDomainBlockJob API:
A new block job event type VIR_DOMAIN_BLOCK_JOB_CANCELLED will be
recognized by
libvirt. Regardless of the flags used with virDomainBlockJobAbort,
this event
will be raised whenever it is received from qemu. This event
indicates that a
block job has been successfully cancelled.
[...]
Without the VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC flag, libvirt will
internally poll
using qemu's "query-block-jobs" API and will not return until the
operation has
been completed.
Why do you raise the event VIR_DOMAIN_BLOCK_JOB_CANCELLED also in the
case where libvirt takes care of it internally?
Is there a specific use case for this?
API users are advised that this operation is
unbounded and
further interaction with the domain during this period may block.
Do you have an example of what operation may block?
Is this the common behavior for all the other async tasks that libvirt
is managing internally?
--
Federico