VM disk space size too big

[valerio_vanni]

I run Vmware Workstation 14 on a Linux Debian host.

I find, on many virtual machines, an excessive disk space usage.

For example, I analyze a Windows 10 Guest.

Virtual disk is 60 GB, single file not preallocated. Vmware says "Current size 22.5 GB used".

But the VM folder is 127 GB: why?

I've already deleted all snapshot, "defragment disk" and "compact disk" from Vmware WS.

I find inside VM directory many vmdk files.

The referenced one in VM properties is Windows10-cl2.vmdk, 23 GB. But I find also 5 Windows10-cl2-0000***.vmdk, that account for the rest. The latest is 2 month old, the others older than it.

Can I delete them?

If I take a full clone, result is 25 GB.

[a_p_]

The "Windows10-cl2-0000***.vmdk" files are snapshot files. Issues like this can occur if the VM's .vmsd file gets corrupted.

What you may try is:

1. close VMware Workstation, or at least the VM's tab
2. backup the VM's folder (recommended, but up to you)
3. delete the VM's .vmsd file
4. create a new VM snapshot
5. open the Snapshot Manager, select the newly created snapshot, and click "Delete"

André

[valerio_vanni]

I've tried, but it didn't delete anything.

Those files are left untouched, with they original timestamps.

Should I delete them directly? Now I have a backup, the full clone.

[a_p_]

A full clone would have been my next suggestion. Now that you have one, there's no need anymore to keep the old files.

André

[valerio_vanni]

I've tried to delete the files, and VM didn't complain.

Full clone was also my first idea but only as a last resort.

For this VM, I'll keep the clone and throw the original (also if it seems not to complain after file removal). Since I was not interested in saved snapshots, it's a perfect solution.

But I have other machines whose snapshot I would like to keep, and I suspect they are suffering the same issue.

For example, I have another machine (whose snapshot I would like to keep). Real disk size is 20 GB, machine folder is 65 GB. Now I have left 2 snapshot, the oldest is 7 days old and I can exclude that this machine has been able to generate such a diff.

There  are 50 numbered *0000$$.vmdk. And I cannot see how to tell an orphaned vmdk from a valid snapshot one.

And I'd like to understand why all this leftover stuff is created.

[a_p_]

To find out more, I need more details.

Please run ls -lisa > filelist.txt in the VM's folder to get a complete file listing.
Then attach a .zip archive which contains the filelist.txt, the .vmx, and .vmsd file as well as the VM's latest vmware.log, and all of the small .vmdk descriptor files (the ones with only a few hundred bytes in size) to your next reply.

André

[valerio_vanni]

I just collected those files.

In Vmware UI, now, I see 4 snapshots. One manual and three automatic.

[a_p_]

Wow, I've rarely seen something like this.
There are 50 snapshots in the VM's folder, but - according to the log file - only 4 that are active (in use). From those 4 snapshots, one has been created manually, and 3 by "Autoprotect" which is enabled for this VM.

According to the latest log file entries, the following .vmdk files are in use:

DISK: OPEN ide0:0 '/home/valerio/vmware_machines/Windows XP Pro Nuovo/Windows_XP_Pro_Nuovo-19GB-cl3-000040.vmdk' persistent R[]
2023-01-02T12:42:59.787+01:00| vcpu-0| I125: DISKLIB-DSCPTR: Opened [0]: "Windows_XP_Pro_Nuovo-19GB-cl3-000039.vmdk" (0xe)
2023-01-02T12:42:59.787+01:00| vcpu-0| I125: DISKLIB-DSCPTR: Opened [0]: "Windows_XP_Pro_Nuovo-19GB-cl3-000004.vmdk" (0xe)
2023-01-02T12:42:59.787+01:00| vcpu-0| I125: DISKLIB-DSCPTR: Opened [0]: "Windows_XP_Pro_Nuovo-19GB-cl3-000050.vmdk" (0xe)
2023-01-02T12:42:59.787+01:00| vcpu-0| I125: DISKLIB-DSCPTR: Opened [0]: "Windows_XP_Pro_Nuovo-19GB-cl3-flat.vmdk" 0 (0xe)
Opened '/home/valerio/vmware_machines/Windows XP Pro Nuovo/Windows_XP_Pro_Nuovo-19GB-cl3.vmdk

Please note that this may have already changed, due to the Autoprotect setting, so you may need to double-check with the latest entries in the log file as well as in the .vmx file.

What I'd strongly suggest in the current situation, is to backup everything before taking any action!

Then - for the mentioned VM - create a new sub-directory and move all the .vmdk files that are not listed above to that sub-directory. If the VM can be powered on after that, and everything looks as expected, you may proceed with getting rid of the moved files.

As a side note: Autoprotect does not replace backups! Personally I don't use that feature, and rather rely on manually created snapshots, which I create after/before important changes.

André

[valerio_vanni]

Thank you, I'll try. But perhaps at the end I'll restart from a full clone.

Is it the only needed test powering on? Or should I also try to created/delete snapshots?

Merge some of them? I fear I will find some corruption at some point in the future.

I noticed a thing: all referenced files in log have a paired "lock" directory. And it seems ok.

Some other have a lock dir too (2, 16, 26, 36), and some other nothing. Does it mean something (the one not referenced but with a lock)?

Now 51 appeared, and 39 disappeared (autoprotect created one snapshot and deleted one, it seems that this time the right thing has been done).

For autoprotect: I use many levels of backup: autoprotect for everyday things, manual (like you) for relevant changes and full clones on other media for bigger disasters.

[a_p_]

If the VM powers on without complaining about a missing .vmdk file, you're ok. I can't tell you however why these additional snapshot files never got deleted. One reason could be that you've create snapshot-trees at some point in time (resuming a VM from earlier snapshots), and that entry got lost in the .vmsd file!? 
All .lck files, and folders can safely be deleted while the VM is powered off, and VMware Workstation (or at least the VM's tab) is closed. If required these will be recreated the next time you use the VM.

André

[valerio_vanni]

It seems to work, it started without errors.

I've tried to merge a couple of snapshots and got no error. Now it has made its first automatic.

At some point a snapshot tree condition there has been for sure.

Now I'm looking at another machine: real size 40 GB, directory size 100 GB, 4 snapshot referenced in log and 15 vmdk files in directory.

It seems that Workstation doesn't like to delete snapshots.