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

> 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?