Re: [edk2-devel] A problem with live migration of UEFI virtual machines

Laszlo Ersek

On 02/24/20 16:28, Daniel P. Berrangé wrote:
On Tue, Feb 11, 2020 at 05:39:59PM +0000, Alex Bennée wrote:

wuchenye1995 <wuchenye1995@...> 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.
Following up here *too*, just for completeness.

The query in this thread has been posted three times now (and I have
zero idea why). Each time it generated a different set of responses. For
completes, I'm now going to link the other two threads here (because the
present thread seems to have gotten the most feedback).

To the OP:

- please do *NOT* repost the same question once you get an answer. It
only fragments the discussion and creates confusion. It also doesn't
hurt if you *confirm* that you understood the answer.

- Yet further, if your email address has for domain, but your
msgids contain "tencent", that raises some eyebrows (mine for sure).
You say "we" in the query, but never identify the organization behind
the plural pronoun.

(I've been fuming about the triple-posting of the question for a while
now, but it's only now that, upon seeing how much work Dan has put into
his answer, I've decided that dishing out a bit of netiquette would be
in order.)

* First posting:
- msgid: <tencent_F1295F826E46EDFF3D77812B@...>
- edk2-devel:
- qemu-devel:

* my response:
- msgid: <>
- edk2-devel:
- qemu-devel: none, because (as an exception) I used the stupid web interface to respond, and so my response
never reached qemu-devel

* Second posting (~4 hours after the first)
- msgid: <tencent_3CD8845EC159F0161725898B@...>
- edk2-devel:
- qemu-devel:

* Dave's response:
- msgid: <20200220154742.GC2882@work-vm>
- edk2-devel:
- qemu-devel:

* Third posting (next day, present thread) -- cross posted to yet
another list (!), because apparently Dave's feedback and mine had not
been enough:
- msgid: <tencent_BC7FD00363690990994E90F8@...>
- edk2-devel:
- edk2-discuss:
- qemu-devel:

Back on topic: see my response again. The answer is, you can't solve the
problem (specifically with OVMF), and QEMU in fact does you service by
preventing the migration.


Join to automatically receive all group messages.