Failed to reduce the disk space occupied by the client

[SUNVoyager]

It's a long story.

First, I installed Ubuntu 18.04 LTS in VMware Workstation. There are two disks in the virtual machine, one is 150G (denoted as disk1) and the other is 100G (denoted as disk2).

Then, after using the virtual machine for a period of time, I found that the space occupied by the client is getting larger and larger. So I deleted some files stored in Ubuntu.

At the same time, I found a strange phenomenon. The more files deleted, the larger the space occupied by the client. Finally, I found that the space occupied by the virtual machine was up to 200G, which is actually about 100G.

Finally, I searched for some solutions, such as:
(Note: I have deleted the snapshot before executing the command)
①sudo vmware-toolbox-cmd disk shrink /
Error: unable to find the entrance
②vmware-vdiskmanager -k Ubuntu \ Desktop.vmdk
Result: The execution was successful (processing time is very short), but only reduced by about 2G.
③dd if = / dev / zero of = wipefile bs = 1024x1024; rm wipefile
Implementation process: The occupied space continues to increase until 300G.
Terminal prompt: If there is insufficient space to delete the wipefile, I choose yes.
Result: After restarting, the Ubuntu system directly enters the rescue mode. Enter the ls command in the terminal and find that the file system is unknown. At the same time, the virtual machine takes up 300G.

I have some questions here:
①Why delete the files in the Ubuntu system, but occupy more space on the host?
②What is wrong with the above method of using compressed disk?

look forward to your reply. Thank you

[RColbert]

1. When you provision a VM, you set the maximum amount host disk you want to use. The VM will allocate disk as needed as it runs and depending on the file system, that will even grow as you delete files until you hit the maximum vmdk size. In the case of your Ubuntu VM, your guest is running a journaled file system which means it only zeros out disk (which would let the host reclaim it) once you hit the max size of the disk.
2. You aren't using compressed disk, you used what is called Thin Provisioning. The vmdk files start out at a minimum size and grow but do not dynamically shrink.

[a_p_]

At the same time, the virtual machine takes up 300G.

If that's the case without snapshots, then it's likely a bug.

Can you confirm that the VM doesn't have active snapshots, i.e. not <vmname>-00000x.vmdk files in the VM's folder.

André

[SUNVoyager]

I listed the information of all files in disk1 (below).

Directory of Ubuntu642

2020/05/21  15:20    <DIR>          .

2020/05/21  15:20    <DIR>          ..

2020/05/21  15:12     8,589,934,592 564dc812-7519-0768-f7ab-682a602db851.vmem

2020/04/10  16:24     2,363,490,304 Ubuntu642-0-000001-s001.vmdk

2020/04/10  16:24     1,787,756,544 Ubuntu642-0-000001-s002.vmdk

2020/04/10  16:24     4,562,681,856 Ubuntu642-0-000001-s003.vmdk

2020/04/10  16:24     2,504,196,096 Ubuntu642-0-000001-s004.vmdk

2020/04/10  16:24       313,196,544 Ubuntu642-0-000001-s005.vmdk

2020/04/10  16:24        82,706,432 Ubuntu642-0-000001-s006.vmdk

2020/04/10  16:24       248,709,120 Ubuntu642-0-000001-s007.vmdk

2020/04/10  16:23        29,360,128 Ubuntu642-0-000001-s008.vmdk

2020/04/10  16:24       985,530,368 Ubuntu642-0-000001-s009.vmdk

2020/04/10  16:23     2,218,786,816 Ubuntu642-0-000001-s010.vmdk

2020/04/10  16:23       842,792,960 Ubuntu642-0-000001-s011.vmdk

2020/04/10  16:24       947,322,880 Ubuntu642-0-000001-s012.vmdk

2020/04/10  16:24     4,725,604,352 Ubuntu642-0-000001-s013.vmdk

2020/04/10  16:23     4,468,572,160 Ubuntu642-0-000001-s014.vmdk

2020/04/10  16:24     4,931,780,608 Ubuntu642-0-000001-s015.vmdk

2020/04/10  16:24     3,923,116,032 Ubuntu642-0-000001-s016.vmdk

2020/04/10  16:23     4,948,885,504 Ubuntu642-0-000001-s017.vmdk

2020/04/10  16:23     4,911,857,664 Ubuntu642-0-000001-s018.vmdk

2020/04/10  16:24     4,951,769,088 Ubuntu642-0-000001-s019.vmdk

2020/04/10  16:23     4,948,426,752 Ubuntu642-0-000001-s020.vmdk

2020/04/10  16:23     4,913,364,992 Ubuntu642-0-000001-s021.vmdk

2020/04/10  16:23     4,952,031,232 Ubuntu642-0-000001-s022.vmdk

2020/04/10  16:23     4,950,065,152 Ubuntu642-0-000001-s023.vmdk

2020/04/10  16:23     4,908,187,648 Ubuntu642-0-000001-s024.vmdk

2020/04/10  16:23     4,950,065,152 Ubuntu642-0-000001-s025.vmdk

2020/04/10  16:23     4,950,065,152 Ubuntu642-0-000001-s026.vmdk

2020/04/10  16:23     4,908,187,648 Ubuntu642-0-000001-s027.vmdk

2020/04/10  16:23     4,950,065,152 Ubuntu642-0-000001-s028.vmdk

2020/04/10  16:23     4,950,065,152 Ubuntu642-0-000001-s029.vmdk

2020/04/10  16:23     4,732,223,488 Ubuntu642-0-000001-s030.vmdk

2020/04/10  16:23     4,765,515,776 Ubuntu642-0-000001-s031.vmdk

2020/04/10  16:23     3,684,499,456 Ubuntu642-0-000001-s032.vmdk

2020/04/10  16:26             1,878 Ubuntu642-0-000001.vmdk

2020/05/21  21:45     4,756,275,200 Ubuntu642-0-000002-s012.vmdk

2020/05/21  21:45     3,079,077,888 Ubuntu642-0-000002-s013.vmdk

2020/05/21  21:45     2,179,858,432 Ubuntu642-0-000002-s014.vmdk

2020/05/21  21:45     3,987,996,672 Ubuntu642-0-000002-s015.vmdk

2020/05/21  21:45     4,702,208,000 Ubuntu642-0-000002-s016.vmdk

2020/05/21  21:45     4,920,508,416 Ubuntu642-0-000002-s017.vmdk

2020/05/21  21:45     4,939,644,928 Ubuntu642-0-000002-s018.vmdk

2020/05/21  21:45     3,606,577,152 Ubuntu642-0-000002-s019.vmdk

2020/05/21  21:45     4,649,385,984 Ubuntu642-0-000002-s020.vmdk

2020/05/21  21:45     4,938,137,600 Ubuntu642-0-000002-s021.vmdk

2020/05/21  21:45     4,967,563,264 Ubuntu642-0-000002-s022.vmdk

2020/05/21  21:45     4,966,580,224 Ubuntu642-0-000002-s023.vmdk

2020/05/21  21:45     4,932,960,256 Ubuntu642-0-000002-s024.vmdk

2020/05/21  21:45     4,966,580,224 Ubuntu642-0-000002-s025.vmdk

2020/05/21  21:45     4,966,580,224 Ubuntu642-0-000002-s026.vmdk

2020/05/21  21:45     4,932,960,256 Ubuntu642-0-000002-s027.vmdk

2020/05/21  21:45     4,966,580,224 Ubuntu642-0-000002-s028.vmdk

2020/05/21  21:45     4,966,580,224 Ubuntu642-0-000002-s029.vmdk

2020/05/21  21:45     4,924,571,648 Ubuntu642-0-000002-s030.vmdk

2020/05/21  21:45     4,966,580,224 Ubuntu642-0-000002-s031.vmdk

2020/05/21  21:45     3,900,243,968 Ubuntu642-0-000002-s032.vmdk

2020/04/10  16:26     2,426,339,328 Ubuntu642-0-s001.vmdk

2020/04/10  16:26     3,924,754,432 Ubuntu642-0-s002.vmdk

2020/04/10  16:26     4,002,152,448 Ubuntu642-0-s003.vmdk

2020/04/10  16:26     4,067,819,520 Ubuntu642-0-s004.vmdk

2020/04/10  16:26     4,188,209,152 Ubuntu642-0-s005.vmdk

2020/04/10  16:26     4,177,920,000 Ubuntu642-0-s006.vmdk

2020/04/10  16:25     4,208,525,312 Ubuntu642-0-s007.vmdk

2020/04/10  16:25     4,194,697,216 Ubuntu642-0-s008.vmdk

2020/04/10  16:25     4,210,294,784 Ubuntu642-0-s009.vmdk

2020/04/10  16:26     4,150,525,952 Ubuntu642-0-s010.vmdk

2020/04/10  16:26       335,609,856 Ubuntu642-0-s011.vmdk

2020/04/10  16:26     4,103,143,424 Ubuntu642-0-s012.vmdk

2020/04/10  16:26     4,003,725,312 Ubuntu642-0-s013.vmdk

2020/04/10  16:26     3,947,757,568 Ubuntu642-0-s014.vmdk

2020/04/10  16:26     3,915,776,000 Ubuntu642-0-s015.vmdk

2020/04/10  16:26     4,014,931,968 Ubuntu642-0-s016.vmdk

2020/04/10  16:26     3,989,700,608 Ubuntu642-0-s017.vmdk

2020/04/10  16:26     3,940,220,928 Ubuntu642-0-s018.vmdk

2020/02/05  11:24     3,941,597,184 Ubuntu642-0-s019.vmdk

2020/02/05  11:24     2,307,850,240 Ubuntu642-0-s020.vmdk

2020/02/08  12:06           917,504 Ubuntu642-0-s021.vmdk

2020/02/05  11:24           655,360 Ubuntu642-0-s022.vmdk

2020/02/05  11:24           655,360 Ubuntu642-0-s023.vmdk

2020/02/08  12:06           917,504 Ubuntu642-0-s024.vmdk

2020/02/05  11:24           655,360 Ubuntu642-0-s025.vmdk

2020/02/08  12:06           917,504 Ubuntu642-0-s026.vmdk

2020/01/11  09:43            65,536 Ubuntu642-0-s027.vmdk

2020/02/08  16:21           851,968 Ubuntu642-0-s028.vmdk

2020/02/08  16:21           786,432 Ubuntu642-0-s029.vmdk

2020/02/08  16:21           851,968 Ubuntu642-0-s030.vmdk

2020/02/08  16:21           786,432 Ubuntu642-0-s031.vmdk

2020/02/08  16:21           786,432 Ubuntu642-0-s032.vmdk

2020/02/08  16:21           851,968 Ubuntu642-0-s033.vmdk

2020/02/08  16:21           786,432 Ubuntu642-0-s034.vmdk

2020/02/08  16:21           786,432 Ubuntu642-0-s035.vmdk

2020/02/08  16:21           851,968 Ubuntu642-0-s036.vmdk

2020/02/08  16:21           786,432 Ubuntu642-0-s037.vmdk

2020/02/08  16:21           655,360 Ubuntu642-0-s038.vmdk

2020/04/10  16:26             2,073 Ubuntu642-0.vmdk

2020/05/21  21:05             8,684 Ubuntu642.nvram

2019/12/25  12:20               944 Ubuntu642.vmdk

2020/05/21  14:54               128 Ubuntu642.vmsd

2020/05/21  21:59               368 Ubuntu642.vmxf

2020/05/21  15:12    <DIR>          564dc812-7519-0768-f7ab-682a602db851.vmem.lck

2020/05/21  17:59           253,251 vmware-2.log

2020/05/21  18:15    <DIR>          Ubuntu642.vmx.lck

2020/05/21  19:30           547,925 vmware-1.log

2020/05/21  21:06         3,204,971 vmware-0.log

2020/05/21  21:45       988,545,024 Ubuntu642-0-000002-s001.vmdk

2020/05/21  21:45     3,097,755,648 Ubuntu642-0-000002-s002.vmdk

2020/05/21  21:45     3,277,324,288 Ubuntu642-0-000002-s003.vmdk

2020/05/21  21:45     4,453,892,096 Ubuntu642-0-000002-s004.vmdk

2020/05/21  21:45     2,875,129,856 Ubuntu642-0-000002-s005.vmdk

2020/05/21  21:45       549,126,144 Ubuntu642-0-000002-s006.vmdk

2020/05/21  21:45       700,252,160 Ubuntu642-0-000002-s007.vmdk

2020/05/21  21:45        77,070,336 Ubuntu642-0-000002-s008.vmdk

2020/05/21  21:45     1,925,316,608 Ubuntu642-0-000002-s009.vmdk

2020/05/21  21:45     1,854,406,656 Ubuntu642-0-000002-s010.vmdk

2020/05/21  21:45     4,392,550,400 Ubuntu642-0-000002-s011.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s001.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s002.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s003.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s004.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s005.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s006.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s007.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s008.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s009.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s010.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s011.vmdk

2020/05/21  21:48           524,288 Ubuntu642-s012.vmdk

2020/05/21  21:48           327,680 Ubuntu642-s013.vmdk

2020/05/21  15:12           158,955 vmware.log

2020/05/21  21:49    <DIR>          564d9485-c2c3-6e7f-ded1-6fd3ab5b5bed.vmem.lck

2020/05/21  21:49     8,589,934,592 564d9485-c2c3-6e7f-ded1-6fd3ab5b5bed.vmem

2020/05/21  21:49    <DIR>          Ubuntu642-0-000002.vmdk.lck

2020/05/21  21:49    <DIR>          Ubuntu642-0-000001.vmdk.lck

2020/05/21  21:49    <DIR>          Ubuntu642-0.vmdk.lck

2020/05/21  21:59             1,881 Ubuntu642-0-000002.vmdk

2020/05/21  21:59             3,873 Ubuntu642.vmx

2020/05/23  08:45                32 file.txt

           130 files 322,975,488,899 bytes

8 directories 394,901,323,776 available bytes

Do you think there is a problem?

(Note: I use VMware WorkStation 15.2)

[SUNVoyager]

Actually, I don't know how to shrink the disk space accurately, I just tried some methods.

Do you have a streamlined approach to shrink disk space?

[scott28tt]

Moderator: Thread moved to the regular Workstation Pro area, you are NOT using the Tech Preview version.

[a_p_]

As shown in the file listing, the VM has active snapshots for one of the virtual disks.

Looking at the .vmsd file's size, I assume that the Snapshot Manger doesn't list any snapshots!?

To delete the snapshots in such a case- i.e. merge the snapshot into the base disks - follow these steps:

1. shut down the VM (don't  suspend)
2. (optional) backup the VM's folder/files
3. open the Snapshot Manage, create a new snapshot, select that snapshot, and hit the Delete button

This should delete/consolidate all existing snapshots. Due to the snapshot's sizes it may take some time, so please remain patient.

Once all of the snapshots are gone (i.e. no more *-00000x-s0xx.vmdk files in the VM's folder) you should be able to shrink the VM.

André

[SUNVoyager]

Sir, what you said is correct.

According to what you said, I first created a new snapshot and then deleted it. Finally, the size of disk1 was reduced from 300G to 80G.

But disk2 doesn't seem to change much, even with the shrink method. I wonder if you have any other solutions?

Another question: When the virtual machine is powered on, it enters rescue mode, and there is grub boot in disk1, but when using the ls command to view each partition, unknown files are displayed. In this case, is there any possibility for the client to repair? Thank you.

[a_p_]

Another question: When the virtual machine is powered on, it enters rescue mode, and there is grub boot in disk1, but when using the ls command to view each partition, unknown files are displayed. In this case, is there any possibility for the client to repair?

This requires a detailed explanation, and some examples of what exactly you do, and see.

But disk2 doesn't seem to change much, even with the shrink method. I wonder if you have any other solutions?

Can yu confirm that there are no more ...-00000x-s0xx.vmdk file in the VM's folder anymore?

Since I don't know how the second disk is used within the OS - i.e. which file system, how mounted, ... - I can't tell you much. Maybe it's necessary to zero out the unused disk space on this disk/partition manually to get better results with the shrink operation.

André

[SUNVoyager]

(1)Enter rescue mode

Then enter the ls command to view the partitions (the following are the partitions)

hd0 (hd0, msdos0) (hd0, msdos5) hd1 (hd1, msdos1)

disk1 has two partitions: (hd0, msdos0) and (hd0, msdos5)

disk2 has a partition: (hd1, msdos1)

I know that grub boot is in (hd0, msdos0)

Then enter ls (hd0, msdos0) / ,the result shows: Unknown file system. The same is true for (hd0, msdos5).

The result of ls (hd1, msdos1) / returns that the file system is ext2, but not the location of the boot.

I have looked for some solutions: Boot-Repair-Disk can be used in a real ubuntu system, but how should it be repaired in a virtual machine? Is it possible to fix it?

(2)Also, what do you mean by Maybe it's necessary to zero out the unused disk space on this disk / partition manually to get better results with the shrink operation ? Thank you.