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(a)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.
Peter