On 05/14/14 13:30, Jiri Denemark wrote: > 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@xxxxxxxxxx> >>> --- >>> 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. Yep, ACK to this patch as 2.5 fixes the stuff. > > Jirka > Peter
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list