My Ubuntu image VMware disk has grown to 5GB physical file size. It's a dynamically growing disk with the maximum capacity of 8GB. I cleaned some stuff inside Linux distro and now inside it occupies 3GB. Obviously the physical file size didn't shrink back automatically. Is there a way (if possible free of charge) to shrink this disk back to ~3GB?
I need this to fit the image on the DVD.
There are three steps:
Defragment (no need to un/remount anything)
sudo e4defrag /
Ignore any errors. Some files like symlinks and device files can't be defragmented.
Zero-fill all unused space so VMware knows it's indeed unused:
dd if=/dev/zero of=wipefile bs=1M; sync; /bin/rm wipefile
Run the shrink operation:
sudo vmware-toolbox-cmd disk shrinkonly
I've found the solution – you have to compact your hard drive:
Virtual Machine - Settings - General - Clean Up Virtual Machine
Note: "Shrinking" is often used interchangeably to refer to the process of reducing the size of a thin-type disk file. VMware uses the term "shrink" to refer to reducing the underlying size of the disk available to the guest, and "thinning" as the process most tend to use of recapturing unused space without altering the underlying available size.
Since ESXi does not support vmtools-based shrinking on Linux guests, the following steps must be used. See reference link below for more information.
(if possible) Stop all disk write-intensive applications and services as the following steps will momentarily fill the target volume
Defragment volume(s) on target VMDK and ignore any errors as symlinks/device files/etc. cannot be defragmented.
# USE sudo IF NECESSARY IN YOUR CONFIG!
e4defrag /
# or e4defrag /mnt/MOUNTVOLUME
dd if=/dev/zero of=/mnt/MOUNTVOLUME/zeroes bs=1M; sync; rm /mnt/MOUNTVOLUME/zeroes
Shut down & power off guest
SSH to the ESXi host and issue these commands:
# Check current vmdk allocation
du -h /vmfs/volumes/volumename/vmname/vmname.vmdk
# Shrink it
vmkfstools -K /vmfs/volumes/volumename/vmname/vmname.vmdk
# Check again to verify shrinkage
du -h /vmfs/volumes/volumename/vmname/vmname.vmdk
https://kb.vmware.com/s/article/1002019
Deletion of files in most file systems will not completely remove them; merely file tables will be altered. Use of freeware secure file deletion utilities are useful, such as Eraser or SDelete to zero out the space to 'zero' the free space on the volume, effectively clearing the free space of data. It is then, that the disk can be properly thinned. You can then use the vmkfstools -K command (ESXi/ESX 4.1 and later) to complete the block reclaim or use Storage vMotion to migrate the virtual machine to a datastore with different VMFS block size.
Open VMware Toolbox in the guest (as root) and shrink the disk. (Documentation)
If you don't have VMware Tools, you can shrink the disk manually in two steps. First, clear the free space on the virtual disk using a tool like zerofree. Zerofree is available in Ubuntu, but since it requires the guest OS filesystem to be mounted read-only you may want to run it off a live CD. Parted Magic reportedly includes zerofree.
After zeroing the free space, open Virtual Machine Settings and compact the virtual disk.
Use
sudo vmware-toolbox-cmd disk shrinkonly
from the command prompt in your Ubuntu guest.
(Tested on Ubuntu 14.04 LTS guest + Windows 10 Host + VMWare Workstation 12.1.1 )
VMWare harddisk resizing:
Expanding the dynamic virtual harddisk in VMWare is easy and does no longer require the command line tool vmware-vdiskmanager.exe located by default in C:\Program Files\VMware\VMware Workstation\ .
For resizing use the following command (Open a command prompt by pressing WIN+R and enter cmd):
"C:\Program Files\VMware\VMware Workstation\vmware-vdiskmanager.exe" -x NEWSIZE "diskname.vmdk"
Procedure:
The following steps are:
For a visual rundown of the steps and additional info, see here.
These steps worked perfectly for me:
1) Zero-fill unused space
cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill
2) Shrink disk with vmware toolbox
sudo vmware-toolbox-cmd disk shrink /
Tested on Ubuntu 16.04, VMware Workstation 12.1.0 Player, Windows 7 Host
Find the large file and delete them.
find / -type f -size +50M
Defragment (no need to un/remount anything). Ignore any errors. Some files like symlinks and device files can't be defragmented.
sudo e4defrag /
Zero-fill all unused space so VMware knows it's indeed unused:
dd if=/dev/zero of=wipefile bs=1M; sync; rm wipefile
Run the shrink operation: If 4 fails, proceed to 5.
sudo vmware-toolbox-cmd disk shrinkonly
Reboot the linux system with try option and edit the partition table with gparted. Shrink the root file system and delete & move swap partition near to root partition.
SSH to ESXi, and issue this command:
vmkfstools -K /vmfs/volumes/volumename/vmname/vmname.vmdk
We need to edit the *.vmdk file. After the letters RW, defines the size of the VMware virtual disk (VMDK)
*40 GB = 40 * 1024 * 1024 * 1024 / 512 = 83886080*
Migrate it to another datastore to reflect the new size.
If your VM uses sparse disks, your .vmdk files conceptually use only as much disk space on the host as the VM uses. However, the VM and the guest OS have different notions of what's "in use".
When an OS deletes a file, traditionally it does not do anything to the contents of the file. The filesystem instead marks whatever space the file used as available. This is what allows undeletion to work if the content hasn't been overwritten yet.
The OS knows that the space formerly used by the deleted file is no longer in being actively used, but the VM doesn't; there's still data there. The VM therefore (usually) can't automatically reclaim the space from deleted files1.
1 If an OS knows that it's using an SSD, when it deletes a file, it can send TRIM commands to the disk to tell the disk that that space is no longer used. I don't know whether VMware products take advantage of that yet, however.
There are two phases to shrinking a virtual disk:
Wiping fills the guest file system with a zero-filled file to overwrite leftover contents from previously deleted files. This can generate an out-of-space message in the guest, but that's normal and expected. This must be done by a process in the guest. Typically this is done by VMware Tools, but there are other programs that can do this.
Compacting removes the unused (wiped/zeroed) parts of the .vmdk file on the host. Doing this properly depends on the wiping step because that's how it identifies parts that don't need to be preserved. This step requires free disk space on the host because, to avoid data loss on failure, disk compaction will create new disk files. You will need at least as much free space on the host as the size of the largest .vmdk file. (It therefore is advantageous to use split disks, which need much less free space on the host than monolithic disks when shrinking, when defragmenting, or when consolidating snapshots.)
Note that you can't shrink .vmdk files if there are snapshots; the wiping stage will write only to the current delta disk, so there's no way for the compacting step to identify parts of base disks that should be considered unused.
Windows guests with VMware Workstation Pro have another, superior option: Clean Up Disks. Power off the VM and choose: VM > Manage > Clean Up Disks. This is much, much faster than using the traditional shrink approach because it directly examines the guest OS filesystem to identify used and unused parts of the disk and therefore does not need the wiping step. Additionally it works if the VM has snapshots. I don't remember offhand if it has the same requirements for free space on the host, but given how much faster it is, any free space requirements it has are likely to be much, much lower.
In my Workstation 16 Player the mentioned VMware toolbox is not available, but in the settings the disk can be compacted:
Defragment and also Compact the disk.Worked for me with Win10 guest with ntfs, not checked with linux guest.
