On Wed, Aug 07, 2024 at 10:20:49AM -0500, Michael Galaxy wrote:
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 hostDoes 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.
Oh, sure, it's not needed for this particular patchset, I was wondering if there are more things we need to implement in order for CPR to be supported in libvirt.
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.
Well, if you are starting the domains without libvirt's prior knowledge (i.e. not from as saved snapshot or anything like that) libvirt will generate the paths based on the domain ID. But if there is nothing running during the start libvirt will start the IDs from number 1. Unless the previous VM was also the first one started it will have different ID and the whole path will be different.
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
Attachment:
signature.asc
Description: PGP signature
