All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?
Date: Mon, 21 Jul 2014 12:22:32 +0200	[thread overview]
Message-ID: <53CCE9E8.7070607@redhat.com> (raw)
In-Reply-To: <FD820C40-CB60-48E3-B6C6-BE6B51D8AE87@alex.org.uk>

Il 19/07/2014 13:37, Alex Bligh ha scritto:
>>> Whilst (per below) your workaround gets past the issue for this ROM,
>>> I'm confused about the numbers in the error message, as 64k and
>>> 128k do not equal 10,000 or 20,000:
>>> Length mismatch: 0000:00:03.0/virtio-net-pci.rom: 10000 in != 20000
>>
>> These are hexadecimal.
> 
> Have sent a patch to add '0x'

Thanks.

>>> My guess is this might be the bogus inclusion of PITCommonState
>>> per the last hunk of
>>> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20
>>>
>>> Is there a technique to debug this sort of thing?
>>
>> You can try using Amit's vmstate checker.
> 
> I think this requires a json output in the format given by -dump-vmstate
> (unless we're at cross purposes). qemu 1.0 does not produce such a JSON
> output. I only have the vmstate to go on (same problem exists if
> -S is used throughout so the VM never starts and without block migration).

You'd have to backport it, yes.

> Currently my idea is 'gdb' :-)

ghex too.  Add a printf at the end of every successful section load.

>> You could try rebuilding the patched QEMU sources from CentOS.  CentOS
>> 7's rhel6.1.0 or rhel6.2.0 machine types are comparable to pc-1.0, with
>> some luck they might even be compatible.
> 
> I think the issue is that there are at least two versions of pc-1.0 (or
> how the state is serialised); see the memory layout issues. I suspect
> both qemu-git and qemu-kvm had slightly different pc-1.0.

qemu 1.0 in theory has the same pc-1.0 as qemu 1.3 and newer.

qemu-kvm 1.0 is different.

> I actually
> need it to be compatible with Ubuntu's qemu-kvm pc-1.0 which might
> of course be different again :-/

Unlikely. :)

>>> Ubuntu is about to become tested (and a patch or workaround generated
>>> at least for migrations from 12.04 - the previous LTS version);
>>> whether or not it is upstreamed won't be up to me though.
>>
>> Yes, because Ubuntu hardly introduces any new feature during the LTS
>> support period.
> 
> My guess is they will take a non-intrusive SRU which provides the
> ability for live migrates to work. However, if not we will just
> maintain it out of tree (like we were doing for various other
> qemu bits).

Quite frankly: good luck.

Ubuntu has 1-2 people looking after QEMU (2-3 if you add Debian manpower).

RHEL sometimes has 5 people or more looking at migration bugs, and QE
tests machine types backwords compatibility periodically every six
months, so we never get into ugly situations or at least we can buy
ourselves a month to fix them.

Also, Ubuntu will have to choose between making 12.04->14.04 work and
making 14.04 (no updates) -> 14.04 (updated) work.

I'm not saying that Ubuntu sucks.  I'm just saying that there's only so
much that poor Serge can do.

Paolo

  reply	other threads:[~2014-07-21 10:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-18 23:33 [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix? Alex Bligh
2014-07-19  5:51 ` Paolo Bonzini
2014-07-19  7:10   ` Alex Bligh
2014-07-19  7:30     ` Paolo Bonzini
2014-07-19  8:43       ` Alex Bligh
2014-07-19  8:54         ` Peter Maydell
2014-07-19  8:59           ` Alex Bligh
2014-07-19 10:53         ` Paolo Bonzini
2014-07-19 11:37           ` Alex Bligh
2014-07-21 10:22             ` Paolo Bonzini [this message]
2014-07-21 13:59               ` Alex Bligh
2014-07-21 14:11                 ` Paolo Bonzini
2014-07-21 14:35                   ` Alex Bligh
2014-07-21 14:14                 ` Paolo Bonzini
2014-07-22  7:11             ` Amit Shah
2014-07-22  9:50               ` Amit Shah
2014-07-22  9:55                 ` Paolo Bonzini
2014-07-22 10:22                   ` Amit Shah
2014-07-22 10:32                     ` Alex Bligh
2014-07-22 10:54                       ` Amit Shah
2014-07-22 11:38                         ` Alex Bligh
2014-07-22 11:54                           ` Amit Shah
2014-07-22 12:12                             ` Paolo Bonzini
2014-07-22 12:19                               ` Alex Bligh
2014-07-22 12:47                                 ` Amit Shah
2014-07-22 12:40                               ` Amit Shah
2014-07-22 12:15                             ` Alex Bligh
2014-07-22 12:44                               ` Amit Shah

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=53CCE9E8.7070607@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=alex@alex.org.uk \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.