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