Hi,
Answers below.....
On 8/7/24 08:26, Martin Kletzander wrote:
On Tue, Aug 06, 2024 at 03:50:45PM -0500, Michael Galaxy wrote:
Hi,
On 8/6/24 07:38, Martin Kletzander wrote:
On Wed, Jun 05, 2024 at 04:37:36PM -0400, mgalaxy@xxxxxxxxxx wrote:
From: Michael Galaxy <mgalaxy@xxxxxxxxxx>
if (src->mem.source != dst->mem.source) {
- virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
- _("Target memoryBacking source '%1$s' doesn't
match source memoryBacking source'%2$s'"),
- virDomainMemorySourceTypeToString(dst->mem.source),
- virDomainMemorySourceTypeToString(src->mem.source));
- return false;
+ /*
+ * The current use case for this is the live migration of
live-update
+ * capable CPR guests mounted on PMEM devices at the host
Does libvirt need more adjustments to support cpr-reboots? I don't
think we have any support for them yet.
Ummmm, no, not really, no. Which is a good question.
CPR has two different modes. "reboots" and "execs". The former is when
you want to do a full kexec
(which blows away libvirt because you're rebooting), and the latter
does not do a kexec at all.
We are only currently using the reboot mode. And it works just fine.
There are a number of QMP commands that CPR uses, but we are feeding
those commands
through libvirt with just the normal qmp command support that it already
provides rather than
doing any "built-in" changes to libvirt to support those features,
currently.
So, no, we don't have a need (currently) to further modify libvirt to
support CPR.
The QMP command is fine, but since it messes with the VM behind
libvirt's back we will "taint" the domain. In order for this to be
fully supported (together with any future changes, which makes it easier
for consumers of libvirt) it should be added to libvirt as a
possibility.
That's a valid point, but I think it's an exercise for a future RFC, I
think.
What we have here so far is the minimal set of changes needed to make it
work.
I'd like to avoid making this set too complicated. How we handle QMP
abstractions
can be improved later if we want to engage the original CPR author
(steven.sistare@xxxxxxxxxx)
at some point.
So you are solely relying on the fact that when we start QEMU again it
will use the same paths and just resume working? That could be another
reason to make changes to libvirt, if only to make sure the paths are
the same.
Yes, we are relying on that fact, correct. We have not had any serious
issues on this front,
as when we're doing a live updates, we're expecting all the paths to be
the same.
One interesting use case for potentially changing paths, as you say is
maybe if there was
a storage change with a new QCOW2 path for some reason, or as you
mentioned before
the number of NUMA nodes changed, but again, that would be highly
irregular and intrusive
for a local-only live update.
If such situations are really happening, then the cloud manager should
do a live *migration* instead of
a live update and get the original libvirt-managed system into its new
configuration before
returning the host back to service. I live "update" (in place) would be
pretty strange, I think,
if paths have the potential to change underneath us.
All good questions though,
- Michael
