I just found out that all my guests (on a Windows host) have lots of sav-files using lots of space (A windows guest has 81 such files in the snapshot folder, although the machine has no snapshots; An Ubuntu guest has 3 sav-files without having snapshots, etc).
The oldest of these sav-files is from October 22, 2022, when I installed version 7.02. Currently running 7.0.10.
After experimenting I found out that these sav-files are left behind when taking several consecutive snapshots of a running machine and then deleting some of these (with the gui).
Is this intended behavior? (When all snapshots of running machines are deleted one can manually delete all but the last sav-file, so it seems that its kind of not how this should be intended).
The various discard options (GUI, or command line) do not delete these seemingly orphaned sav-files, so its quite time consuming
to find out which ones are orphaned. Is there any safe way to get rid of the orphaned sav-files ?
.sav-files are not deleted
-
scottgus1
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Windows, Linux
Re: .sav-files are not deleted
Running snapshots do make a .sav file, since the running snapshot requires the VM to start right in the state it was when the snapshot was taken. So the running snapshot uses the Saved State system, which makes the .sav file.
Whether deleting the running snapshot should delete the .sav file or not is a source code perusal thing, and may be a bug. Or it may involve whether there are linked clones attached to the VM.
In a quick test on a VM I found that the name of the .sav file for a running snapshot is listed in the VM's .vbox file.
You could do a text search through the .vbox files for all your VMs for the UUID names of the .sav files. Do all of them, not only the VM whose folder the .sav's are stored in. If no .vbox file mentions the .sav file, you might feel safe deleting it.
I would do a full backup of the whole set of files before deleting anything, though. Or consider moving the unmentioned-in-vboxes .sav files to a new folder outside of the VM folders, so you can put them back if you find they're still needed.
Whether deleting the running snapshot should delete the .sav file or not is a source code perusal thing, and may be a bug. Or it may involve whether there are linked clones attached to the VM.
In a quick test on a VM I found that the name of the .sav file for a running snapshot is listed in the VM's .vbox file.
You could do a text search through the .vbox files for all your VMs for the UUID names of the .sav files. Do all of them, not only the VM whose folder the .sav's are stored in. If no .vbox file mentions the .sav file, you might feel safe deleting it.
I would do a full backup of the whole set of files before deleting anything, though. Or consider moving the unmentioned-in-vboxes .sav files to a new folder outside of the VM folders, so you can put them back if you find they're still needed.
Re: .sav-files are not deleted
Yes, making backups was the method I used, but with 260GB of sav-files this is time consuming.
Good point searching the .vbox files, this will speed up the process, thanks.
It seems that this orphaned sav-file problem didn't exist pre 7.0.2. Do you think its worth to file this as a bug?
(Due to the enormous space that is allocated by the sav-files I can not just leave them as they are handed out)
Good point searching the .vbox files, this will speed up the process, thanks.
It seems that this orphaned sav-file problem didn't exist pre 7.0.2. Do you think its worth to file this as a bug?
(Due to the enormous space that is allocated by the sav-files I can not just leave them as they are handed out)
-
fth0
- Volunteer
- Posts: 5690
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: .sav-files are not deleted
Can you provide exact instructions how to reproduce the issue?
Re: .sav-files are not deleted
Here is what produces (orphaned in my opinion) .sav files:
Host: Windows 10 Prof. with most recent updates installed. (Sep. 3, 2023)
Guest: Windows 10 Prof. with most recent updates installed.
Initially, the guest has one snapshot called "Windows 10", one main .vdi file and one .vdi file in the snapshots\ directory.
The latter is the unique file in the snapshots\ directory (of this Guest; incidentally, today no other guest has a .sav file either).
Step 1) Starting the guest (all actions here are performed with GUI, version v7.0.10)
Step 2) For the running guest, create a snapshot (using Machine>Take Snapshot...) named "Snapshot 1" (This produces a .sav file 2023-09-03T16-33-28-029872200Z.sav in the snapshots\ directory as expected)
Step 3) repeat 2) and create a snapshot named "Snapshot 2", which creates 2023-09-03T16-36-53-383062300Z.sav
Step 4) Shutdown the guest and then create a snaphsot of the guest named "Snapshot 3".
Step 6) Delete Snapshot 1, Snapshot 2 and Snapshot 3 (in that order).
Step 7) Revert the VM to the original "Windows 10" (So we are back to square 0).
Result: The main vdi-file from the beginning is unchanged as expected, the .vdi file from the snapshots\ directory is updated
and the two sav-files are still there. The names of the .sav files (e.g. the string "2023-09-03T16-33-28-029872200Z") are not mentioned in any .vbox file. I can now delete the two .sav files and can start the VM again without problem.
(The two .sav files have about 1.5 GB each)
Let me know if you need more info. Thanks for looking into it
Host: Windows 10 Prof. with most recent updates installed. (Sep. 3, 2023)
Guest: Windows 10 Prof. with most recent updates installed.
Initially, the guest has one snapshot called "Windows 10", one main .vdi file and one .vdi file in the snapshots\ directory.
The latter is the unique file in the snapshots\ directory (of this Guest; incidentally, today no other guest has a .sav file either).
Step 1) Starting the guest (all actions here are performed with GUI, version v7.0.10)
Step 2) For the running guest, create a snapshot (using Machine>Take Snapshot...) named "Snapshot 1" (This produces a .sav file 2023-09-03T16-33-28-029872200Z.sav in the snapshots\ directory as expected)
Step 3) repeat 2) and create a snapshot named "Snapshot 2", which creates 2023-09-03T16-36-53-383062300Z.sav
Step 4) Shutdown the guest and then create a snaphsot of the guest named "Snapshot 3".
Step 6) Delete Snapshot 1, Snapshot 2 and Snapshot 3 (in that order).
Step 7) Revert the VM to the original "Windows 10" (So we are back to square 0).
Result: The main vdi-file from the beginning is unchanged as expected, the .vdi file from the snapshots\ directory is updated
and the two sav-files are still there. The names of the .sav files (e.g. the string "2023-09-03T16-33-28-029872200Z") are not mentioned in any .vbox file. I can now delete the two .sav files and can start the VM again without problem.
(The two .sav files have about 1.5 GB each)
Let me know if you need more info. Thanks for looking into it
-
fth0
- Volunteer
- Posts: 5690
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: .sav-files are not deleted
Thank you for the detailed instructions! 
In one of my own setups, I could reproduce the issue on a Linux host with a Linux guest with only one online snapshot (using your steps 1 and 2, then shutting down the guest, deleting Snapshot 1 and reverting the VM).
I'd suggest to create a ticket in the Bugtracker.
Edit:
Link to the ticket created by the OP: #21833
In one of my own setups, I could reproduce the issue on a Linux host with a Linux guest with only one online snapshot (using your steps 1 and 2, then shutting down the guest, deleting Snapshot 1 and reverting the VM).
I'd suggest to create a ticket in the Bugtracker.
Edit:
Link to the ticket created by the OP: #21833
Last edited by fth0 on 4. Sep 2023, 00:50, edited 1 time in total.
Re: .sav-files are not deleted
Ticket created! Thanks for trying and confirming.
-
Air Force One
- Posts: 133
- Joined: 6. Oct 2017, 16:54
- Primary OS: MS Windows other
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Windows
- Location: Germany
-
fth0
- Volunteer
- Posts: 5690
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: .sav-files are not deleted
The issue here is that at the time VirtualBox deletes a snapshot (.vdi file), it "forgets" to delete the corresponding .sav file if it exists. Thereby, VirtualBox correctly removes any knowledge about the .sav file and doesn't use it any more. Drawbacks are the waste of disk space and the insecurity of old data lying around.
AFAIU your tickets after a quick look, they seem to revolve around the .sav files either being used unexpectedly or snapshots not being deleted when you'd expect it. Please explain here where you see a connection.
AFAIU your tickets after a quick look, they seem to revolve around the .sav files either being used unexpectedly or snapshots not being deleted when you'd expect it. Please explain here where you see a connection.