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

[Vangelis Koukis <vkoukis@grnet.gr>]

[-- Attachment #1: Type: text/plain, Size: 3229 bytes --]

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.

> > Regarding different package versions of qemu-kvm, it seems migrations do
> > not work from source 0.12.5 to any other version *even* if -M pc-0.12 is
> > specified at the incoming KVM process. For versions >= 1.0 everything
> > works provided the machine type on the destination is the same as on the
> > source.
> 
> Some older versions of QEMU were buggy causing the machine type to
> not correctly preserve ABI.
> 
> > Our goal is to patch Ganeti [2] so that it sets the destination machine
> > type to that of the source specifically, ensuring migrations work
> > seamlessly after a KVM upgrade. Is there a way to retrieve the machine
> > type of a running KVM process through a monitor command?
> 
> IIRC there is not a monitor command for this.>

> The general approach
> to dealing with migration stability should be to launch QEMU with a
> canonical hardware configuration. This means explicitly setting a machine
> type, CPU model and PCI/USB devices addresses upfront. NB you should not
> use 'pc' as a machine type - if you query the list of machine types from
> QEMU, it will tell you what 'pc' corresponds to (pc-1.2) and then use the
> versioned type so you have a known machine type.
> 

This is exactly what we're trying to do: specify "-M" explicitly in the
kvm command line, instead of letting the default "pc" machine type
change arbitrarily whenever the qemu-kvm package gets upgraded.

Thanks again,
Vangelis.

-- 
Vangelis Koukis
vkoukis@grnet.gr
OpenPGP public key ID:
pub  1024D/1D038E97 2003-07-13 Vangelis Koukis <vkoukis@cslab.ece.ntua.gr>
     Key fingerprint = C5CD E02E 2C78 7C10 8A00  53D8 FBFC 3799 1D03 8E97

Only those who will risk going too far
can possibly find out how far one can go.
        -- T.S. Eliot

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]