* A problem with live migration of UEFI virtual machines
@ 2020-02-10 4:39 wuchenye1995
2020-02-10 20:20 ` [edk2-devel] " Laszlo Ersek
0 siblings, 1 reply; 7+ messages in thread
From: wuchenye1995 @ 2020-02-10 4:39 UTC (permalink / raw)
To: devel@edk2.groups.io; +Cc: qemu-devel, zhoujianjay
[-- Attachment #1: Type: text/html, Size: 3553 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [edk2-devel] A problem with live migration of UEFI virtual machines
2020-02-10 4:39 A problem with live migration of UEFI virtual machines wuchenye1995
@ 2020-02-10 20:20 ` Laszlo Ersek
0 siblings, 0 replies; 7+ messages in thread
From: Laszlo Ersek @ 2020-02-10 20:20 UTC (permalink / raw)
To: "wuchenye1995 <wuchenye1995@gmail.com>,devel@edk2.groups.io
[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]
(Replying through the groups.io web interface, just this one time)
wuchenye1995 wrote:
> 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't solve it. The 2MB and 4MB builds of OVMF are fundamentally
incompatible with each other. It's actually beneficial that QEMU cleanly
prevents such attempts at migration; otherwise you'd see misbehavior
that would be much less graceful.
Please see commit b24fca05751f ("OvmfPkg: introduce 4MB flash image
(mainly) for Windows HCK", 2017-05-05) for more info:
https://github.com/tianocore/edk2/commit/b24fca05751f
This is the reason why the Fedora edk2 package build script (= RPM spec
file) uses "-D FD_SIZE_2MB" explicitly.
Thanks
Laszlo
[-- Attachment #2: Type: text/html, Size: 1512 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* A problem with live migration of UEFI virtual machines
@ 2020-02-10 8:53 "wuchenye1995
2020-02-20 15:47 ` dgilbert
0 siblings, 1 reply; 7+ messages in thread
From: "wuchenye1995 @ 2020-02-10 8:53 UTC (permalink / raw)
To: devel@edk2.groups.io; +Cc: qemu-devel, zhoujianjay, edk2-devel
[-- Attachment #1: Type: text/html, Size: 3404 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A problem with live migration of UEFI virtual machines
2020-02-10 8:53 "wuchenye1995
@ 2020-02-20 15:47 ` dgilbert
0 siblings, 0 replies; 7+ messages in thread
From: dgilbert @ 2020-02-20 15:47 UTC (permalink / raw)
To: wuchenye1995; +Cc: devel@edk2.groups.io, zhoujianjay, edk2-devel, qemu-devel
* 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* A problem with live migration of UEFI virtual machines
@ 2020-02-11 17:06 "wuchenye1995
2020-02-11 17:39 ` Alex Bennée
0 siblings, 1 reply; 7+ messages in thread
From: "wuchenye1995 @ 2020-02-11 17:06 UTC (permalink / raw)
To: discuss; +Cc: devel@edk2.groups.io, zhoujianjay, qemu-devel, wuchenye1995
[-- Attachment #1: Type: text/html, Size: 3406 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A problem with live migration of UEFI virtual machines
2020-02-11 17:06 "wuchenye1995
@ 2020-02-11 17:39 ` Alex Bennée
2020-02-24 15:28 ` Daniel P. Berrangé
0 siblings, 1 reply; 7+ messages in thread
From: Alex Bennée @ 2020-02-11 17:39 UTC (permalink / raw)
To: wuchenye1995; +Cc: discuss, devel@edk2.groups.io, zhoujianjay, qemu-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A problem with live migration of UEFI virtual machines
2020-02-11 17:39 ` Alex Bennée
@ 2020-02-24 15:28 ` Daniel P. Berrangé
0 siblings, 0 replies; 7+ messages in thread
From: Daniel P. Berrangé @ 2020-02-24 15:28 UTC (permalink / raw)
To: Alex Bennée
Cc: wuchenye1995, discuss, devel@edk2.groups.io, zhoujianjay,
qemu-devel
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 :|
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-02-24 15:28 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-10 4:39 A problem with live migration of UEFI virtual machines wuchenye1995
2020-02-10 20:20 ` [edk2-devel] " Laszlo Ersek
-- strict thread matches above, loose matches on Subject: below --
2020-02-10 8:53 "wuchenye1995
2020-02-20 15:47 ` dgilbert
2020-02-11 17:06 "wuchenye1995
2020-02-11 17:39 ` Alex Bennée
2020-02-24 15:28 ` Daniel P. Berrangé
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox