Vmware Compress Vmdk File

0 views
Skip to first unread message

Terina

unread,
Aug 4, 2024, 9:04:20 PM8/4/24
to graphhydnimous
Ihave been looking for hours for a way to reduce the maximum size of this disk, so that it never gets to 150 GB (I'd like to set the limit to 30 GB, and see what happens when the VM reaches this size).

Defragment the disk via the guest, choosing a defragmentation mode that consolidatesempty space at the end of the disk. For a Windows guest, you should empty the Recycle Binand turn off hibernation and paging, returning them after the defragmentation is done.


Shrink the disk (which may take quite a long time to complete).

VMware Workstation : Menu VM / Manage / Clean up disks.

Or use : vmware-vdiskmanager.exe -k [VMDK PATH].

for ESX : vmkfstools --punchzero [VMDK PATH].


Because the OS and its application programs temporarily use lots of disk space for temporary files, page files, hibernate file and config files. Once they get deleted depending on the policy of the OS new sectors on disk are used at the next time. The VM allocate storage for the virtual disk from real disk whenever a new sector is used in the virtual disk. As the sector on virtual disk are always not reused by guest OS the VM thinks its a disk usage and give space from real disk and this will lead to growing virtual disk image.


Your question title is less likely to be solved as using such a tool without inspection of image may lead to total disaster. But you can prevent growing of the image beyond 30GB. There are many way to achieve the goal.


A. Use only 30GB partitioned and leave remaining as free space. If you already partitioned more space then you need to shrink/delete it, the create a new partition then dump it with zeros and punch it as described by @harrymc . As the space in unpartitioned area is never used virtual disk will never grow beyond 30GB.


B. Create a snapshot and restore to it after usage. After creating snapshot VM store data into a new image file. If you restore to it, without saving or making new snapshots, all changed data is deleted and thus space is freed.


C. Create a new virtual disk of maximum 30GB, add it as a new disk into your current virtual machine, move all data to the new virtual disk using a backup tool. You may use a live Linux for the cloning.


The answer of @harrym is pretty good, but it actually does not answer the question. The OP wants to reduce the maximum size.The problem is the hypervisor does not know how much of the presented size (aka maximum size) is indeed used by the OS. The compaction (vmware-vdiskmakager -k) applies to a growable vmdk. It does nothing on preallocated one's.


The first step involves a procedure from within the VM and varies with guest OS.The second step could be supported by the vmware commands but I haven't found a profound way of doing so. Thus the hacky approach.


As the hack works on single file preallocated (type 2) vmdks(haven't tried on multiple file types) we first convert the growableto preallocated. We will temporarily need a partition with physicalspace as the maximum size of the device. (e.g. 150GB).


Now replace that number with the noted number from step one and save the file. WARNING: A mistake here and you could end up trimming actual data used on the filesystem. (But we resized the fs on the beginning of the device and made correct and safe calculations right? )


You'll have to set the sum of all partitions to be less than 30GB. You'll have to shrink the sizes of the partitions down as you go. There is a LOT of documentation on this site on how to shrink partitions down so I will not repeat this here AGAIN.


In a Windows virtual machine, you must first run a disk defragmentfrom within Windows. Defragmenting within Windows ensures that all ofthe used spaces are contiguous. You can then reduce the size of thevirtual disk.


Note: In Workstation 9.x (Windows) and above, shrinking isautomatically done while Cleaning up the disk. Therefore, this optionis removed from VMware Tools Panel. Go to VM > Manage > Clean upDisks. This is not available in Linux version of VMware Workstation9.x and later.


Click the Shrink tab. Select the drive you want to shrink. ClickPrepare to Shrink, then follow the onscreen instructions. Caution: Donot shut down your virtual machine or the host machine while the diskis shrinking. Also, do not try to cancel the process. Interruptingthis process can cause irreparable damage to your virtual disk and youmay not be able to start your virtual machine again.


My 10.8.3 VM ended up using the entire 150GB VMDK space, even though the OS itself uses less than 10GB. Since VMware Workstation can't compress/reclaim space/cleanup HFS+ VMDKs, how would one get the space back without having to start over? I've tried adding an empty VMDK to the VM and cloning it using a number of different methods (Disk Utility, Carbon Copy Cloner, SuperDuper!, Terminal), yet none of them managed to get the new VMDK to boot properly.


Edit: note that it is not perfect, because there's some discarded space inside HFS metadata - like free inodes and such that are no longer used - but will not be zeroed with this. Not sure whether there's a tool for HFS to free unused metadata space.


I use Disk Utility to "Erase Free Space", select your virtual hard disk in DU select the Erase tab and click on the "Erase Free Space..." button I leave the default setting of "Fastest" and click on the "Erase Free Space" button and wait for the Erasing Free space to complete, it will take some time. Once complete shutdown the OS X VM, and edit Virtual Machine Settings, select the Hard Disk and select "Compact" from the "Utilities" pull down menu, a progress bar will appear to indicate the "Compacting virtual disk..." has started, again this will take some time, but at the end of the process the hard drive VMDK should have shrunk in size.


I remember using Erase Free Space when the VMDK was at around 55GB, and it ended up filling the entire thing... I probably had the wrong setting. I'll try that the next time it fills itself up, thanks.


Using WS11 and Yosemite, that command seems to do what it usually does, but after clicking on WS11's compact button for the VMDK, it instantly says that it's been finished while it doesn't actually do anything. Any ideas?


I have a worse problem which is that when I try to compact from vmware GUI, I get a popup with an error message "A required file was not found". I've searched the net for the popup, and it's mentioned but I couldn't find a solution.


You need to wipe the free space on the target filesystem to zeros. For Linux, can use a bash command like in post #2 above. It works for me with ext4. I don't know of Linux tools to wipe free space other than the bash method.


There are also commercial tools like Active KillDisk, Jetico BCWipe that do a better job of wiping filesystem metadata. The bash script only wipes free allocation blocks, but not metadata. In OS X there's the "Erase Free Space" which MSoK mentioned above (post #6) - I think it also wipes only free allocation blocks, not metadata.


Sorry I was mistakenly talking about something different. I actually was referring to the "Clean Up Disks" menu item, which I confused with the compact options. You can still use VMware tools from the command line to do much of this.


Not sure what "defragment" does. I use the contig tool from sysinternals, and after "defragment" it reports the vmdk still fragmented as a file. "defragment" refers to some vmdk internal fragmentation - and I don't know what's the benefit of it. After doing "compact" - doing "defragment" says it's already defragmented.


Yes, that's one of the main benefits of using the split disk vmdk files. Compress, cleanup, cloneiing, defragment operations on the vmdk file requires (internally) making a working copy of the file being operated on... if it's a 2GB split disk, then you only need slightly more than 2 GB of free space, as VMware works on each slice independently. If it's a monolithic (single file) disk, you need at least as much free space as the *maximum defined file size* of the VMDK - even if it isn't using that much!

3a8082e126
Reply all
Reply to author
Forward
0 new messages