Il 06/04/2012 17:28, Eric Blake ha scritto:
> I'm talking about the guest agent. It may make a difference, but cannot
> be the default, because you cannot trust the guest agent to be present.
> I'm thinking this will be like the --quiesce operation of
> snapshot-create, as another situation where
On 04/06/2012 09:19 AM, Paolo Bonzini wrote:
> Il 06/04/2012 06:36, Eric Blake ha scritto:
>> if
>> 'block_job_cancel' were made part of 'transaction', you could
>> copy multiple disks at the same point in time without pausing
>> the domain.
>
> This is doable.
>
> The transactioned command would
Il 06/04/2012 06:36, Eric Blake ha scritto:
> if
> 'block_job_cancel' were made part of 'transaction', you could
> copy multiple disks at the same point in time without pausing
> the domain.
This is doable.
The transactioned command would do a qemu_aio_flush() in the prepare
phase, and a normal b
On 04/06/2012 01:08 AM, Paolo Bonzini wrote:
> Il 06/04/2012 06:36, Eric Blake ha scritto:
>> If only qemu could get 'drive-reopen' inside 'transaction'...
>
> Just a quick answer to this: if qemu could get 'drive-reopen' inside
> 'transaction', the standalone command could be made safe just as ea
Il 06/04/2012 06:36, Eric Blake ha scritto:
> If only qemu could get 'drive-reopen' inside 'transaction'...
Just a quick answer to this: if qemu could get 'drive-reopen' inside
'transaction', the standalone command could be made safe just as easily.
In fact, in QEMU 1.1 the blockdev-snapshot-sync
This is the bare minimum to end a copy job (of course, until a
later patch adds the ability to start a copy job, this patch
doesn't do much in isolation; I've just split the patches to
ease the review).
This patch intentionally avoids SELinux, lock manager, and audit
actions, saving that for a lat
