Re: [Qemu-devel] [okeanos-dev] Re: KVM versions, machine types and failed migrations

[Daniel P. Berrange]

On Wed, Jan 09, 2013 at 03:27:53PM +0200, Vangelis Koukis wrote:
> On Wed, Jan 09, 2013 at 01:10:45pm +0000, Daniel P. Berrange wrote:
> > When doing migration, the fundamental requirement is that the guest
> > OS visible machine ABI must not change. Thus there are three key
> > things to take care of when launching QEMU on the migration target
> > host.
> > 
> >  - The device PCI/USB addresses must be identical to the source
> >  - The machine type must be identical to the source
> >  - The CPU model must be identical to the source
> > 
> 
> Thanks for the detailed list of requirements, we'll take it into account
> for the relevant Ganeti patch.
> 
> > If you don't follow those requirements, either QEMU or the guest OS
> > or both will crash & burn during migration & you get to keep both
> > pieces :-)
> > 
> 
> My point is, are these requirements left up to the caller of "kvm
> -incoming" to satisfy? Since the migration will most probably break,
> wouldn't it be best for QEMU to detect this and complain loudly, instead
> of continuing with the migration, failing silently and destroying the
> VM?
> 
> Sure there could be some "yes, do it, I know it is going to break"
> option, which will make QEMU proceed with the migration. However, in 99%
> of the cases this is just user error, e.g. the user has upgraded the
> version on the other end and has not specified -M explicitly. It would
> be best if QEMU was able to detect and warn the user about what is going
> to happen, because it does lead to the VM dying.

What you describe is certainly desirable, but it is quite hard to achieve
with current QEMU. Much of the work with moving to the new QEMU object
model & configuration descriptions has been motivated by a desire to
enable improvements migration handling. As you suggest, the goal is that
the source QEMU be able to send a complete & reliable hardware description
to the destination QEMU during migration.It is getting closer, but we're
not there yet.

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 :|