On 10/10/2025 at 8:50 PM, JorgeB said:

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.

@JorgeB Has any progress been made on an updated guide to Snapshots for Unraid 7+? Where would I find it if it were posted?

I'm still hoping to have @SimonF clarify the correct procedure for removing and merging unwanted snapshots back into the base IMG, based on my XML files posted.

The general docs have been added, but more advanced stuff may not be covered

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

On 11/28/2025 at 4:37 PM, timg11 said:

@JorgeB Has any progress been made on an updated guide to Snapshots for Unraid 7+? Where would I find it if it were posted?

I'm still hoping to have @SimonF clarify the correct procedure for removing and merging unwanted snapshots back into the base IMG, based on my XML files posted.

Sorry for the delay in getting back to you.

The Windows VM looks like it is not using the snapshot files but I don't know why the snapshot.db is still there as the entries should be removed. Unless you manually change the disk images.

Files are stored as follows.

In domains/VMName Disk files, overlayfiles, memory dump, and running config.

in /etc/libvirt/qemu XML, NVRAM, /snapshotdb/VMName is the snapshot db.

Looking at the XML the windows vm is using the main image files so any snapshot overlay files should be ok to remove. you can remove the snapshotdb.

Will look at the debian one soon. It you want to send me ls of the directories I can check further.

I will create a utility to do a sence check on Snapshots to look for issues and do some testing to see if an issue has crept in.

@SimonF thanks for the reply. Here are some of the directory content's you mentioned:

root@T440:/mnt/user/domains/Windows 11# ls -ltr

total 38818060

-rw-r--r-- 1 root root 6778 Jun 21 14:04 S20250621140445.running

-rw-r--r-- 1 root root 6778 Jun 21 14:10 Windows--generate.running

-rw-r--r-- 1 root root 6960 Aug 24 13:27 S20250824132729.running

-rw-r--r-- 1 root root 7148 Sep 1 16:47 2025-09-01--generate.running

-rw-r--r-- 1 root root 7349 Sep 27 12:32 S20250927123248.running

-rwxrwxrwx 1 root users 107374182400 Dec 10 14:26 vdisk1.img*

root@T440:/mnt/user/domains/Windows 11#

root@T440:/mnt/user/domains/Debian# ls -ltr

total 23688028

-rw-r--r-- 1 root root 7353 Jun 21 14:02 debian-snap-2025-06-21--generate.running

-rwxrwxrwx 1 root users 32212254720 Jun 21 14:09 vdisk1.img*

-rw-r--r-- 1 root root 7353 Jun 21 14:10 Debian2025-06-21--generate.running

-rw------- 1 root users 1130758144 Jul 13 16:38 vdisk1.Debian2025-06-21--generateqcow2

-rw-r--r-- 1 root root 7540 Jul 13 16:38 S20250713163832.running

-rw-r--r-- 1 root root 7724 Aug 10 13:18 S20250810131826.running

-rw------- 1 root users 777977856 Aug 10 13:18 vdisk1.S20250713163832qcow2

-rw-r--r-- 1 root root 7724 Aug 10 13:18 S20250810131841.running

-rw------- 1 root users 9655549952 Aug 24 13:15 vdisk1.S20250810131841qcow2

-rw-r--r-- 1 root root 7916 Aug 24 13:15 S20250824131502.running

-rw------- 1 root users 9864347648 Dec 10 14:31 vdisk1.S20250824131502qcow2

root@T440:/mnt/user/domains/Debian#

root@T440:/etc/libvirt/qemu# ls -ltr

total 16

drwxr-xr-x 1 root root 40 Apr 13 2025 networks/

drwxr-xr-x 1 root root 34 Apr 27 2025 swtpm/

drwxr-xr-x 1 root root 32 Jun 21 14:10 snapshotdb/

drwxr-xr-x 1 root users 0 Oct 4 17:43 snapshot/

drwxr-xr-x 1 root root 1894 Oct 26 11:07 nvram/

drwxr-xr-x 1 root root 48 Nov 28 16:43 autostart/

-rw------- 1 root root 6265 Dec 10 13:28 Debian.xml

-rw------- 1 root root 7335 Dec 10 13:28 Windows\ 11.xml

root@T440:/etc/libvirt/qemu#

Note that above there is a file named "S20250824132729.running" and a file "2025-09-01--generate.running" in the directory /mnt/user/domains/Windows 11#

However these files seem to be quite small in size compared to the .img files.

Note that above there are also files matching these names in the directory /mnt/user/domains/Debian#

For the Debian VM, the files appear in pairs. For the S20250824131502 Snapshot, there are two files. vdisk1.S20250810131841qcow2 and S20250824131502.running. The vdisk1.*qcow2 files are very large.

root@T440:/etc/libvirt/qemu/snapshotdb# ls

Debian/ Windows\ 11/

root@T440:/etc/libvirt/qemu/snapshotdb# cd Debian/

root@T440:/etc/libvirt/qemu/snapshotdb/Debian# ls

snapshots.db

root@T440:/etc/libvirt/qemu/snapshotdb/Debian# cd ../Windows\ 11/

root@T440:/etc/libvirt/qemu/snapshotdb/Windows 11# ls

snapshots.db

Win_snapshots.dbDeb_snapshots.db

Edited December 10, 2025Dec 10 by timg11

The thing I'm looking for experts to confirm is the correct procedure for removing and merging unwanted snapshots back into the base IMG.

There was conflicting information earlier in the thread on how to proceed with a Block Commit when there are multiple snapshots. Should I start with the most recent (at the bottom of the tree), and sequentially work my way up performing a block commit on each? Or start with the top of the tree (first/oldest snapshot), do a block commit on it, and it will automatically incorporates the changes from the subsequent snapshots in the tree below it?

Either approach sounds plausible, and I expect doing it wrong could result in data loss by setting the VM to a point in the past.

On 12/14/2025 at 5:31 PM, timg11 said:

The thing I'm looking for experts to confirm is the correct procedure for removing and merging unwanted snapshots back into the base IMG.

There was conflicting information earlier in the thread on how to proceed with a Block Commit when there are multiple snapshots. Should I start with the most recent (at the bottom of the tree), and sequentially work my way up performing a block commit on each? Or start with the top of the tree (first/oldest snapshot), do a block commit on it, and it will automatically incorporates the changes from the subsequent snapshots in the tree below it?

Either approach sounds plausible, and I expect doing it wrong could result in data loss by setting the VM to a point in the past.

When doing the commit select the last one if you want to commit all into the original you can leave the defaults. There is a bug I am working on that the snapshots in the GUI will leave info about the middle snapshot but it is just a ghost record in the snapshotdb file.

base is the first image in the tree with top being the latest.

@simonF, It seems that my Unraid 7.2 setup differs from your, which makes me nervous. You say "base is the first image in the tree with top being the latest."
Here is my snapshot tree for Debian:

Using the DATE/TIME field, it appears the latest is at the bottom.

Here are the raw files, which don't lie, but also don't show the tree relationship.

root@T440:/mnt/user/domains/Debian# ls -l

total 23813084

-rw-r--r-- 1 root root 7353 Jun 21 2025 Debian2025-06-21--generate.running

-rw-r--r-- 1 root root 7540 Jul 13 16:38 S20250713163832.running

-rw-r--r-- 1 root root 7724 Aug 10 13:18 S20250810131826.running

-rw-r--r-- 1 root root 7724 Aug 10 13:18 S20250810131841.running

-rw-r--r-- 1 root root 7916 Aug 24 13:15 S20250824131502.running

-rw-r--r-- 1 root root 7353 Jun 21 2025 debian-snap-2025-06-21--generate.running

-rw------- 1 root users 1130758144 Jul 13 16:38 vdisk1.Debian2025-06-21--generateqcow2

-rw------- 1 root users 777977856 Aug 10 13:18 vdisk1.S20250713163832qcow2

-rw------- 1 root users 9655549952 Aug 24 13:15 vdisk1.S20250810131841qcow2

-rw------- 1 root users 9864347648 Dec 22 16:17 vdisk1.S20250824131502qcow2

-rwxrwxrwx 1 root users 32212254720 Jun 21 2025 vdisk1.img*

root@T440:/mnt/user/domains/Debian#

Because the snapshot UI has bugs and inconsistencies, I got an AI recommendation to go with CLI:

🛠️ How to Flatten your Snapshot Chain

This process will create a new, 100% independent "Gold Image" from your current state.

1. Stop the VM: You cannot safely flatten the chain while the VM is running.

2. Open the Unraid Terminal: Navigate to your VM directory: cd /mnt/user/domains/Debian/

3. Run the Convert Command: Identify your latest snapshot file from your ls output: vdisk1.S20250824131502qcow2. Run this command:

   Bash

   qemu-img convert -O raw vdisk1.S20250824131502qcow2 vdisk1_flattened.img
   

   • What this does: It reads the latest snapshot, looks back through every parent file in the chain, and writes one single, consolidated raw image file containing everything.

🔄 Swapping to the New Flattened Image

Once the command finishes, you will have a new file named vdisk1_flattened.img. To use it:

1. Backup the old files: Move the old .qcow2 files and the original vdisk1.img into a "TEMP" folder just in case.

2. Rename: Rename vdisk1_flattened.img to vdisk1.img.

3. Edit VM Settings: In the Unraid VM settings, ensure the Primary vDisk is pointing to the new vdisk1.img.

4. Start the VM: It should boot exactly as it was, but now it is a "single file" VM again with no dependencies on snapshots.
   

Is that process valid and safe to get back to a single IMG?

If the web UI is up to the task and better than the AI's CLI process, can you give me a step by step procedure?

Maybe it is just as simple as this:

1) click on most recent snapshot (Bottom). In my case, it is S20250824131502. Click on Block Commit.

2) wait for process to finish.
3) click on next most recent snapshot (now moved to bottom of tree since the prior one has been merged?) Click on Block Commit.
4) repeat (working up the tree from bottom leaf to top root, until all snapshots are gone (or will they never by gone because of the bug with the ghost record you mentioned?)

PS - I have changed my profile "Personal text" and "About Me" to "Unraid 7.2.2 on Dell T440 server with Windows 11 VM and Debian 13 VM" yet every post still has Unraid 7.0.1. Is posting signature yet another setting I am unable to find?

Edited December 22, 2025Dec 22 by timg11

19 minutes ago, timg11 said:

@simonF, It seems that my Unraid 7.2 setup differs from your, which makes me nervous. You say "base is the first image in the tree with top being the latest."
Here is my snapshot tree for Debian:

Using the DATE/TIME field, it appears the latest is at the bottom.

Here are the raw files, which don't lie, but also don't show the tree relationship.

root@T440:/mnt/user/domains/Debian# ls -l

total 23813084

-rw-r--r-- 1 root root 7353 Jun 21 2025 Debian2025-06-21--generate.running

-rw-r--r-- 1 root root 7540 Jul 13 16:38 S20250713163832.running

-rw-r--r-- 1 root root 7724 Aug 10 13:18 S20250810131826.running

-rw-r--r-- 1 root root 7724 Aug 10 13:18 S20250810131841.running

-rw-r--r-- 1 root root 7916 Aug 24 13:15 S20250824131502.running

-rw-r--r-- 1 root root 7353 Jun 21 2025 debian-snap-2025-06-21--generate.running

-rw------- 1 root users 1130758144 Jul 13 16:38 vdisk1.Debian2025-06-21--generateqcow2

-rw------- 1 root users 777977856 Aug 10 13:18 vdisk1.S20250713163832qcow2

-rw------- 1 root users 9655549952 Aug 24 13:15 vdisk1.S20250810131841qcow2

-rw------- 1 root users 9864347648 Dec 22 16:17 vdisk1.S20250824131502qcow2

-rwxrwxrwx 1 root users 32212254720 Jun 21 2025 vdisk1.img*

root@T440:/mnt/user/domains/Debian#

Because the snapshot UI has bugs and inconsistencies, I got an AI recommendation to go with CLI:

🛠️ How to Flatten your Snapshot Chain

This process will create a new, 100% independent "Gold Image" from your current state.

1. Stop the VM: You cannot safely flatten the chain while the VM is running.

2. Open the Unraid Terminal: Navigate to your VM directory: cd /mnt/user/domains/Debian/

3. Run the Convert Command: Identify your latest snapshot file from your ls output: vdisk1.S20250824131502qcow2. Run this command:

   Bash

   qemu-img convert -O raw vdisk1.S20250824131502qcow2 vdisk1_flattened.img
   

   • What this does: It reads the latest snapshot, looks back through every parent file in the chain, and writes one single, consolidated raw image file containing everything.

🔄 Swapping to the New Flattened Image

Once the command finishes, you will have a new file named vdisk1_flattened.img. To use it:

1. Backup the old files: Move the old .qcow2 files and the original vdisk1.img into a "TEMP" folder just in case.

2. Rename: Rename vdisk1_flattened.img to vdisk1.img.

3. Edit VM Settings: In the Unraid VM settings, ensure the Primary vDisk is pointing to the new vdisk1.img.

4. Start the VM: It should boot exactly as it was, but now it is a "single file" VM again with no dependencies on snapshots.
   

Is that process valid and safe to get back to a single IMG?

If the web UI is up to the task and better than the AI's CLI process, can you give me a step by step procedure?

Maybe it is just as simple as this:

1) click on most recent snapshot (Bottom). In my case, it is S20250824131502. Click on Block Commit.

2) wait for process to finish.
3) click on next most recent snapshot (now moved to bottom of tree since the prior one has been merged?) Click on Block Commit.
4) repeat (working up the tree from bottom leaf to top root, until all snapshots are gone (or will they never by gone because of the bug with the ghost record you mentioned?)

PS - I have changed my profile "Personal text" and "About Me" to "Unraid 7.2.2 on Dell T440 server with Windows 11 VM and Debian 13 VM" yet every post still has Unraid 7.0.1. Is posting signature yet another setting I am unable to find?

You can run qemu-img info last_snap_file | grep backing and this will show the tree. You can use the flatten method as that is a solution that would be used to make a backup.

The bug is just removing the snapshotdb entry for the gui if there are more than 2 snaps.

Select on the last snap and commit using --base and --top this will collapse the whole tree back into the base image.

root@computenode:~# qemu-img info /mnt/user/domains2/Arch9/vdisk1.S20250321211701qcow2 | grep backing

backing file: /mnt/user/domains2/Arch9/vdisk1.img

backing file format: raw

root@computenode:~#

So, assuming I have 3 snapshots and want to keep the most recent and delete the other two, leaving my VM in its current state. According to the documentation, both block commit and block pull will achieve the desired outcome, except that with pull, you continue using the independent overlay image instead of the original base image.

So;

1: Commit the latest snap and delete the other two, which will permanently leave my VM in its current state. Leaving no snapshots left (assuming you checked delete). And continuing to use the base image (assuming you checked pivot). Here, I can leave pivot and delete unchecked if I want to continue capturing future changes, instead of doing a new snapshot after the commit. (?)

2: Pull the latest snap, and I can delete the other two and the base image if I want. Which will leave my VM in its current state, continuing to use the independent overlay image from now on, with no snapshots left.

Am I understanding it correctly?

Are there any scenarios you want to use one over the other? Assuming I just want to keep the VM in its current state and just get rid of earlier snapshots.

@SimonF Thanks for your help. I performed the flatten process and now the Debian directory looks like this with a single image file:

root@T440:/mnt/user/domains/Debian# ls -ltr

total 11438560

drwxrwxrwx 1 root root 590 Dec 27 10:38 temp/

-rw-r--r-- 1 root users 32212254720 Dec 27 10:53 vdisk1.img

root@T440:/mnt/user/domains/Debian#

When I edited the vdisk back to vdisk1.img, it changed its setting from Manual to Automatic after I Updated.

I am seeing the bug where the old snapshots still show in the GUI:

Is there a manual fix for that, or should I just ignore it?

1 hour ago, timg11 said:

@SimonF Thanks for your help. I performed the flatten process and now the Debian directory looks like this with a single image file:

root@T440:/mnt/user/domains/Debian# ls -ltr

total 11438560

drwxrwxrwx 1 root root 590 Dec 27 10:38 temp/

-rw-r--r-- 1 root users 32212254720 Dec 27 10:53 vdisk1.img

root@T440:/mnt/user/domains/Debian#

When I edited the vdisk back to vdisk1.img, it changed its setting from Manual to Automatic after I Updated.

I am seeing the bug where the old snapshots still show in the GUI:

Is there a manual fix for that, or should I just ignore it?

If you did the flattern outside of the GUI it will not remove the snaps from the db. But now as you do not have any snaps you can just delete the snapshot dB file.

Here's how my "domains" folders look now:

root@T440:/mnt/user/domains# cd Debian/

root@T440:/mnt/user/domains/Debian# ls -l

total 9140352

drwxrwxrwx 1 root root 590 Dec 27 10:38 temp/

-rw-r--r-- 1 root users 32212254720 Dec 29 17:18 vdisk1.img

root@T440:/mnt/user/domains/Debian# cd ../Windows\ 11/

root@T440:/mnt/user/domains/Windows 11# ls -l

total 38000332

-rw-r--r-- 1 root root 7148 Sep 1 16:47 2025-09-01--generate.running

-rw-r--r-- 1 root root 6778 Jun 21 2025 S20250621140445.running

-rw-r--r-- 1 root root 6960 Aug 24 13:27 S20250824132729.running

-rw-r--r-- 1 root root 7349 Sep 27 12:32 S20250927123248.running

-rw-r--r-- 1 root root 6778 Jun 21 2025 Windows--generate.running

-rwxrwxrwx 1 root users 107374182400 Dec 29 17:19 vdisk1.img*

root@T440:/mnt/user/domains/Windows 11#

Which of these would be the "snapshot dB" file that causes the GUI to show the old snapshots?

I've been running with the snapshots flattened, and down to a single .img file.

However, Unraid still thinks that snapshots exist.

You said to remove the .db files, but where do I find them to remove them?

/etc/libvirt/qemu/snapshotdb/VMname/snapshots.db