handycapp

Hi folks, this issue has taken me an inordinate amount of time to identify. My environment: Unraid OS: 7.2.3 VM Type: UEFI (OVMF) Guest OS: Debian 12 (but issue is hypervisor‑level, not guest‑specific) Hypervisor: KVM/QEMU via libvirt Storage: vdisk1.img on /mnt/user/domains/<vmname>/ UEFI VMs are the default for most modern OSes. Cloning is essential for: staging changes testing upgrades templating disaster recovery snapshot‑style workflows At present, cloning a UEFI VM requires manual intervention in multiple areas of the XML and filesystem, which is error‑prone and not discoverable. Summary of the Problem Cloning a UEFI VM via the Unraid VM Manager produces a VM definition that is not bootable, even when: The vdisk is valid The vdisk path is correct No passthrough devices are assigned No ISO is attached Boot order is correct BIOS type matches the source VM The cloned VM always drops into OVMF BIOS and cannot locate a bootloader. This behaviour is fully reproducible. Root Cause Analysis After detailed inspection of the generated XML and libvirt runtime state, the following issues are present in every clone: 1. Missing NVRAM (VARS) file for the cloned VM The source VM has: Code <nvram>/etc/libvirt/qemu/nvram/<UUID>_VARS-pure-efi.fd</nvram> The cloned VM’s XML references a different UUID, but no corresponding VARS file is created in: Code /etc/libvirt/qemu/nvram/ As a result, OVMF has: no EFI variables no boot entries no BootOrder no saved boot manager state This alone is sufficient to cause a drop into BIOS. Manual fix (works): Code cp /etc/libvirt/qemu/nvram/<sourceUUID>_VARS-pure-efi.fd \ /etc/libvirt/qemu/nvram/<cloneUUID>_VARS-pure-efi.fd Then update the <nvram> path in the clone’s XML. 2. Inherited passthrough <hostdev> blocks The clone inherits all <hostdev> entries from the source VM, including GPU audio functions, USB controllers, NVMe devices, etc. If the source VM is running, the clone cannot start because the PCI devices are already bound to vfio-pci by the source domain. Even when removed in the GUI, the XML may still contain stale <hostdev> blocks. 3. Inherited ISO <disk device='cdrom'> block Even when the GUI shows “None” for OS Install ISO, the cloned XML still contains: Code <disk type='file' device='cdrom'> <source file='/mnt/user/isos/<installer>.iso'/> </disk> This causes QEMU to prioritize the CD-ROM device unless boot order is explicitly overridden. 4. Boot order is not reset The clone inherits the source VM’s boot order, which may prioritize: CD-ROM Network boot Nonexistent devices Combined with missing NVRAM, this guarantees a BIOS drop. 5. vdisk path is correct, but clone still fails to boot Even when pointing the clone directly at the source VM’s known‑good vdisk, the clone still drops into BIOS. This confirms the issue is not related to: vdisk corruption block‑commit snapshot chain copy failure The failure is entirely in the VM definition (XML + missing NVRAM). Steps to Reproduce (Minimal) Create a UEFI VM (OVMF) Shut it down Use Clone in VM Manager Manually copy the vdisk to the clone’s folder Start the cloned VM Result: VM enters OVMF BIOS and cannot boot. Expected Behaviour Cloning a VM should: Generate a new NVRAM (VARS) file Remove passthrough devices unless explicitly selected Remove ISO references Reset boot order to vdisk first Produce a bootable clone without manual XML editing Actual Behaviour Cloning produces a VM that: Has no NVRAM file Contains stale passthrough hostdevs Contains stale ISO references Has incorrect boot order Cannot boot even with a known‑good vdisk Questions for Lime Technology: Is the absence of automatic NVRAM generation for cloned UEFI VMs a known limitation in 7.2.3? Is there an officially supported method to clone UEFI VMs without manual XML/NVRAM intervention? Is automatic NVRAM creation planned for a future 7.x release? Should the VM Manager remove inherited hostdev and ISO blocks when cloning? Is the VM Manager rewrite (mentioned in prior forum posts) expected to address these issues? sagittarius-diagnostics-20260107-2100.zip