Re: [Qemu-devel] [libvirt] virDomainBlockJobAbort and block_job_cancel

[Stefan Hajnoczi]

On Thu, Dec 8, 2011 at 2:55 PM, Adam Litke <address@hidden> wrote:
> On Wed, Dec 07, 2011 at 04:01:58PM -0700, Eric Blake wrote:
>> 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?
>
> I think we can say that qemu will operate in one of two modes:
> a) Blocking abort AND event is not emitted
> b) Non-blocking abort AND event is emitted
>
> The difficulty is in detecting which case the current qemu supports.  I don't
> believe there is a way to query qemu for a list of currently-supported events.
> Therefore, we'd have to use version numbers.  If we do this, how do we avoid
> breaking users of qemu git versions that fall between official qemu releases?

I agree.  Checking version numbers is always problematic - distros may
backport features.

This isn't pretty but how about:

1. Issue block_job_cancel
2. Issue query-block-jobs and check if the job is there.
3. Check for QMP events (if applicable).
4. If the block job was visible then we must be async and need to
expect an event if we didn't already get one.
5. If the block job was not visible then it has been stopped.

Stefan