[libvirt] [PATCH 3/3] qemu: Properly abort migration to a file

Jiri Denemark jdenemar at redhat.com
Thu May 22 17:58:15 UTC 2014


On Thu, May 22, 2014 at 18:33:08 +0200, Peter Krempa wrote:
> On 05/22/14 16:28, Jiri Denemark wrote:
> > On Thu, May 22, 2014 at 16:14:22 +0200, Peter Krempa wrote:
> >> On 05/22/14 13:55, Jiri Denemark wrote:
> >>> This is similar to the previous commit in that we need to explicitly
> >>> send migrate_cancel when libvirt detects an error other than those
> >>> reported by query-migrate. However, the possibility to hit such error is
> >>> pretty small.
> >>>
> >>> Signed-off-by: Jiri Denemark <jdenemar at redhat.com>
> >>> ---
> >>>  src/qemu/qemu_migration.c | 21 ++++++++++++++++++++-
> >>>  1 file changed, 20 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> >>> index ae18acb..5754f73 100644
> >>> --- a/src/qemu/qemu_migration.c
> >>> +++ b/src/qemu/qemu_migration.c
> >>> @@ -4704,6 +4704,7 @@ qemuMigrationToFile(virQEMUDriverPtr driver, virDomainObjPtr vm,
> >>>      int pipeFD[2] = { -1, -1 };
> >>>      unsigned long saveMigBandwidth = priv->migMaxBandwidth;
> >>>      char *errbuf = NULL;
> >>> +    virErrorPtr orig_err = NULL;
> >>>  
> >>>      /* Increase migration bandwidth to unlimited since target is a file.
> >>>       * Failure to change migration speed is not fatal. */
> >>> @@ -4806,8 +4807,17 @@ qemuMigrationToFile(virQEMUDriverPtr driver, virDomainObjPtr vm,
> >>>  
> >>>      rc = qemuMigrationWaitForCompletion(driver, vm, asyncJob, NULL, false);
> >>>  
> >>> -    if (rc < 0)
> >>> +    if (rc < 0) {
> >>> +        if (rc == -2) {
> >>> +            orig_err = virSaveLastError();
> >>> +            virCommandAbort(cmd);
> >>
> >> Shouldn't we abort the migration in qemu before killing the I/O helper?
> >> Qemu will get a sigpipe probably after we do that. Not sure wether
> >> that's worth dealing with as the migration is still going to fail.
> > 
> > Hmm, good question. Do we even need to abort I/O helper as I guess
> > cancelling the migration will result in EOF on the I/O helper's input?
> 
> Well and a counter-example is if qemu get's stuck, then you at least
> abort the iohelper and then get stuck a few lines below on the monitor.

Fair enough, I'll push the patch as-is. We don't really care if QEMU
aborts migration after the I/O helper is killed since we're going to
cancel it anyway.

Jirka




More information about the libvir-list mailing list