I'm a new Unraid user, starting with 7.0.1. I'd like to use snapshots to back up my two VMs.

I looked through the long thread on VM Snapshots here. It seems to be mostly discussion on debugging the beta - not a FAQ or tutorial.

The release notes for 7.0.0 only says "Improvements: Added support for VM clones, snapshots, and evdev passthru."

Searches take me to many posts about plugins and other ways of doing snapshots, but they are from before Unraid 7.

Can anyone point me to clear instructions on how to use Unraid 7 to:

1) Create a snapshot of a VM while it is running?

2) specify where the snapshots are stored on the array?

3) restore a snapshot if a VM fails or has to be rolled back?

4) Automate the creation of snapshots periodically?

There is a 1 minute video that seems to imply that these things are possible, but several levels of letterboxing make the Unraid settings in the video too small to be legible.

1 hour ago, timg11 said:

1) Create a snapshot of a VM while it is running?

To create any snapshot from the VM Icon create snapshot with the VM running.

1 hour ago, timg11 said:

2) specify where the snapshots are stored on the array?

Snapshots are stored in the VM directory as the method creates an overlay file for the changes with the base file of the orignal. Note some of my paths are non standard as this is a dev system.

1 hour ago, timg11 said:

3) restore a snapshot if a VM fails or has to be rolled back?

To rollback from the snapshots click on the icon and the menu appears. Revert will return to the previous setup. Block commit push changes in the overlay file back into the orginal. Pull pulls the base file into the overlay to create a new standalone file.

1 hour ago, timg11 said:

4) Automate the creation of snapshots periodically?

There are no options currently to allow this as there is no command available to be added to a script. Functions will be added to the new API in future releases to support but no current time frame.

Note reverting an active snapshot will return the VM to the running state when the snap was taken.

@SimonF Thank you - very helpful introduction!

I tried the Create Snapshot menu item from my Debian VM on the VMs page.

I got this error: "Execution error: Requested operation is not valid: cannot migrate domain: The vdagent chardev doesn't yet support migration"

I tried it with the Windows VM and got this:

"Execution error: Requested operation is not valid: cannot migrate domain: The vdagent chardev doesn't yet support migration; 0000:01:00.0: VFIO migration is not supported in kernel; 0000:03:00.0: VFIO migration is not supported in kernel"

Searching on that error, I found a post from you in the long thread last year where you said "It should work if you dont do the memory dump, but I have not tested."

I tried unchecking memory dump, and it worked without errors. The VMs page now says 1 snapshots.

Surprising to learn that "there is no command available to be added to a script" since that is the next thing I would do after getting it to work manually.

5 minutes ago, timg11 said:

I tried unchecking memory dump, and it worked without errors. The VMs page now says 1 snapshots.

Do you have copy paste enabled?

The vdagent is required to support.

7.1 was the initial implementation of snaps and was GUI based.

Also active snapshots will passthru is not really supported by qemu and kernel currently.

One more question on snapshots. As I (manually) perform a snapshot periodically, these files are building up in /mnt/user/domains/.

How do I clean up obsolete or outdated snapshot files?

I don't want the space taken by snapshots to grow indefinitely.

Coming back to this question - how do I maintain and manage snapshots?

For example, after some system configuration change, I might want to have a clean snapshot baseline.

Now I have a tree of snapshots dating back for months.

How do I clear the current tree and start a new one?

Here's what Gemini has to offer. Seems reasonable, but my experience is that AI is best for when you already are an expert on the subject, or at least know enough to spot hallucinations. Maybe someone very familiar with snapshots can review?

---

To clean up your Unraid VM's vdisk folder, reduce storage usage, and consolidate to a single image file suitable for offline backup, you need to use the snapshot management features to merge the chained differential files back into the base disk.

The process you are looking for is called consolidation or committing the snapshots. This will merge the data from all the .qcow2 differential files into the original base file, vdisk1.img.

---

1. How to Clean Up and Create a New Baseline

The files in your directory represent a chain of snapshots where each subsequent snapshot (and the current running state) is dependent on the previous one:

• vdisk1.img: This is your original base disk image.

• vdisk1.Windows--generateqcow2: This is the first snapshot delta file.

• vdisk1.S20250824132729qcow2: This is the second snapshot delta file, dependent on the first.

• vdisk1.2025-09-01--generateqcow2: This is the third snapshot delta file.

• vdisk1.S20250927123248qcow2: This is the most recent snapshot delta file.

The total space consumed by this VM is the sum of the base disk and all the differential files:

68.7 GB+28.4 GB+9.9 GB+13.4 GB+5.7 GB≈126.1 GB

The Solution: Delete All Snapshots

To clean up and get back to a single baseline file, you must delete all of the existing VM snapshots using the Unraid WebGUI's VM Manager.

1. Stop the VM: The most critical step is to fully shut down the "Windows 11" VM in the Unraid WebGUI. Do not just pause or suspend it.

2. Access Snapshot Manager: Navigate to the VMs tab in the Unraid WebGUI. Click on the "Windows 11" VM and locate the Snapshots section or option.

3. Delete All Snapshots: You will typically need to delete the snapshots one by one, or you may have a "Delete All" option, depending on the Unraid/libvirt implementation.

   • Start by deleting the oldest snapshot first, then proceed through the chain.

   • Each deletion will trigger an automatic disk consolidation/merge process (libvirt/QEMU's blockcommit operation) in the background. This process merges the data from the deleted snapshot's differential file into its parent disk.

4. Wait for Consolidation: Allow time for each consolidation to complete. This can take a significant amount of time depending on the disk size, the amount of data to be merged, and your disk speed.

5. Verify Cleanup: Once all snapshots are deleted, the differential files (vdisk1.*qcow2) should disappear.

The result: The base file vdisk1.img will now contain the latest state of your VM (which includes all the changes from the deleted snapshots), effectively becoming your new "baseline". The overall storage usage will drop significantly (likely close to the base file's initial size plus the total difference, which may still be over 100 GB, but you will have only one file).

Edited September 28, 2025Sep 28 by timg11

I am trying to clean up snapshots on my VM.

The information provided above by Gemini was incorrect. Now it says the correct process is removing snapshots from newest to oldest:

Step-by-Step Consolidation (Newest to Oldest)

You must use the Remove option on each snapshot in this sequence:

1. Remove: vdisk1.S20250927123248qcow2 (Newest)

   • Action: The data from this file is merged into its parent, vdisk1.2025-09-01--generateqcow2.

   • Result: The file vdisk1.S20250927123248qcow2 is deleted.

2. Remove: vdisk1.2025-09-01--generateqcow2

   • Action: The combined data from this updated file is merged into its parent, vdisk1.S20250824132729qcow2.

   • Result: The file vdisk1.2025-09-01--generateqcow2 is deleted.

3. Remove: vdisk1.S20250824132729qcow2

   • Action: The combined data is merged into its parent, vdisk1.Windows--generateqcow2.

   • Result: The file vdisk1.S20250824132729qcow2 is deleted.

4. Remove: vdisk1.Windows--generateqcow2 (Oldest Snapshot)

   • Action: The final combined data is merged into the base disk, vdisk1.img.

   • Result: The file vdisk1.Windows--generateqcow2 is deleted.

Upon completion, only the single, consolidated vdisk1.img file will remain, ready for offline backup.

However, attempting to remove the newest gives "Execution error - Image currently active for this domain."

The VM is stopped but apparently " the underlying disk image is still being held by the system's virtualization layer (libvirt/QEMU)."

Then Gemini suggested releasing it like this:

root@T440:~# virsh list --all

Id Name State

-----------------------------

1 Debian running

- Windows 11 shut off

root@T440:~# virsh destroy "Windows 11"

error: Failed to destroy domain 'Windows 11'

error: Requested operation is not valid: domain is not running

root@T440:~#

That failed too.

Now Gemini suggests: "undefine the domain. Undefining the domain removes its configuration from libvirt's memory, which is the final step that typically releases all persistent resource locks.."

I'm getting suspicious of this long, complex rabbit trail from Gemini. Surely it can't be so difficult to use and manage snapshots.

Can anyone point me to any guidelines or threads on best practices for managing and cleaning snapshots for Unraid VMs?

Edited October 5, 2025Oct 5 by timg11

I would like to remove the snapshots off my VMs, but I read varying approaches here.

I just want to get back to a single, clean .IMG file.

I don't want to risk destroying my VMs.

@SimonF gave a great intro on creating snapshots, but now that I have a better understanding, I want to remove them.
I'm not finding good information - the official documentation apparently hasn't been written yet. As I explained above Gemini AI is taking me down an increasing complex path that seems risky, and has a good chance of being completely incorrect or destroying my VM.

is there is simple, safe way to remove snapshots from a VM and get the VM back to operating from a single IMG file?

2 hours ago, timg11 said:

the official documentation apparently hasn't been written yet

It's being written as we speak, but post a screenshot showing the VM's existing snapshots, and we should be able to give more info.

Thanks @JorgeB here are the screenshots:

Assuming you want to keep the current data, click the last snapshot and then "block commit," leaving the "pivot" and "delete" options enabled for the block commit. It will commit all the changes since the snapshots to the backing vdisk and delete the snapshots.

On 10/11/2025 at 3:24 PM, timg11 said:

Thanks @JorgeB here are the screenshots:

Can you provide the following for the windows VM?

cat /etc/libvirt/qemu/snapshotdb/VM Name/snapshots.db

ls /mnt/user/domains/VM Name

I tried what @JorgeB said, and did a block commit on the newest snapshot for the Windows VM, with pivot and delete. That deleted that one snapshot but 3 remain.

@jorge said "It will commit all the changes since the snapshots to the backing vdisk and delete the snapshots", but since I see a different behavior, I'm checking back here with the experts before proceeding. It's not urgent to delete these snapshots and I definitely don't want to break or corrupt the VMs.

I've attached the snapshots.db from the Windows 11 VM. cat-snapshots.db-Win11.txt

Here is how the VM looks after the one commit:

I re-started the VM and verified that it came up properly. Nothing seems to have been lost, so it is in the desired state.

So should I just repeat the block commit on each of the other snapshots, starting at the bottom (most recent)

Yes /mnt/user/domains has the VM. Here is the directory with my two VMs. I was not paying attention and forgot to use a Linux-friendly name for the Windows VM - Now I'm not sure what would happen if I changed it to Windows_11.

Sorry the paste function on this site is broken again. I cannot paste any text, only images.

Edited October 25, 2025Oct 25 by timg11

If you block committed the top snapshot to base, I believe the other snapshots are no longer relevant and can be deleted, but please wait for @SimonF to confirm.

@JorgeB you said "click the last snapshot and then "block commit,"
I interpreted "last" as being the most recent, or in the tree structure, the bottom one dated 2025-09-27.

If doing a Block Commit on the oldest (top) snapshot will merge all the later ones into the primary image (deleting the snapshots, or making it safe to delete them), that is what I'd like to do. Doing in one step would be preferable, since doing the Block Commit on only the most recent took quite a while.

@SimonF please confirm the correct procedure.

Can you provide virsh dumpxml VMName | xmllint --xpath '//devices/disk' -

This would show which disks are in the VM. It should

But in this example, it should collaspe all snap shots into the base image. I will do some testing. Can you confirm you are on 7.0.1 still or a different verion.

On 10/27/2025 at 1:49 PM, SimonF said:

Can you provide virsh dumpxml VMName | xmllint --xpath '//devices/disk' -

😖Text Paste broken on this site again! CTRL-V, Paste, Paste Without Formatting all ignored. See attached file.

virsh-dumpxlm-windows.txt

Yes still on 7.0.1. - Need to update but my to-do list remains long.....

At any of the vertices of the tree |__ I can click and get a submenu with choices 1) Revert Snapshot 2) Block Commit 3)Block Pull 4) Remove snapshot.

Edited November 1, 2025Nov 1 by timg11

@SimonF Did the virsh dumpxml VMName | xmllint --xpath '//devices/disk' information clarify anything?

Should I update to 7.2 now? Does it make any difference w.r.t. snapshot management?

I'm just looking to remove these unnecessary snapshots in the safest and most efficient manner, without risking the state of the operational VMs.

Block Commit on the oldest (top) snapshot? or Block Commit one by one starting with newest? Or something else?

33 minutes ago, timg11 said:

@SimonF Did the virsh dumpxml VMName | xmllint --xpath '//devices/disk' information clarify anything?

Should I update to 7.2 now? Does it make any difference w.r.t. snapshot management?

I'm just looking to remove these unnecessary snapshots in the safest and most efficient manner, without risking the state of the operational VMs.

Block Commit on the oldest (top) snapshot? or Block Commit one by one starting with newest? Or something else?

Was the VM running at the time? The output only shows that the VM is using just be original image file. Can you provide cat /etc/libvirt/qemu/snapshotdb/AArch/snapshots.db replacing AArch with your VM name.

<disk type="file" device="disk">
      <driver name="qemu" type="raw" cache="writeback" discard="unmap"/>
      <source file="/mnt/user/domains/Windows 11/vdisk1.img" index="3"/>
      <backingStore/>
      <target dev="hdc" bus="sata" rotation_rate="1"/>
      <serial>vdisk1</serial>
      <boot order="1"/>
      <alias name="sata0-0-2"/>
      <address type="drive" controller="0" bus="0" target="0" unit="2"/>
    </disk>

@SimonF The VM is running.

I have attached the output of cat snapshots.db

I've also attached Debian-snapshots.db, which is the status of the Debian VM that also has snapshots I want to clear.

Debian Snapshots:

Windows 11 Snapshots:

snapshots.db Debian-snapshots.db

7 minutes ago, timg11 said:

@SimonF The VM is running.

I have attached the output of cat snapshots.db

I've also attached Debian-snapshots.db, which is the status of the Debian VM that also has snapshots I want to clear.

Debian Snapshots:

Windows 11 Snapshots:

snapshots.db Debian-snapshots.db

Can you provide this for Debian also virsh dumpxml VMName | xmllint --xpath '//devices/disk'

That pipe to xmllint doesn't seem to work as expected:

# virsh dumpxml Debian | xmllint --xpath '//devices/disk'

Usage : xmllint [options] XMLfiles ...

I have attached the full output of virsh dumpxml VMName

virsh_dumpxml_Debian.txt

Debian VM is running

2 hours ago, timg11 said:

That pipe to xmllint doesn't seem to work as expected:

# virsh dumpxml Debian | xmllint --xpath '//devices/disk'

Usage : xmllint [options] XMLfiles ...

I have attached the full output of virsh dumpxml VMName

virsh_dumpxml_Debian.txt

Debian VM is running

Can you send full XML for windows also.

virsh_dumpxml_Windows.txt