qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: kvm@vger.kernel.org, qemu-devel@nongnu.org,
	okeanos-dev@lists.grnet.gr, synnefo-devel@googlegroups.com
Subject: Re: [Qemu-devel] KVM versions, machine types and failed migrations
Date: Wed, 9 Jan 2013 13:10:45 +0000	[thread overview]
Message-ID: <20130109131045.GI20716@redhat.com> (raw)
In-Reply-To: <20130109122350.GC13451@daedalus.cslab.ece.ntua.gr>

On Wed, Jan 09, 2013 at 02:23:50PM +0200, Vangelis Koukis wrote:
> Hello,
> 
> I'd like to ask a few questions about the way migrations work in KVM
> among different emulated machine types and different versions of the
> qemu-kvm package. I am sending to both the kvm@ and qemu-devel@ lists,
> please redirect me if I was wrong in doing so.
> 
> In a nutshell: while trying to live-migrate a VM on ~okeanos [1], we
> see VM migrations fail silently if going from kvm 1.0 to kvm 1.1.
> The source VM is frozen, "info migrate" on the source monitor reports
> success, but the VM is dead upon arrival on the destination process.
> Please see [3] for the exact package versions for qemu-kvm we have
> tested with.
> 
> Migration works if the destination kvm has been started with the same
> machine type as the source VM, e.g., using "-M pc-1.0" specifically on
> the destination, when migrating a pc-1.0 machine from kvm 1.0 to
> kvm 1.1.
> 
> How does the machine type specified with -M work in the case of
> migrations? Are migrations expected to fail if the machine type is
> different between source and destination process? If yes, shouldn't KVM be
> able to detect this and abort the migration instead of failing silently?

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

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

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

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

  reply	other threads:[~2013-01-09 13:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-09 12:23 [Qemu-devel] KVM versions, machine types and failed migrations Vangelis Koukis
2013-01-09 13:10 ` Daniel P. Berrange [this message]
2013-01-09 13:27   ` [Qemu-devel] [okeanos-dev] " Vangelis Koukis
2013-01-10  9:43     ` Daniel P. Berrange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130109131045.GI20716@redhat.com \
    --to=berrange@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=okeanos-dev@lists.grnet.gr \
    --cc=qemu-devel@nongnu.org \
    --cc=synnefo-devel@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).