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

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

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.

Also to +1 on bad things for today - I made this a cross post to libvirt in case there is one that has done that in the past.

On Mon, Aug 28, 2017 at 4:36 PM, Christian Ehrhardt <christian ehrhardt canonical com> wrote:
migration issues due to rom changes seem to occur over and over in past years [1], [2],[3],[4],[5].
From the past I know several workarounds (like just truncating to the bigger size) but all have various deficiencies.

But OTOH rom's will always change due to fixes in them. And recently I found one such change [6] that affects the next Ubuntu release and wonder what the ?right?, well lets say best way to fix it would be.
Current issue:
Length mismatch: 0000:00:03.0/virtio-net-pci.rom: 0x40000 in != 0x80000: Invalid argument
Due to efi-virtio.rom growing over 256k due to an update to a newer ipxe from upstream.

I beg your pardon (for not being educated enough on this yet), but I want to avoid to go a route that is fixing it in a sub-optimal way and ask for some guidance. There might be better ways in the modern qemu of today than there were in the past.
TL;DR I look for the best way (if any) to declare in the new qemu: "I know that the old size was smaller, let me fix that up on migration".

I'll try on my own as I expect the machine type structures/mechanisms (and we have Ubuntu specific types that could encapsulate the rom status from the ipxe package to be coupled with the type) have all that is needed.
Yet me almost randomly trying around there surely isn't the best way to go - so if there is some existing case or a short hint at what in there might be the best way to fixup a changed rom size on a migration I'd be very happy to hear about that.

[1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1536331
[2]: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg01881.html
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1293566
[4]: https://bugzilla.redhat.com/show_bug.cgi?id=1090093
[5]: https://forge.univention.org/bugzilla/show_bug.cgi?id=38877
[6]: https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/1713490

P.S: As everybody else I don't mind so much on reverse migration to older releases

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

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