[libvirt] [Qemu-devel] virDomainBlockJobAbort and block_job_cancel

[Eric Blake]

On 12/07/2011 03:35 PM, Adam Litke wrote:
> Stefan's qemu tree has a block_job_cancel command that always acts
> asynchronously.  In order to provide the synchronous behavior in libvirt (when
> flags is 0), I need to wait for the block job to go away.  I see two options:
> 
> 1) Use the event:
> To implement this I would create an internal event callback function and
> register it to receive the block job events.  When the cancel event comes in, I
> can exit the qemu job context.  One problem I see with this is that events are
> only available when using the json monitor mode.

I like this idea.  We have internally handled events before, and limited
it to just JSON if that made life easier: for example, virDomainReboot
on qemu is rejected if you only have the HMP monitor, and if you have
the JSON monitor, the implementation internally handles the event to
change the domain state.

Can we reliably detect whether qemu is new enough to provide the event,
and if qemu was older and did not provide the event, do we reliably know
that abort was blocking in that case?

It's okay to make things work that used to fail, but it is a regression
to make blocking job cancel fail where it used to work, so rejecting
blocking job cancel with HMP monitor is not a good idea.  If we can
guarantee that all qemu new enough to have async cancel also support the
event, while older qemu was always blocking, and that we can always use
the JSON monitor to newer qemu, then we're set - merely ensure that we
use only the JSON monitor and the event.  But if we can't make the
guarantees, and insist on supporting newer qemu via HMP monitor, then we
may need a hybrid combination of options 1 and 2, or for less code
maintenance, just option 2.

> 
> 2) Poll the qemu monitor
> To do it this way, I would write a function that repeatedly calls
> virDomainGetBlockJobInfo() against the disk in question.  Once the job
> disappears from the list I can return with confidence that the job is gone.
> This is obviously sub-optimal because I need to poll and sleep.

We've done this before, for both HMP and JSON - see
qemuMigrationWaitForCompletion.  I agree that an event is nicer than
polling, but we may be locked into this.

> 
> 3) Ask Stefan to provide a synchronous mode for the qemu monitor command
> This one is the nicest from a libvirt perspective, but I doubt qemu wants to add
> such an interface given that it basically has broken semantics as far as qemu is
> concerned.

Or even:

4) Ask Stefan to make the HMP monitor command synchronous, but only
expose the JSON command as asynchronous.  After all, it is only HMP
where we can't wait for an event.

> 
> If this is all too nasty, we could probably just change the behavior of
> blockJobAbort and make it always synchronous with a 'cancelled' event.

No, we can't change the behavior without breaking back-compat of
existing clients of job cancellation.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20111207/1a9c471d/attachment-0001.sig>