Bug 1301592 - Different iPXE rom sizes break migration
Different iPXE rom sizes break migration
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Virtualization Maintenance
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-25 08:16 EST by Fabian Deutsch
Modified: 2016-03-28 05:53 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-25 08:23:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fabian Deutsch 2016-01-25 08:16:30 EST
Description of problem:
The ipxe rom sizes used on the source and destination host of a migration need to (roughly?) match in size, this is an issue if - over time because of updates - the ipxe rom size will change.
qemu should be capable to handle different iPXE rom sizes on the source and destination.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Dr. David Alan Gilbert 2016-01-25 08:23:16 EST
No, this shouldn't be a problem; the ROM sizes we distribute in the iPXE rom dirs are all padded much larger than they need to be, and that allows plenty of room for expansion.  e.g. the virtio-net ROM is only about 66k but is padded to 256k; so we've got plenty of room for growth.
Comment 2 Dr. David Alan Gilbert 2016-01-25 08:30:43 EST
(In reply to Dr. David Alan Gilbert from comment #1)
> No, this shouldn't be a problem; the ROM sizes we distribute in the iPXE rom
> dirs are all padded much larger than they need to be, and that allows plenty
> of room for expansion.  e.g. the virtio-net ROM is only about 66k but is
> padded to 256k; so we've got plenty of room for growth.

Oh with an added note that we specify different ROM images for different machine types; so if we find that eventually it really does go over the boundary, we can elect that machine type rhel9 uses a different ROM path that's bigger.

(Note Fedora hasn't bothered doing this padding; I'm partially of a mind to make qemu do padding itself when it loads them which would also cure the problem).
Comment 3 Dan Kenigsberg 2016-01-26 04:45:42 EST
bug 1293566 specifies to inconsistent roms shipped by Red Hat, which leads to

 2016-01-14T14:00:18.621239Z qemu-kvm: Length mismatch: 0000:00:03.0/virtio-net-pci.rom: 0x10000 in != 0x40000: Invalid argument

during migration (and most probably when restoring from a saved state).

ipxe-20130517-7.1fm.gitc4bce43.el7sat
ipxe-20130517-7.gitc4bce43.el7

I do not know what ipxe-20130517-7.1fm.gitc4bce43.el7sat was shipped and whether anything similar is expected in el7. However, if it does, we'd have a similar bug in a pure RHEL conditions.
Comment 4 Dr. David Alan Gilbert 2016-01-27 10:55:45 EST
Dan:   Yes I'm aware of that bug, it's a packaging screwup, we explicitly pad the ROMs so that growth of the ROMs is not an issue.
Comment 5 Fabian Deutsch 2016-01-27 11:10:05 EST
David, but what happens if the next RHEL update will bring an iPXE rom which is so large, that the padding is not enough?
Comment 6 Dr. David Alan Gilbert 2016-01-27 12:05:54 EST
(In reply to Fabian Deutsch from comment #5)
> David, but what happens if the next RHEL update will bring an iPXE rom which
> is so large, that the padding is not enough?

The current ROM size is 64k, padded to 256k so we're pretty safe; however, if in some later version we needed to do a major change then we can do exactly what we do for rhel6 ROMs, which is we get qemu to use a different path based on machine type.  If started with a rhel-6.x machine type qemu uses a different path from when started with the rhel-7.x machine types.  If 7.5 needed a bigger ROM then we would still have to keep a smaller rom for the old machine types, but we can have the larger rom for the new machine types.

Note You need to log in before you can comment on or make changes to this bug.