Re: [PATCH v2 2/4] Support live migration between file-backed memory and anonymous memory.

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(a)akamai.com wrote: >>>> From: Michael Galaxy <mgalaxy(a)akamai.com&gt; >>>> >>>> >>>>     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(a)oracle.com) 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