On Wed, May 14, 2014 at 11:08:28 +0200, Peter Krempa wrote:
On 05/13/14 15:44, Jiri Denemark wrote:
When qemu driver is polling for migration to finish (in qemuMigrationWaitForCompletion), it may happen that another job allowed during migration is running and if it does not finish within 30 seconds, migration would be cancelled because of that. However, we can just ignore the timeout and let the waiting loop try again later.
If an event fired at the end of migration is ever implemented in QEMU, we can just wait for the event instead of polling for migration status and libvirt will behave consistently, i.e., migration won't be cancelled in case another job started during migration takes long time to finish.
For bug https://bugzilla.redhat.com/show_bug.cgi?id=1083238
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> --- src/qemu/qemu_domain.c | 10 ++++++---- src/qemu/qemu_migration.c | 7 ++++--- 2 files changed, 10 insertions(+), 7 deletions(-)
The code in this patch looks good, but while inspecting the callers of qemuDomainObjEnterMonitorAsync I found two other places that store the value of the call and then possibly return it. I think that qemuProcessStartCPUs() and qemuProcessStopCPUs() should convert the value back to -2 so that we don't have to make sure that everything deals okay with that.
Oops, I somehow overlooked these two instances. New patch 2.5/3 should fix them. Jirka