Re: [PATCH 0/1] Support cloning saved VMs

> On 10 Jan 2025, at 12:38, Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: > > !-------------------------------------------------------------------| > CAUTION: External Email > > |-------------------------------------------------------------------! > > On Fri, Jan 10, 2025 at 12:31:00PM +0000, Felipe Franciosi wrote: >> >> >>> On 10 Jan 2025, at 12:23, Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: >>> >>> On Fri, Jan 10, 2025 at 12:09:44PM +0000, Felipe Franciosi wrote: >>>> >>>> >>>>> On 10 Jan 2025, at 11:00, Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: >>>>> >>>>> On Fri, Jan 10, 2025 at 10:49:20AM +0000, Felipe Franciosi wrote: >>>>>> >>>>>> >>>>>>> On 10 Jan 2025, at 08:33, Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: >>>>>>> >>>>>>> On Thu, Jan 09, 2025 at 07:27:16PM +0000, Felipe Franciosi wrote: >>>>>>>> Hello! >>>>>>>> >>>>>>>> I have a use case which I'm struggling to support with libvirt: >>>>>>>> saving a VM to a file, cloning it (which renames the VM), and restoring it. >>>>>>>> >>>>>>>> My search revealed a number of tutorials for using virt-clone [1], but that >>>>>>>> doesn't seem to cover VMs which are _saved_ (only running or paused). >>>>>>> >>>>>>> Saved in what way ? Managed save ? >>>>>> >>>>>> Thanks for the prompt reply! >>>>>> >>>>>> I'm saving with virDomainSave(). My understanding is that this is not managed. >>>>> >>>>> Functionally it is the same as managed save, just the that file path >>>>> is specified by the client, rather than by libvirt. >>>> >>>> Got it, thanks. >>>> >>>>>>>> [1] https://github.com/virt-manager/virt-manager/blob/main/virtinst/virtclone.py >>>>>>>> >>>>>>>> In a nutshell, I want to power on a VM and do some setup, then save its full >>>>>>>> state to disk (e.g., with virsh save). Finally I want to modify the XML to: >>>>>>>> - rename the VM >>>>>>>> - change which bridge its NICs are on (while maintaining mac addresses) >>>>>>>> - change the disk image to a copy (done while the VM is saved) >>>>>>>> >>>>>>>> But the restore operation fails because of a target domain name check >>>>>>>> implemented in virDomainDefCheckABIStabilityFlags(). I've debated how to best >>>>>>>> address this and I'm looking for your views. >>>>>>> >>>>>>> If you're cloning a VM, it needs both a new UUID and name, so I'm surprised >>>>>>> the ABI stability check hasn't already blocked you on the UUID change before >>>>>>> getting to the name change check. >>>>>> >>>>>> I definitely didn't change the UUID. In fact, I want it to be the same (at >>>>>> least in the SMBIOS tables) because the guest OS is not going to expect that >>>>>> value to change without a power cycle/reset. The ABI Check actually ensures the >>>>>> SMBIOS values do not change during restore. >>>>>> >>>>>> https://gitlab.com/libvirt/libvirt/-/blob/caa10431cdd1aa476637ff721f1947c... >>>>>> >>>>>> My understanding is that this passed because the other domain was not running >>>>>> (and the save was unmanaged, so libvirt is unaware of the saved VM). >>>>>> >>>>>> What I don't understand is why the UUID has to be unique (or, in fact, the same >>>>>> as the SMBIOS Type 1 UUID). Isn't this something just visible to the VM? For >>>>>> the clone use case, I surely don't want this to change. >>>>>> >>>>>> In other words, it's not clear to me why this check is needed: >>>>>> https://gitlab.com/libvirt/libvirt/-/blob/caa10431cdd1aa476637ff721f1947c... >>>>> >>>>> Libvirt has three unique identifiers for all VMs - UUID, name, and ID. The >>>>> latter is only for running VMs. >>>>> >>>>> UUID is the primary unique identifier that is used for pretty much every >>>>> lookup inside libvirt. Name is a secondary unique identifier largely just >>>>> for external lookups by humans, since UUIDs are not human friendly. >>>>> >>>>> Essentially every API call starts with virDomainObjListFindByUUID to convert >>>>> the public 'virDomainPtr' object into the internal 'virDomainObjPtr' struct >>>>> that holds the config & state. >>>> >>>> Ah-ha. Ok, this is really helpful, thanks again! >>>> >>>> My next question is why the SMBIOS Type 1 UUID tied to the Libvirt identifier? >>>> (I'm pointing again at L#12810 above.) >>>> >>>> That feels incorrect. My (new) understanding is that: >>>> - The SMBIOS Type 1 UUID is guest-visible >>>> - The Libvirt UUID is a host identifier >>>> >>>> What comes to mind is that maybe something like guest tools wants to be able to >>>> report back to a control plane what VM it is on based on this value. If that's >>>> the motivation, then isn't Generation ID a better field to rely on? >>> >>> Strictly speaking we don't have to tie them together, but in practice we >>> do, because it is pretty compelling to be correlate data between the host >>> OS and guest OS for apps. >> >> Right, so libvirt uses the XML <UUID> as a host unique identifier and also as >> QEMU's "-uuid" parameter (which, based on my understanding, is a default for >> any virtual hardware UUID stuff such as SMBIOS Type 1 UUID/Serial. And the >> reason for that is to allow guests to infer their hypervisor identifier. >> >>> >>>> My understanding is that SMBIOS identifiers cannot change at runtime. >>> >>> Correct. >> >> Ok, but then I'm confused: how is clone supposed to work? When I clone a saved >> VM, Libvirt requires that I change its <UUID> and it also requires that this >> <UUID> matches SMBIOS Type 1 UUID which, by definition, cannot change. >> >> What am I missing? > > Yep, the idea of cloning a running (well saved) VM on the same > host is effectively denied due to this policy. > > We have never claimed that cloning a running VM is supported, > and actively discouraged people from trying to do this. > > The only workaround would be if launched on a different host. Failing > that the only option would be for us to remove the requirement that > VM UUID matches SMBIOS UUID. > > Perhaps we could do the latter, but mark the VM as "tainted" to indicate > this undesirable config scenario. That works for me. Let me submit another patch along those lines for review. Also it sounds like there isn't a strong reason for tying up SMBIOS UUID and VM UUID except the use case of the guest inferring its hypervisor identifier. Would it make sense to propose a new device type that can canonically be used for that purpose? Something like Generation ID, perhaps. I can see if someone from our side can work on that if you think it's a good idea.