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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list