qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine


From: Paolo Bonzini
Subject: Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?
Date: Mon, 21 Jul 2014 12:22:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

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 via email to

[Prev in Thread] Current Thread [Next in Thread]