[libvirt] How to best handle the reoccurring of rom changes breaking cross version migrations?

Christian Ehrhardt christian.ehrhardt at canonical.com
Fri Nov 3 07:30:42 UTC 2017


On Thu, Nov 2, 2017 at 4:34 PM, Daniel P. Berrange <berrange at redhat.com> 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?

>
> Getting this to happen requires pre-planning when building the ROMs. By
> the time you hit the size change during migration it is too late and your
> VM is basically doomed. When building you need to add padding. IIUC for
> RHEL we artificially increased the size of the seabios and ipxe ROMs to
> 256k. So when later RHEL updates ship new seabios/ipxe they still fit in
> the 256k region previously allowed for.


That would have been a good solution to this - if it was done in the past :-)
If I end up forced to draw a line anyway, that is a good way to start
over safe against further size changes.




More information about the libvir-list mailing list