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.
Oops, I somehow overlooked these two instances. New patch 2.5/3 should
fix them.
Jirka