Paolo Bonzini points out that in my refactoring of the code for
virDomainMigrate(), I added a check for the return value from
virDomainMigratePerform(). The problem is that we don't want to
exit if we fail, we actually want to go on and do
virDomainMigrateFinish2() with a non-0 return code to clean things
up. Remove the check.
While reproducing this issue, I also noticed that we wouldn't
always properly propagate an error message. In particular, I
found that if you blocked off the migration ports (with iptables)
and then tried the migration, it would actually fail but we would
get no failure output from Qemu. Therefore, we would think we
succeeded, and leave a huge mess behind us. Execute the monitor
command "info migrate", and look for a failure string in there
as well.
Signed-off-by: Chris Lalancette <clalance(a)redhat.com>
---
src/libvirt.c | 2 --
src/qemu_driver.c | 15 +++++++++++++++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index ca8e003..5c1efb6 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -2962,8 +2962,6 @@ virDomainMigrateVersion2 (virDomainPtr domain,
*/
ret = domain->conn->driver->domainMigratePerform
(domain, cookie, cookielen, uri, flags, dname, bandwidth);
- if (ret == -1)
- goto done;
/* In version 2 of the migration protocol, we pass the
* status code from the sender to the destination host,
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index eb22940..772f2f9 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -6956,6 +6956,21 @@ qemudDomainMigratePerform (virDomainPtr dom,
goto cleanup;
}
+ /* it is also possible that the migrate didn't fail initially, but
+ * rather failed later on. Check the output of "info migrate"
+ */
+ VIR_FREE(info);
+ if (qemudMonitorCommand(vm, "info migrate", &info) < 0) {
+ qemudReportError (dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ "%s", _("could not get info about
migration"));
+ goto cleanup;
+ }
+ if (strstr(info, "fail") != NULL) {
+ qemudReportError (dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ _("migrate failed: %s"), info);
+ goto cleanup;
+ }
+
/* Clean up the source domain. */
qemudShutdownVMDaemon (dom->conn, driver, vm);
paused = 0;
--
1.6.0.6
Show replies by date
On 08/28/2009 04:55 PM, Chris Lalancette wrote:
While reproducing this issue, I also noticed that we wouldn't
always properly propagate an error message. In particular, I
found that if you blocked off the migration ports (with iptables)
and then tried the migration, it would actually fail but we would
get no failure output from Qemu. Therefore, we would think we
succeeded, and leave a huge mess behind us. Execute the monitor
command "info migrate", and look for a failure string in there
as well.
ACK! Thanks for reproducing my precise failure mode, too, especially
since it turned out to be a second bug.
Paolo
Paolo Bonzini wrote:
On 08/28/2009 04:55 PM, Chris Lalancette wrote:
> While reproducing this issue, I also noticed that we wouldn't
> always properly propagate an error message. In particular, I
> found that if you blocked off the migration ports (with iptables)
> and then tried the migration, it would actually fail but we would
> get no failure output from Qemu. Therefore, we would think we
> succeeded, and leave a huge mess behind us. Execute the monitor
> command "info migrate", and look for a failure string in there
> as well.
ACK! Thanks for reproducing my precise failure mode, too, especially
since it turned out to be a second bug.
Thanks, committed now.
--
Chris Lalancette