From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: berrange@redhat.com, devel@edk2.groups.io,
"Andrew Fish" <afish@apple.com>,
qemu-devel@nongnu.org, zhoujianjay <zhoujianjay@gmail.com>,
discuss <discuss@edk2.groups.io>,
"Alex Bennée" <alex.bennee@linaro.org>,
wuchenye1995 <wuchenye1995@gmail.com>
Subject: Re: [edk2-devel] A problem with live migration of UEFI virtual machines
Date: Mon, 2 Mar 2020 12:32:19 +0000 [thread overview]
Message-ID: <20200302123219.GE2798@work-vm> (raw)
In-Reply-To: <6666a886-720d-1ead-8f7e-13e65dcaaeb4@redhat.com>
* Laszlo Ersek (lersek@redhat.com) wrote:
> The interesting question is, what happens when you power down the VM on
> the destination host (= post migration), and launch it again there, from
> zero. In that case, the firmware executable file comes from the
> *destination host* (it was never persistently migrated from the source
> host, i.e. never written out on the dst). It simply comes from the OVMF
> package that had been installed on the destination host, by the
> sysadmin. However, the varstore pflash does reflect the permanent result
> of the previous migration. So this is where things can fall apart, if
> both firmware binaries (on the src host and on the dst host) don't agree
> about the internal structure of the varstore pflash.
My guess is that overtime we're going to need to find a way to handle
this, otherwise we're going to find people having to maintain old
versions of OVMF just to keep variable store compatiiblity.
Dave
> Thanks
> Laszlo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
prev parent reply other threads:[~2020-03-02 12:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-11 17:06 A problem with live migration of UEFI virtual machines wuchenye1995
2020-02-11 17:39 ` Alex Bennée
2020-02-24 15:28 ` Daniel P. Berrangé
2020-02-25 17:53 ` [edk2-devel] " Laszlo Ersek
2020-02-25 18:56 ` Andrew Fish via
2020-02-25 20:40 ` Laszlo Ersek
2020-02-25 21:35 ` Andrew Fish via
2020-02-26 9:42 ` Laszlo Ersek
2020-02-28 3:20 ` Zhoujian (jay)
2020-02-28 11:29 ` Laszlo Ersek
2020-02-28 4:04 ` Andrew Fish via
2020-02-28 11:47 ` Laszlo Ersek
2020-02-28 11:50 ` Laszlo Ersek
2020-03-02 12:32 ` Dr. David Alan Gilbert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200302123219.GE2798@work-vm \
--to=dgilbert@redhat.com \
--cc=afish@apple.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=devel@edk2.groups.io \
--cc=discuss@edk2.groups.io \
--cc=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wuchenye1995@gmail.com \
--cc=zhoujianjay@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.