> On 10 Jan 2025, at 08:33, Daniel P. Berrangé <berrange@xxxxxxxxxx> 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. >> [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/caa10431cdd1aa476637ff721f1947c4e0b53da1/src/conf/domain_conf.c#L21759 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/caa10431cdd1aa476637ff721f1947c4e0b53da1/src/conf/domain_conf.c#L12810 >> 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?). > 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. F.
