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

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.

>>> [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.

>>> I suspect this call is there for a reason (which may still be relevant), >>> although the name is clearly not part of the ABI; it's the host identifier for >>> that domain and not guest-visible. My first stab at this is therefore just to >>> drop this check (patch attached). >> >> The most important thing is that Libvirt has to ensure uniqueness of the >> name, within the host. If the name can be silently changed by passing >> in change XML, the unique checks will be missing and you can end up with >> many VMs with the same name. > > Sure, but that's different than checking source is the same as destination. > > Isn't a check of domain name uniqueness within the host better done elsewhere? > Maybe as part of domainRestore() / domainCreate() / domainRename() (or some > common higher-level ground?). Name uniqueness is validated in any code path that adds a new virDomainObjPtr to the virDomainObjList, via validatin in virDomainObjListAdd.

The ABI stability checks are done in places where we allow the XML of an existing VM to be replaced, and that doesn't involve calls to virDomainObjListAdd since we're not creating a new VM, just altering its backend config.

>> Likewise for UUID checks. > > I still don't understand how UUID is used, so clarification/pointers welcome! > >>> I'm open to suggestions, for example by plumbing through a flag which makes the >>> check optional. Please let me know how you prefer that I take this forward. >> >> If you're using managed save, then I would think it is already possible to >> achieve. >> >> First cloning the VM: >> >> virsh dumpxml myvm > myvm.xml >> cp myvm.xml myvm-clone.xml >> ..modify name & uuid & bridge & disk of myvm-clone.xml >> virsh define myvm-clone.xml >> >> Now modify the saved state >> >> virsh managedsave-dumpxml myvm-clone > save.xml >> ...modify save.xml to change name & uuid to match myvm-clonme... >> virsh managedsave-define save.xml >> >> The ABI stability check done by managedsave-define, will validate against >> the name + uuid of the cloned VM, so in fact it will force you to change >> the name + uuid in the save XML before loading it back in, and it should >> be not possible to restore from the managed save image until fixing this > > Thanks for these pointers; I'll look into them. But I think my workflows are > not managed as these VMs are not persistent on the host. When they die, they > may be restarted elsewhere by a higher-level (multi-host) control plane. There are equivalent save-image-define / save-image-dumpxml for the non-managed save scenario.