qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [libvirt] How to best handle the reoccurring of rom cha


From: Philipp Hahn
Subject: Re: [Qemu-devel] [libvirt] How to best handle the reoccurring of rom changes breaking cross version migrations?
Date: Fri, 3 Nov 2017 18:16:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

Hello

Am 03.11.2017 um 08:30 schrieb Christian Ehrhardt:
> On Thu, Nov 2, 2017 at 4:34 PM, Daniel P. Berrange <address@hidden> wrote:
>>
>> On Thu, Nov 02, 2017 at 04:14:06PM +0100, Christian Ehrhardt wrote:
>>> Ping - since there wasn't any reply so far - any best practices one could
>>> share?
>>>
>>> Let me add a TL;DR:
>>> - bump of ipxe rom versions change the size of virtio-net-pci.rom
>>> - that breaks on migration "Length mismatch"
>>>
>>> I'd guess the size of that rom has to be fixed up on the fly, but if that
>>> is really ok and how/where is the question.
>>
>> The actual ROM contents will be transferred in the migration stream, so
>> the fact that the target host has ROMs with different content is not
>> important. The key thing that matters is that QEMU the target host loads
>> the ROMs at the same location, so that when the ROM contents is overwritten
>> with data from the incoming migration scheme, it all ends up at the same
>> place as it was on the source.
> 
> 
> Thanks Daniel for your answer, although you try to kill my remaining
> hopes of a better solution :-)
> But if the actual ROM content is migrated over anyway "all I'd have to
> do" is to make clear that the newer system (qemu) knows that the
> incoming rom has a different size than it thinks.
> I thought that was what the machine types and their mechanisms were
> for, but so far I only scratched like 10% of those - maybe they don't
> cover these rom sizes?

The problem is that libvirt launches a qemu process without knowing
those details.
Later when you try to restore an old snapshot or try to do a live
migration, the newly spawned qemu process must have the same layout to
be able to load the old VMState.

Qemu has gone through several such changes and is worsened by the fact,
that distributions like Debian use their own ROM files, which might be
different from the sizes shipped with Qemu.
For that reason we (Univention) still ship the old ROM images next to
the new ones and carry the attached patch to switch between them based
on the model. Maybe that works for you, too.

One more warning (we experiences): Even if the sizes are the same, live
migration can still fail afterwards: We have observed several cases,
where a migrated VM carried an old version of SeaBIOS, which fails when
you reboot the VM. We traced that down to Qemu implementing a new
feature (SMM), which was not supported by the old SeaBIOS and then got
it wrong after reboot only.

Hope that helps.

Philipp

Attachment: 0002-Bug-24702-Rom-file-compatibility.quilt
Description: Text document


reply via email to

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