Re: [libvirt] [PATCH] BlockJob: Support sync/async virDomainBlockJobAbort
On Wed, Jan 18, 2012 at 12:59:29PM -0500, Federico Simoncelli wrote:
----- 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?
We just raise the events we receive from qemu and qemu will always generate
these. IMO, there is no harm in always raising the events. If a user doesn't
care about them, then they don't have to register for notifications.
> 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?
Any operation that needs to issue a monitor command would block. This is a
large list. That being said, the existing implementation already has this
potential issue with the ASYNC flag being the workaround.
I cannot answer definitively as to whether all libvirt async tasks can block. I
suspect the answer depends on whether the operation relies on a monitor command
that can block in qemu. As far as I know the only other command like this
(coincidentally it is being improved in qemu by Luiz) is virDomainMemoryStats().
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center