Hey guys,

I'm trying to migrate my Windows 11 VM from my cache pool (mnt/cache/domains/Windows 11/) to a dedicated VM storage pool (mnt/vdiskpool/domains/Windows 11/). I transferred the 'domains' share to the 'vdiskpool' drive, ran mover, and then made sure there's no secondary drive for the domains share. The VM works fine until I realized that 'vdisk1.qcow2' was still located in mnt/cache/domains/Windows 11. So I tried to transfer the .qcow2 file from the cache drive to the vdiskpool drive. When I do, I get this message.



It seems it's expecting for it to be on the cache drive. I've looked within the VM config (even the xml) and I cannot find any line which governs the location of this qcow2 file. At this point I remembered that I created a snapshot for this VM - not for any particular reason, just to see how it works. I don't really know how to delete it.
I asked for help in the official discord server and a user called 'Kilrah' advised that I change the following highlighted lines in the snapshots.db file to /mnt/user/domains/Windows 11/.

but after I did that and rebooted Unraid, I still get the same error. I can confirm that even after all this, copying the vdisk1.qcow2 file to /mnt/cache/domains/Windows 11/ still works flawlessly, meaning something else definitely still expects it to be there.

Here is my VM config:


Would deleting the snapshot somehow help?
Should I revert the changes I made in the snapshot.db file?

How can I fix this?

Edited August 22Aug 22 by Corvus

You can try changing all references to /cache/ on the XML to /vdiskpool/, assuming everything has been moved there.

5 hours ago, JorgeB said:

You can try changing all references to /cache/ on the XML to /vdiskpool/, assuming everything has been moved there.

I've tried this, although the weird thing is that when viewing the XML while the VM is running, it DOES make mention to the cache directory where the qcow2 file is located. However, I cannot make change to it while it's running.
But when I shut down the VM, and again try to view the XML - the reference to the directory is gone! It simply doesn't exist anymore!

Here is the XML when the VM is shut down:
<?xml version='1.0' encoding='UTF-8'?>

<domain type='kvm'>

<name>Windows 11</name>

<uuid>e05d58a1-e3fc-859a-7670-a211f88da6e1</uuid>

<metadata>

<vmtemplate xmlns="http://unraid" name="Windows 11" iconold="windows11.png" icon="windows11.png" os="windowstpm" webui="" storage="default"/>

</metadata>

<memory unit='KiB'>16777216</memory>

<currentMemory unit='KiB'>16777216</currentMemory>

<memoryBacking>

<nosharepages/>

</memoryBacking>

<vcpu placement='static'>8</vcpu>

<cputune>

<vcpupin vcpu='0' cpuset='2'/>

<vcpupin vcpu='1' cpuset='3'/>

<vcpupin vcpu='2' cpuset='4'/>

<vcpupin vcpu='3' cpuset='5'/>

<vcpupin vcpu='4' cpuset='6'/>

<vcpupin vcpu='5' cpuset='7'/>

<vcpupin vcpu='6' cpuset='8'/>

<vcpupin vcpu='7' cpuset='9'/>

</cputune>

<os>

<type arch='x86_64' machine='pc-q35-9.2'>hvm</type>

<loader readonly='yes' type='pflash' format='raw'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi-tpm.fd</loader>

<nvram format='raw'>/etc/libvirt/qemu/nvram/e05d58a1-e3fc-859a-7670-a211f88da6e1_VARS-pure-efi-tpm.fd</nvram>

</os>

<features>

<acpi/>

<apic/>

<hyperv mode='custom'>

<relaxed state='on'/>

<vapic state='on'/>

<spinlocks state='on' retries='8191'/>

<vpindex state='on'/>

<synic state='on'/>

<stimer state='on'/>

<vendor_id state='on' value='none'/>

</hyperv>

</features>

<cpu mode='host-passthrough' check='none' migratable='on'>

<topology sockets='1' dies='1' clusters='1' cores='4' threads='2'/>

<cache mode='passthrough'/>

</cpu>

<clock offset='localtime'>

<timer name='hpet' present='no'/>

<timer name='hypervclock' present='yes'/>

</clock>

<on_poweroff>destroy</on_poweroff>

<on_reboot>restart</on_reboot>

<on_crash>restart</on_crash>

<devices>

<emulator>/usr/local/sbin/qemu</emulator>

<disk type='file' device='disk'>

<driver name='qemu' type='qcow2' cache='writeback' discard='unmap'/>

<source file='/mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2'/>

<target dev='hdc' bus='virtio'/>

<serial>vdisk1</serial>

<boot order='1'/>

<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>

</disk>

<disk type='file' device='cdrom'>

<driver name='qemu' type='raw'/>

<source file='/mnt/user/isos/virtio-win-0.1.285-1.iso'/>

<target dev='hdb' bus='sata'/>

<readonly/>

<address type='drive' controller='0' bus='0' target='0' unit='1'/>

</disk>

<controller type='pci' index='0' model='pcie-root'/>

<controller type='pci' index='1' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='1' port='0x8'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/>

</controller>

<controller type='pci' index='2' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='2' port='0x9'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>

</controller>

<controller type='pci' index='3' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='3' port='0xa'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>

</controller>

<controller type='pci' index='4' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='4' port='0xb'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/>

</controller>

<controller type='pci' index='5' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='5' port='0xc'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x4'/>

</controller>

<controller type='pci' index='6' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='6' port='0xd'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x5'/>

</controller>

<controller type='pci' index='7' model='pcie-to-pci-bridge'>

<model name='pcie-pci-bridge'/>

<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>

</controller>

<controller type='virtio-serial' index='0'>

<address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>

</controller>

<controller type='sata' index='0'>

<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>

</controller>

<controller type='usb' index='0' model='qemu-xhci' ports='15'>

<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>

</controller>

<interface type='bridge'>

<mac address='52:54:00:33:2c:ad'/>

<source bridge='br0'/>

<model type='virtio-net'/>

<address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>

</interface>

<serial type='pty'>

<target type='isa-serial' port='0'>

<model name='isa-serial'/>

</target>

</serial>

<console type='pty'>

<target type='serial' port='0'/>

</console>

<channel type='unix'>

<target type='virtio' name='org.qemu.guest_agent.0'/>

<address type='virtio-serial' controller='0' bus='0' port='1'/>

</channel>

<input type='tablet' bus='usb'>

<address type='usb' bus='0' port='1'/>

</input>

<input type='mouse' bus='ps2'/>

<input type='keyboard' bus='ps2'/>

<tpm model='tpm-tis'>

<backend type='emulator' version='2.0' persistent_state='yes'/>

</tpm>

<graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0' sharePolicy='ignore'>

<listen type='address' address='0.0.0.0'/>

</graphics>

<audio id='1' type='none'/>

<video>

<model type='qxl' ram='65536' vram='16384' vgamem='16384' heads='1' primary='yes'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/>

</video>

<hostdev mode='subsystem' type='pci' managed='yes'>

<driver name='vfio'/>

<source>

<address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>

</source>

<address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>

</hostdev>

<hostdev mode='subsystem' type='pci' managed='yes'>

<driver name='vfio'/>

<source>

<address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/>

</source>

<address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>

</hostdev>

<watchdog model='itco' action='reset'/>

<memballoon model='none'/>

</devices>

</domain>

And here is the XML when the VM is running:

<?xml version='1.0' encoding='UTF-8'?>

<domain type='kvm' id='4'>

<name>Windows 11</name>

<uuid>e05d58a1-e3fc-859a-7670-a211f88da6e1</uuid>

<metadata>

<vmtemplate xmlns="http://unraid" name="Windows 11" iconold="windows11.png" icon="windows11.png" os="windowstpm" webui="" storage="default"/>

</metadata>

<memory unit='KiB'>16777216</memory>

<currentMemory unit='KiB'>16777216</currentMemory>

<memoryBacking>

<nosharepages/>

</memoryBacking>

<vcpu placement='static'>8</vcpu>

<cputune>

<vcpupin vcpu='0' cpuset='2'/>

<vcpupin vcpu='1' cpuset='3'/>

<vcpupin vcpu='2' cpuset='4'/>

<vcpupin vcpu='3' cpuset='5'/>

<vcpupin vcpu='4' cpuset='6'/>

<vcpupin vcpu='5' cpuset='7'/>

<vcpupin vcpu='6' cpuset='8'/>

<vcpupin vcpu='7' cpuset='9'/>

</cputune>

<resource>

<partition>/machine</partition>

</resource>

<os>

<type arch='x86_64' machine='pc-q35-9.2'>hvm</type>

<loader readonly='yes' type='pflash' format='raw'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi-tpm.fd</loader>

<nvram format='raw'>/etc/libvirt/qemu/nvram/e05d58a1-e3fc-859a-7670-a211f88da6e1_VARS-pure-efi-tpm.fd</nvram>

</os>

<features>

<acpi/>

<apic/>

<hyperv mode='custom'>

<relaxed state='on'/>

<vapic state='on'/>

<spinlocks state='on' retries='8191'/>

<vpindex state='on'/>

<synic state='on'/>

<stimer state='on'/>

<vendor_id state='on' value='none'/>

</hyperv>

</features>

<cpu mode='host-passthrough' check='none' migratable='on'>

<topology sockets='1' dies='1' clusters='1' cores='4' threads='2'/>

<cache mode='passthrough'/>

</cpu>

<clock offset='localtime'>

<timer name='hpet' present='no'/>

<timer name='hypervclock' present='yes'/>

</clock>

<on_poweroff>destroy</on_poweroff>

<on_reboot>restart</on_reboot>

<on_crash>restart</on_crash>

<devices>

<emulator>/usr/local/sbin/qemu</emulator>

<disk type='file' device='disk'>

<driver name='qemu' type='qcow2' cache='writeback' discard='unmap'/>

<source file='/mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2' index='2'/>

<backingStore type='file' index='3'>

<format type='qcow2'/>

<source file='/mnt/cache/domains/Windows 11/vdisk1.qcow2'/>

<backingStore/>

</backingStore>

<target dev='hdc' bus='virtio'/>

<serial>vdisk1</serial>

<boot order='1'/>

<alias name='virtio-disk2'/>

<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>

</disk>

<disk type='file' device='cdrom'>

<driver name='qemu' type='raw'/>

<source file='/mnt/user/isos/virtio-win-0.1.285-1.iso' index='1'/>

<backingStore/>

<target dev='hdb' bus='sata'/>

<readonly/>

<alias name='sata0-0-1'/>

<address type='drive' controller='0' bus='0' target='0' unit='1'/>

</disk>

<controller type='pci' index='0' model='pcie-root'>

<alias name='pcie.0'/>

</controller>

<controller type='pci' index='1' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='1' port='0x8'/>

<alias name='pci.1'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/>

</controller>

<controller type='pci' index='2' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='2' port='0x9'/>

<alias name='pci.2'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>

</controller>

<controller type='pci' index='3' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='3' port='0xa'/>

<alias name='pci.3'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>

</controller>

<controller type='pci' index='4' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='4' port='0xb'/>

<alias name='pci.4'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/>

</controller>

<controller type='pci' index='5' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='5' port='0xc'/>

<alias name='pci.5'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x4'/>

</controller>

<controller type='pci' index='6' model='pcie-root-port'>

<model name='pcie-root-port'/>

<target chassis='6' port='0xd'/>

<alias name='pci.6'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x5'/>

</controller>

<controller type='pci' index='7' model='pcie-to-pci-bridge'>

<model name='pcie-pci-bridge'/>

<alias name='pci.7'/>

<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>

</controller>

<controller type='virtio-serial' index='0'>

<alias name='virtio-serial0'/>

<address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>

</controller>

<controller type='sata' index='0'>

<alias name='ide'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>

</controller>

<controller type='usb' index='0' model='qemu-xhci' ports='15'>

<alias name='usb'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>

</controller>

<interface type='bridge'>

<mac address='52:54:00:33:2c:ad'/>

<source bridge='br0'/>

<target dev='vnet2'/>

<model type='virtio-net'/>

<alias name='net0'/>

<address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>

</interface>

<serial type='pty'>

<source path='/dev/pts/0'/>

<target type='isa-serial' port='0'>

<model name='isa-serial'/>

</target>

<alias name='serial0'/>

</serial>

<console type='pty' tty='/dev/pts/0'>

<source path='/dev/pts/0'/>

<target type='serial' port='0'/>

<alias name='serial0'/>

</console>

<channel type='unix'>

<source mode='bind' path='/run/libvirt/qemu/channel/4-Windows 11/org.qemu.guest_agent.0'/>

<target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>

<alias name='channel0'/>

<address type='virtio-serial' controller='0' bus='0' port='1'/>

</channel>

<input type='tablet' bus='usb'>

<alias name='input0'/>

<address type='usb' bus='0' port='1'/>

</input>

<input type='mouse' bus='ps2'>

<alias name='input1'/>

</input>

<input type='keyboard' bus='ps2'>

<alias name='input2'/>

</input>

<tpm model='tpm-tis'>

<backend type='emulator' version='2.0' persistent_state='yes'/>

<alias name='tpm0'/>

</tpm>

<graphics type='vnc' port='5900' autoport='yes' websocket='5700' listen='0.0.0.0' sharePolicy='ignore'>

<listen type='address' address='0.0.0.0'/>

</graphics>

<audio id='1' type='none'/>

<video>

<model type='qxl' ram='65536' vram='16384' vgamem='16384' heads='1' primary='yes'/>

<alias name='video0'/>

<address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/>

</video>

<hostdev mode='subsystem' type='pci' managed='yes'>

<driver name='vfio'/>

<source>

<address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>

</source>

<alias name='hostdev0'/>

<address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>

</hostdev>

<hostdev mode='subsystem' type='pci' managed='yes'>

<driver name='vfio'/>

<source>

<address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/>

</source>

<alias name='hostdev1'/>

<address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>

</hostdev>

<watchdog model='itco' action='reset'>

<alias name='watchdog0'/>

</watchdog>

<memballoon model='none'/>

</devices>

<seclabel type='dynamic' model='dac' relabel='yes'>

<label>+0:+100</label>

<imagelabel>+0:+100</imagelabel>

</seclabel>

</domain>

Note how the cache directory is only mentioned in the latter (ie. When it's running)
What can I do??

Edited August 23Aug 23 by Corvus

Anyone?

The references may be related to the snapshots; you can remove and consolidate the snapshot in the main vdisk, that should get rid of the references.

6 hours ago, JorgeB said:

The references may be related to the snapshots; you can remove and consolidate the snapshot in the main vdisk, that should get rid of the references.

How do I do this, step by step?

And do I risk losing anything by doing this?

SHould be in the docs below, and you would only lose the snapshot, not the current data.

https://docs.unraid.net/unraid-os/using-unraid-to/create-virtual-machines/vm-setup/#vm-snapshots

2 minutes ago, JorgeB said:

SHould be in the docs below, and you would only lose the snapshot, not the current data.

https://docs.unraid.net/unraid-os/using-unraid-to/create-virtual-machines/vm-setup/#vm-snapshots

Just so I understand, is the qcow2 file the snapshot?
Just trying to understand the logic of how removing the snapshot will fix this.

Do you mean that the only thing left preventing me from relocating the qcow2 file into the new VM pool is that the snapshot is expecting it to be there?

Does that mean that after deleting the snapshot I can just move over the qcow2 file into the new directory and it should work?

When you create a snapshot, a local qcow2 file is created to reference it. Getting rid of those files, and restoring only the vdisk should resolve the issue.

On 8/25/2026 at 1:40 AM, JorgeB said:

When you create a snapshot, a local qcow2 file is created to reference it. Getting rid of those files, and restoring only the vdisk should resolve the issue.

Ok so I've followed the steps as outlined in the documention below:

Go to the VMs tab in the WebGUI.

1. Click on the VM name to expand its details.

2. Navigate to the Snapshots section.

3. Use the available buttons for Revert, Block Commit, Block Pull, or Remove.

4. Remove snapshot: This simply deletes the snapshot overlay file without affecting your VM. Your VM continues using the original disk file, and any changes made after the snapshot are lost.

And now when I go to start my VM, it says the following error:

I checked my vdiskpool/domains/Windows 11/ directory and the vdisk1.provisionedqcow2 file is now missing.

Didn't you say that the snapshot creates a qcow2 file?
Why did it remove the vdisk1.provisionedqcow2 file instead?
There is a 'visk1.qcow2' file in the vdiskpool/domains/Windows 11/ directory but it doesn't seem to matter because it seems to be looking for a vdisk1.provisionedqcow2 file.

Luckily I saved a backup of the file, and restoring it to the vdiskpool/domains/Windows 11/ directory works, but now I'm back to square one right? I can confirm that while running, the VM still has the reference to that vdisk1.qcow2 file located in /mnt/cache/domains/Windows 11/vdisk1.qcow2, but disappears as soon as I shut down the VM.

How do I fix this? Please explain like I'm 5.

Edited August 26Aug 26 by Corvus

I've changed the first 'source file' from the screenshot above from /mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2 to /mnt/vdiskpool/domains/Windows 11/vdisk1.qcow2, and now it deletes any mention of the cache directory.

HOWEVER, what you said about losing the snapshot and not the data was wrong - it's actually an older state of my VM from a few months ago when I created the snapshot.

I lost months of data on this.

I could restore the vdisk1.provisionedqcow2 file, but then I'm back to square 1.
Is there a way to retain the latest version of the VM while killing the snapshot?

Anyone?

I had replied earlier, but somehow it didn't show, I think the correct option would be doing a block commit, like mentioned in the docs:

Block Commit: This process copies all changes from the snapshot overlay back into the original VM disk file. By default, it shows "Pivot" and "Delete" options selected:

• Pivot: This option switches your VM from using the overlay file back to using the original disk file. After the commit, your VM will use the original disk (which now contains the changes) instead of the overlay file.

• Delete: This option removes the snapshot overlay file after the changes have been committed to the original disk.

• Together ("Pivot" + "Delete"):

  • With both selected: Changes are committed to the original file, your VM switches back to using the original disk, and the overlay file is deleted. This is the most common choice.

  • With both unchecked: Changes are committed to the original file, but your VM continues using the overlay file, and the overlay file remains to capture future changes.

20 hours ago, JorgeB said:

I had replied earlier, but somehow it didn't show, I think the correct option would be doing a block commit, like mentioned in the docs:

Block Commit: This process copies all changes from the snapshot overlay back into the original VM disk file. By default, it shows "Pivot" and "Delete" options selected:

• Pivot: This option switches your VM from using the overlay file back to using the original disk file. After the commit, your VM will use the original disk (which now contains the changes) instead of the overlay file.

• Delete: This option removes the snapshot overlay file after the changes have been committed to the original disk.

• Together ("Pivot" + "Delete"):

  • With both selected: Changes are committed to the original file, your VM switches back to using the original disk, and the overlay file is deleted. This is the most common choice.

  • With both unchecked: Changes are committed to the original file, but your VM continues using the overlay file, and the overlay file remains to capture future changes.

I can't see in the docs how to do this.
There is no longer a 'snapshots' icon to click on in the VM, even when it's not running.
Can you please explain, step by step? I have no idea what I'm doing.

Edited August 29Aug 29 by Corvus

Post the diagnostics and the contents of that Windows 11 folder.

3 hours ago, JorgeB said:

Post the diagnostics and the contents of that Windows 11 folder.

nas-diagnostics-20260829-2002.zip

Sorry, my earlier advice to use "Remove" was not clear for what you were trying to preserve. Remove discards the overlay containing changes made after the snapshot, which is why the VM reverted to its months-old state. It was fortunate that you had backed up the overlay. I meant remove the snapshot in the general sense, not use the remove option, but I should have been more clear.

The diagnostics and screenshot now make the situation clear:

- vdisk1.provisionedqcow2 on vdiskpool is the active overlay containing your newer changes.

- vdisk1.qcow2 on cache is the older base image.

- The current VM state is produced by reading both files together.

That is also why the cache path appears only in the running XML: libvirt reads the backing-file relationship stored inside the overlay when the VM starts.

For now, please do not delete, rename, move, or overwrite either file, and do not change the VM XML again.

1. Shut down the VM.

2. Make independent backup copies of both qcow2 files.

3. Run these commands and post the complete output:

qemu-img info --backing-chain "/mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2"

cat "/etc/libvirt/qemu/snapshotdb/Windows 11/snapshots.db"

If the second command says the file does not exist, please post that result too.

Once we confirm that there are only those two layers, the safest approach will likely be to convert the active overlay into a new standalone qcow2 file on vdiskpool. That will combine the current state into a new file while leaving both original files untouched until the new disk has been tested.

I also noticed that although the domains share now uses vdiskpool, VM Manager’s default storage path is still /mnt/cache/domains/. We should correct that after recovering the VM so future VM files do not default to the old pool.

Ok thanks for being thorough.

Here's the output for the commands:



For my own education, can you please explain what they did?

Thanks, this confirms exactly what is happening. Both commands were read-only and did not change anything.

qemu-img info --backing-chain followed the disk chain from newest to oldest. It found exactly two layers:

1. /mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2 — the active overlay containing your newer changes.

2. /mnt/cache/domains/Windows 11/vdisk1.qcow2 — the older base image.

There is no third layer. Your current 64 GiB virtual disk is the combined view of those two files.

The second command displayed Unraid’s snapshot database. Its output was blank; that means the database is empty. This explains why the Snapshots section no longer appears in the WebGUI. It does not remove the backing-file relationship stored inside vdisk1.provisionedqcow2, which is why the cache file still appears in the running XML.

We should not use Remove or Block Commit now. Block Commit would write the changes into the old base on cache, while modifying the existing overlay in place would add unnecessary risk. The safest approach is to read the complete two-file chain and write its current state into a third, new, standalone qcow2 file.

First:

1. Shut down the VM and temporarily disable its autostart.

2. Confirm that you have independent backup copies of both original qcow2 files.

3. Make sure the following destination file does not already exist.

Then run:

qemu-img convert -p -f qcow2 -O qcow2 "/mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2" "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2"

This reads the current guest-visible state through both existing files and writes it into the new vdisk1.flattened.qcow2. It does not modify either original.

After conversion, run:

qemu-img check "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2"

qemu-img info --backing-chain "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2"

qemu-img compare -p -f qcow2 -F qcow2 "/mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2" "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2"

The expected results are:

- qemu-img check reports no errors.

- qemu-img info lists only vdisk1.flattened.qcow2 and no backing file.

- qemu-img compare reports that the images are identical.

Post those results before changing or deleting anything. Once they pass, we can point the stopped VM at vdisk1.flattened.qcow2, boot it and verify that the latest data is present. Keep both original files and their backups until the new disk has been thoroughly checked.

After recovery, we should also change VM Manager’s default storage path from /mnt/cache/domains/ to the new VM pool.

On 8/30/2026 at 5:22 PM, JorgeB said:

Thanks, this confirms exactly what is happening. Both commands were read-only and did not change anything.

qemu-img info --backing-chain followed the disk chain from newest to oldest. It found exactly two layers:

1. /mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2 — the active overlay containing your newer changes.

2. /mnt/cache/domains/Windows 11/vdisk1.qcow2 — the older base image.

There is no third layer. Your current 64 GiB virtual disk is the combined view of those two files.

The second command displayed Unraid’s snapshot database. Its output was blank; that means the database is empty. This explains why the Snapshots section no longer appears in the WebGUI. It does not remove the backing-file relationship stored inside vdisk1.provisionedqcow2, which is why the cache file still appears in the running XML.

We should not use Remove or Block Commit now. Block Commit would write the changes into the old base on cache, while modifying the existing overlay in place would add unnecessary risk. The safest approach is to read the complete two-file chain and write its current state into a third, new, standalone qcow2 file.

First:

1. Shut down the VM and temporarily disable its autostart.

2. Confirm that you have independent backup copies of both original qcow2 files.

3. Make sure the following destination file does not already exist.

Then run:

qemu-img convert -p -f qcow2 -O qcow2 "/mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2" "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2"

This reads the current guest-visible state through both existing files and writes it into the new vdisk1.flattened.qcow2. It does not modify either original.

After conversion, run:

qemu-img check "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2"

qemu-img info --backing-chain "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2"

qemu-img compare -p -f qcow2 -F qcow2 "/mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2" "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2"

The expected results are:

- qemu-img check reports no errors.

- qemu-img info lists only vdisk1.flattened.qcow2 and no backing file.

- qemu-img compare reports that the images are identical.

Post those results before changing or deleting anything. Once they pass, we can point the stopped VM at vdisk1.flattened.qcow2, boot it and verify that the latest data is present. Keep both original files and their backups until the new disk has been thoroughly checked.

After recovery, we should also change VM Manager’s default storage path from /mnt/cache/domains/ to the new VM pool.

Thanks for this. Sorry it took me so long to try it, as work kept me busy.

Here's the output from all commands. Seems to have worked successfully. What do I do now? How do I point the VM correctly? Anything else I need to do?

Everything looks good to me, the next safe steps are:

1. Keep the VM stopped with autostart disabled.

2. Open the VM editor in Form View.

3. Set the primary vDisk location manually to:

/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2

4. Apply the change, then reopen the VM configuration and confirm it references the flattened file.

5. Start the VM and verify that the newest files and application data are present.

6. Keep both original qcow2 files and their backup copies until the flattened VM has been thoroughly verified.

7. Afterwards, change VM Manager’s default storage path from /mnt/cache/domains/ to /mnt/vdiskpool/domains/.

36 minutes ago, JorgeB said:

Everything looks good to me, the next safe steps are:

1. Keep the VM stopped with autostart disabled.

2. Open the VM editor in Form View.

3. Set the primary vDisk location manually to:

/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2

4. Apply the change, then reopen the VM configuration and confirm it references the flattened file.

5. Start the VM and verify that the newest files and application data are present.

6. Keep both original qcow2 files and their backup copies until the flattened VM has been thoroughly verified.

7. Afterwards, change VM Manager’s default storage path from /mnt/cache/domains/ to /mnt/vdiskpool/domains/.

Just did all that.

Worked successfully!

Thanks so much man, I never would have figured that out on my own!
I guess I can delete any duplicate vdisk in /cache/domains now? (backups are stored elsewhere)

1 hour ago, Corvus said:

I guess I can delete any duplicate vdisk in /cache/domains now? (backups are stored elsewhere)

If the VM is now pointing to /mnt/vdiskpool you can delete those files.