|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH] migration: adding migration to/from a file |
Date: | Tue, 20 Jan 2009 10:24:50 -0600 |
User-agent: | Thunderbird 2.0.0.19 (X11/20090105) |
Daniel P. Berrange wrote:
Does it matter if it blocks though ? Migrating to a file is not "live" migration anyway,
Yes. The general reason is that blocking in QEMU is evil because it's single threaded. If you block on IO in QEMU, then everything comes grinding to a halt. The VM may not be running, but you still want the GUI to be responsive, the monitor, and VNC to be responsive. This is particularly import in the context of asynchronous monitor notifications. savevm may be a long operation and there may be pending notifications that would get significantly delayed.
If you issue a "stop" before doing live migration, the result is equivalent to "savevm" from a binary perspective but the monitor will remain responsive during the whole operation. I'd like to eliminate the blocking version of savevm entirely but we're currently prevent from doing this because of the savevm to a disk. The issue is that you cannot write to the qcow2 snapshot space while other IO operations can happen. stop'ing the guest would prevent this (obviously) but it would be nice to support this in a truly live form.
I think we need to adjust the qcow2 snapshot format to support chaining of snapshot segments. That would allow a truly live save to qcow2.
Regards, Anthony Liguori
so if we happen to block the rest of the QEMU event loop during course of writing to the file it doesn't seemtoo serious. Or is there some scenario which badly breaks with blocking writes even for non-live usage ? Daniel
[Prev in Thread] | Current Thread | [Next in Thread] |