On 02/26/2018 08:05 PM, Liang Li wrote:
When doing drive mirror to a low speed shared storage, if there was heavy
BLK IO write workload in VM after the 'ready' event, drive mirror block job
can't be canceled immediately, it would keep running until the heavy BLK IO
workload stopped in the VM.

Libvirt depends on the current block-job-cancel semantics, which is that
when used without a flag after the 'ready' event, the command blocks
until data is in sync.  However, these semantics are awkward in other
situations, for example, people may use drive mirror for realtime
backups while still wanting to use block live migration.  Libvirt cannot
start a block live migration while another drive mirror is in progress,
but the user would rather abandon the backup attempt as broken and
proceed with the live migration than be stuck waiting for the current
drive mirror backup to finish.

The drive-mirror command already includes a 'force' flag, which libvirt
does not use, although it documented the flag as only being useful to
quit a job which is paused.  However, since quitting a paused job has
the same effect as abandoning a backup in a non-paused job (namely, the
destination file is not in sync, and the command completes immediately),
we can just improve the documentation to make the force flag obviously
useful.

How does this interact with John's ongoing work to redo block job semantics:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg06167.html


Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Jeff Cody <jc...@redhat.com>
Cc: Kevin Wolf <kw...@redhat.com>
Cc: Max Reitz <mre...@redhat.com>
Cc: Eric Blake <ebl...@redhat.com>
Cc: John Snow <js...@redhat.com>
Reported-by: Huaitong Han <huanhuait...@didichuxing.com>
Signed-off-by: Huaitong Han <huanhuait...@didichuxing.com>
Signed-off-by: Liang Li <liliang...@didichuxing.com>
---

But in isolation, the patch looks reasonable to me.

Reviewed-by: Eric Blake <ebl...@redhat.com>

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Reply via email to