Re: How to best handle the reoccurring of rom changes breaking cross version migrations?

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

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux