Re: [Qemu-devel] [PATCH 7/8] block: add witness argument to drive-reopen

[Paolo Bonzini]

Il 14/04/2012 00:32, Eric Blake ha scritto:
> But if the world conspires against me, such as libvirt going down, then
> qemu completing the reopen, then the guest VM halting itself so that the
> qemu process goes away, all before libvirt restarts, then I'm stuck
> figuring out whether qemu finished the job (so that when I restart the
> guest, I want to pivot the filename) or failed the job (so that when I
> restart the guest, I want to revert to the source).  To do this, I now
> have to create a new file on disk (not a pipe), pass in the fd in
> advance, and then call drive-reopen, as well as record that filename as
> the location where I will look as part of trying to re-establish
> connections with the guest when libvirtd restarts.

Yes.

> I'm not quite sure how to expose this to upper-layer management
> applications when they are using libvirt transient guests, but that's
> not qemu's problem.

Do transient guests have persistent storage for them in /var while they
are running?

>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index 0bf3a25..2e5a925 100644
>> --- a/qapi-schema.json
>> +++ b/qapi-schema.json
>> @@ -1228,6 +1228,13 @@
>>  #
>>  # @format: #optional the format of the new image, default is 'qcow2'.
>>  #
>> +# @witness: A file descriptor name that was passed via getfd.  QEMU will 
>> write
> 
> Mark this #optional

Yes.

> Question - I know that 'drive-reopen' forces a block_job_cancel_sync()
> call before closing the source; how long can that take?

Not much; the mirroring job polls the dirty bitmap for new I/O every 100
ms, so it should be more or less comparable with the bdrv_drain_all that
is also performed by drive-reopen and blockdev-snapshot-sync.

> So that does mean that a call to 'drive-reopen' could indeed
> take a very long time from initially sending the monitor command before
> I finally get a response of success or failure, and that while the
> response will be accurate, the whole intent of this patch is that
> libvirt might not be around to get the response, so we want something a
> bit more persistent.  Does this mean that if we add 'drive-reopen' to
> 'transaction', that transaction will be forced to wait for
> block_job_cancel_sync?

Transactions are already waiting for pending I/O to complete
(bdrv_drain_all), and mirroring that I/O to the target
(block_job_cancel_sync) won't take much longer.

Paolo