[libvirt] [PATCH v2 4/5] qemu: Don't report false error from MigrateFinish

Daniel P. Berrange berrange at redhat.com
Fri Jul 17 13:51:21 UTC 2015


On Fri, Jul 10, 2015 at 11:26:17AM +0200, Jiri Denemark wrote:
> virDomainMigrateFinish* APIs were unfortunately designed to return the
> pointer to the domain on destination and NULL on error. This looks OK in
> normal cases but the same API is also called when we know migration
> failed and thus we expect Finish to return NULL even if it actually did
> all it was supposed to do without any error. The call is defined to
> return nonnull domain pointer over RPC, which means returning NULL will
> always result in an error being send. If this was not in fact an error,
> the API itself wouldn't set anything to the thread local virError, which
> makes the RPC layer come up with it's own "Library function returned
> error but did not set virError" error.
> 
> This is quite confusing and also hard to detect by the caller. This
> patch adds a special error code which can be used to check that Finish
> successfully aborted migration.

FWIW, I have come to the conclusion that it is impossible to 100%
reliably detect successful from the virDomainMigrate* APIs, because
it is possible that the libvirt connection to the dest host may
fail, while the domain is in fact successfully running on the target.
So there is always the possbility to get a error from the RPC layer
despite everything at QEMU level being 100% successful.

So in openstack we now ignore the return code for virDomainMigrate
and instead try to detect succcess from the domain job info which
will show that the domain on the source has completed, even if we
loose the dest host RPC connection.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list