Note: groups.io will be down for maintenance on Wednesday, October 5th, starting at 9AM Pacific Time (4PM Wednesday October 5, 2022 UTC), for approximately one hour.
Re: [edk2-devel] A problem with live migration of UEFI virtual machines
On 02/24/20 16:28, Daniel P. Berrangé wrote:
On Tue, Feb 11, 2020 at 05:39:59PM +0000, Alex Bennée wrote:Following up here *too*, just for completeness.I don't believe we are that strict for firmware in general. The
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 @gmail.com 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
* First posting:
- msgid: <tencent_F1295F826E46EDFF3D77812B@...>
- edk2-devel: https://edk2.groups.io/g/devel/message/54146
- qemu-devel: https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg02419.html
* my response:
- msgid: <firstname.lastname@example.org>
- edk2-devel: https://edk2.groups.io/g/devel/message/54161
- qemu-devel: none, because (as an exception) I used the stupid
groups.io web interface to respond, and so my response
never reached qemu-devel
* Second posting (~4 hours after the first)
- msgid: <tencent_3CD8845EC159F0161725898B@...>
- edk2-devel: https://edk2.groups.io/g/devel/message/54147
- qemu-devel: https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg02415.html
* Dave's response:
- msgid: <20200220154742.GC2882@work-vm>
- edk2-devel: https://edk2.groups.io/g/devel/message/54681
- qemu-devel: https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg05632.html
* Third posting (next day, present thread) -- cross posted to yet
another list (!), because apparently Dave's feedback and mine had not
- msgid: <tencent_BC7FD00363690990994E90F8@...>
- edk2-devel: https://edk2.groups.io/g/devel/message/54220
- edk2-discuss: https://edk2.groups.io/g/discuss/message/135
- qemu-devel: https://lists.gnu.org/archive/html/qemu-devel/2020-02/msg02735.html
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.