A problem with live migration of UEFI virtual machines

A problem with live migration of UEFI virtual machines

[wuchenye1995]

[-- Attachment #1: Type: text/html, Size: 3553 bytes --]

A problem with live migration of UEFI virtual machines

[wuchenye1995]

[-- Attachment #1: Type: text/html, Size: 3404 bytes --]

Re: A problem with live migration of UEFI virtual machines

[Dr. David Alan Gilbert]

* wuchenye1995 (wuchenye1995@gmail.com) wrote:

> We found a problem with live migration of UEFI virtual machines due to size of OVMF.fd changes.</div><div class=" selfdiv" style="height: 79.6875px; width: auto !important;"
> Specifically, the size of OVMF.fd in edk with low version such as edk-2.0-25 is <b>2MB</b> while the size of it in higher version such as edk-2.0-30 is <b>4MB</b>.
>   When we migrate a UEFI virtual machine from the host with low version of edk2 to the host with higher one, qemu component will report an error in function
> qemu_ram_resize while
>checking size of ovmf_pcbios: Length mismatch: pc.bios: 0x200000 in != 0x400000: Invalid argument.
>We want to know how to solve this problem after updating the version of edk2.

When you migrate, you must migrate between identical configurations; so
you need ROM images (including edk2) that are the same size.
There's two answers;
   a) Stick with the same version of the ROM between VMs you want to
migrate
   b) Pad your ROM images to some larger size (e.g. 8MB) so that
even if they grow a little bigger then you don't hit the problem.

Dave
P.S. Please use plain text email

Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

A problem with live migration of UEFI virtual machines

[wuchenye1995]

[-- Attachment #1: Type: text/html, Size: 3406 bytes --]

Re: A problem with live migration of UEFI virtual machines

[Alex Bennée]

wuchenye1995 <wuchenye1995@gmail.com> writes:

> Hi all,
>    We found a problem with live migration of UEFI virtual machines due to size of OVMF.fd changes.
>    Specifically, the size of OVMF.fd in edk with low version such as edk-2.0-25 is 2MB while the size of it in higher version such as edk-2.0-30 is 4MB.
>    When we migrate a UEFI virtual machine from the host with low version of edk2 to the host with higher one, qemu component will report an error in function qemu_ram_resize while
> checking size of ovmf_pcbios: Length mismatch: pc.bios: 0x200000 in != 0x400000: Invalid argument.
>    We want to know how to solve this problem after updating the
>    version of edk2.

You can only migrate a machine that is identical - so instantiating a
empty machine with a different EDK image is bound to cause a problem
because the machines don't match.

-- 
Alex Bennée

Re: A problem with live migration of UEFI virtual machines

[Daniel P. Berrangé]

On Tue, Feb 11, 2020 at 05:39:59PM +0000, Alex Bennée wrote:
> 
> wuchenye1995 <wuchenye1995@gmail.com> writes:
> 
> > Hi all,
> >    We found a problem with live migration of UEFI virtual machines due to size of OVMF.fd changes.
> >    Specifically, the size of OVMF.fd in edk with low version such as edk-2.0-25 is 2MB while the size of it in higher version such as edk-2.0-30 is 4MB.
> >    When we migrate a UEFI virtual machine from the host with low version of edk2 to the host with higher one, qemu component will report an error in function qemu_ram_resize while
> > checking size of ovmf_pcbios: Length mismatch: pc.bios: 0x200000 in != 0x400000: Invalid argument.
> >    We want to know how to solve this problem after updating the
> >    version of edk2.
> 
> You can only migrate a machine that is identical - so instantiating a
> empty machine with a different EDK image is bound to cause a problem
> because the machines don't match.

I don't believe we are that strict for firmware in general. The firmware
is loaded when QEMU starts, but that only matters for the original
source host QEMU. During migration, the memory content of the original
firmware will be copied during live migration, overwriting whatever the
target QEMU loaded off disk. This works....provided the memory region
is the same size on source & target host, which is where the problem
arises in this case.

If there's a risk that newer firmware will be larger than old firmware
there's only really two options:

  - Keep all firmware images forever, each with a unique versioned
    filename. This ensures target QEMU will always load the original
    smaller firmware

  - Add padding to the firmware images. IOW, if the firmware is 2 MB,
    add zero-padding to the end of the image to round it upto 4 MB
    (whatever you anticipate the largest size wil be in future).

Distros have often taken the latter approach for QEMU firmware in the
past. The main issue is that you have to plan ahead of time and get
this padding right from the very start. You can't add the padding after
the fact on an existing VM.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|