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
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 easily.
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
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 do a
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
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