When cancelling migration we can see the following conversation on QMP
monitor:
{"execute":"migrate_cancel","id":"libvirt-33"}
{"timestamp": {"seconds": 1432899178, "microseconds":
844907}, "event":
"MIGRATION", "data": {"status": "cancelling"}}
{"return": {}, "id": "libvirt-33"}
{"timestamp": {"seconds": 1432899178, "microseconds":
845625}, "event":
"MIGRATION", "data": {"status": "failed"}}
{"timestamp": {"seconds": 1432899178, "microseconds":
846432}, "event":
"MIGRATION", "data": {"status": "cancelled"}}
That is, migration status first changes to "failed" just to change to
the correct "cancelled" state in a few moments later. However, this is
enough to let libvirt report migration failed for unknown reason instead
of having been cancelled by a user.
This should really be fixed in QEMU but I'm not sure how easy it is.
However, it's pretty easy for us to work around it.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
Notes:
Version 2:
- new patch
src/qemu/qemu_process.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 0427e5d..8575d90 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -1515,6 +1515,7 @@ qemuProcessHandleMigrationStatus(qemuMonitorPtr mon
ATTRIBUTE_UNUSED,
void *opaque ATTRIBUTE_UNUSED)
{
qemuDomainObjPrivatePtr priv;
+ qemuDomainJobInfoPtr jobInfo;
virObjectLock(vm);
@@ -1529,7 +1530,15 @@ qemuProcessHandleMigrationStatus(qemuMonitorPtr mon
ATTRIBUTE_UNUSED,
goto cleanup;
}
- priv->job.current->status.status = status;
+ jobInfo = priv->job.current;
+ if (status == QEMU_MONITOR_MIGRATION_STATUS_ERROR &&
+ jobInfo->status.status == QEMU_MONITOR_MIGRATION_STATUS_CANCELLING) {
+ VIR_DEBUG("State changed from \"cancelling\" to
\"failed\"; setting "
+ "current state to \"cancelled\"");
+ status = QEMU_MONITOR_MIGRATION_STATUS_CANCELLED;
+ }
+
+ jobInfo->status.status = status;
virDomainObjSignal(vm);
cleanup:
--
2.4.1