Shrinking VMware Virtual Disks on a Mac

I have the unfortunate quirk that, when I think “VMware”, I often say it in my head with a German accent, like “WeeEmVare”. I find that makes things like “VMware Virtual Woes” fun and challenging to say. So it is with great enthusiasm that I recommend reading this post in the same manner.[1]

At Metric Insights, we currently deploy VMWare virtual machines to customers to try out our product. Recently, after having updated one of said VMs and preparing to upload the compressed file to our site, I realized with horror that the compressed file was 3.7G. This takes me over 5 hours to upload to our server, and I imagine an hour or so for our customers to download. Here’s how I shrunk it!

After a quick check, I realized that the virtual OS’s /tmp directory was unnecessarily full of an extra 3G that could be removed. So I deleted the contents of /tmp but was irked that the virtual disk didn’t shrink at all. It made sense, really, the journaled file systems (ext3 or ext4) on Linux don’t actually remove all the data on the hard drive after removing files, so unsuspecting college students can recover their accidentally deleted projects much easier.[2]

After a bit of searching I found the vmware-vdiskmanager utility. On VMWare Fusion installations, this lives at /Applications/VMware Fusion/Contents/Library/vmware-vdiskmanager and is described in detail here. Unfortunately, the documentation states vmware-vdiskmanager will only shrink disks on Windows. This of course, didn’t stop me from trying on the Mac.

I ran the utility with the shrink option (vmware-vdiskmanager -k path/to/my_virtual_disk.vmdk), and the virtual disk just smugly sat there at it’s original size. This was irksome, yet predictable. I refused to believe it wouldn’t work on a Mac, so I scoured the webs and found this amazingly helpful blog post with a humorous solution: just fill up the virtual disk completely!

So I logged into the the virtual machine as root and ran:

# dd if=/dev/zero of=/0bits bs=20971520
# rm /0bits
# shutdown -h now

When that was finished and the virtual machine shut down, I reran vmware-vdiskmanager:

cru@lappy:~/vms/MetricInsights-Centos-64-bit $ du -hs .
6.7G	.
cru@lappy:~/vms/MetricInsights-Centos-64-bit $ /Applications/VMware\ -k CentOS\ 6\ 64-bit.vmdk 
  Shrink: 100% done.
Shrink completed successfully.
cru@lappy:~/vms/MetricInsights-Centos-64-bit $ du -hs .
2.7G	.
cru@lappy:~/vms/MetricInsights-Centos-64-bit $ echo "yay!"

Now zipping up the app happens much faster and results in a much more manageable 800M!

cru@lappy:~/vms $ 7z a MetricInsights-Centos-64-bit
cru@lappy:~/vms $ ls -lh 
-rw-r--r--  1 cru  staff   868M Oct 25 13:00

This quick and dirty solution saved me tons of time and headache until we can get an OVF/OVA build/distribution system in place (blogs on that later!)

[1] If you’re one of the lucky readers out there who already has a German accent, you might find it a similarly entertaining exercise to use a US Southern accent. You’ll have an easier time saying VMware Virtual Woes, but might find it more difficult to say things like “Obama ’12!”. Sorry… couldn’t resist!

[2] Even in ext2 filesystems the inodes aren’t immediately removed from the disk. This fact saved my life in college after I was the dupe that accidentally deleted his final project the night before the deadline…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s