Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?

[Alex Bligh]

Paolo,

On 19 Jul 2014, at 11:53, Paolo Bonzini <address@hidden> wrote:

>>> No, the old one is _always_ the correct one.
>>> 
>>> The pxe-* ROMs must be 128k, the efi-* ROMs must be 256k.
>> 
>> On 12.04
>> # ls -la /usr/share/qemu/pxe-virtio.rom
>> -rw-r--r-- 1 root root 63488 Jun 12 23:23 /usr/share/qemu/pxe-virtio.rom
>> 
>> On 14.04 (after resolving a pile of symlinks)
>> # ls -la /usr/lib/ipxe/qemu/pxe-virtio.rom
>> -rw-r--r-- 1 root root 83968 Jan  6  2014 /usr/lib/ipxe/qemu/pxe-virtio.rom
>> 
>> I'm guessing the ROM size gets rounded up to the next power of 2, hence
>> the ROM size on 12.04 is 64k, and on 14.04 is 128k, right?
>> 
>> So it would appear that if the length is actually coming from the
>> length of the file on disk, that on 12.04 the pxe-ROM is not 128k
>> but 64k. So if 'pxe-* ROMs must be 128k' is correct, I'm not sure
>> that's incompatible with  'the old one is _always_ the correct
>> one'.
> 
> Sorry, pxe-virtio.rom must be 64k.  It's pxe-e1000.rom that is 128k
> because it exceeds 64k by a little:

OK, well it has naughtily grown quite a bit on Ubuntu 14.04 as
above. That's easily fixable.

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

>> However, after the block migration is finished, I now see:
>> 
>> Receiving block device images
>> Completed 100 %
>> Unknown savevm section type 255
>> load of migration failed
> 
> This could be another incompatibility between qemu-kvm and qemu.  I know
> we had a couple in Fedora.
> 
>> 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).

Currently my idea is 'gdb' :-)

> 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. I actually
need it to be compatible with Ubuntu's qemu-kvm pc-1.0 which might
of course be different again :-/

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

> But in 2 years you will have to endure roughly the same
> pain.

I am aware of this.

-- 
Alex Bligh