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?