On 10/26/12 23:52, Eric Blake wrote:
On 10/26/2012 07:08 AM, Peter Krempa wrote:
On 10/23/12 04:10, Eric Blake wrote:
Since libvirt drops locks between issuing a monitor command and
getting a response, it is possible for libvirtd to be restarted
before getting a response on a drive-reopen command; worse, it is
also possible for the guest to shut itself down during the window
while libvirtd is down, ending the qemu process. A management app
needs to know if the pivot happened (and the destination file
contains guest contents not in the source) or failed (and the source
file contains guest contents not in the destination), but since
the job is finished, 'query-block-jobs' no longer tracks the
status of the job, and if the qemu process itself has disappeared,
even 'query-block' cannot be checked to ask qemu its current state.
This is mainly a problem for the RHEL 6.3 drive-reopen command; which
partly explains why upstream qemu 1.3 abandoned that command and
went with block-job-complete plus persistent bitmap instead. At
the time of this patch, the design for persistent bitmap has not
been clarified, so a followup patch will be needed once we actually
figure out how to use the qemu 1.3 interface.
If we surround 'drive-reopen' with a pause/resume pair, then we can
guarantee that the guest cannot modify either source or destination
files in the window of libvirtd uncertainty, and the management app
is guaranteed that either libvirt knows the outcome and reported it
correctly; or that on libvirtd restart, the guest will still be
paused and that the qemu process cannot have disappeared due to
guest shutdown; and use that as a clue that the management app must
implement recovery protocol, with both source and destination files
still being in sync and with 'query-block' still being an option as
part of that recovery. My testing of the RHEL 6.3 implementation
of 'drive-reopen' show that the pause window will typically be only
a fraction of a second.
* src/qemu/qemu_driver.c (qemuDomainBlockPivot): Pause around
drive-reopen.
(qemuDomainBlockJobImpl): Update caller.
---
src/qemu/qemu_driver.c | 37 +++++++++++++++++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)
ACK with rhel stuff in, but should/could be dropped if we will support
only the upstream functionality.
I will keep the commit (mostly) as-is, but touch up the commit message.
That is, with the current state of qemu.git, we STILL have to pause the
guest, since Paolo has not completed the persistent bitmap design. I'm
not sure if he will get that done by qemu 1.3; if he does, we can
revisit this code as part of using his persistent bitmap, if he doesn't,
then I'd rather have this code be safe out-of-the-box.
Ah; Fair enough.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list