ESXi - Shrink Physical VM Files

mda

2[H]4U
Joined
Mar 23, 2011
Messages
2,207
Hello all,

I'd like to seek your help in shrinking the data files consumed by one VM.

Back story:

Implementer partitions "large" 500GB VM for a system. Realistically, 150GB is enough space for the application copied twice over + the OS.

Implementer no longer wants to re-do this VM. They don't seem so proficient at ESXi, or RHEL anyway.

I want to reclaim the 350GB extra space so I can use this for smaller VMs and for future use for the larger ones. I only have 2TB (realistically, it's 1.6TB when you account for swap and formatting) of space so 350GB is big for me.

ESXi details
Version 6.5 U2, Lenovo Customized Image

Bloated Guest OS in Question
Red Hat 5.8 32 bit
Partitioned 'standard' (not LVM)
ext3

I can gparted the Guest OS to the point wherein the partitioned space only shows 150GB, with the 350GB as unallocated.

However, I no longer know what to do to have ESXi shrink the actual files/disks.

I have tried editing the VMDK file and editing the extent figures, unregistering the VM, moving the VM to another datastore.

When I do this, the VM 'thinks' it is now the smaller file, but the physical size of the vmdk-flat file still shows the larger value. The same large value shows up when monitoring the VMs, and doing an ls -lh on the ESXi CLI.

All the googles I've done don't really have a clear cut answer on this since the official answer is that this kind of move is is unsupported (?)

Is there any other way I can shrink this VM?

My experience level with ESXi - noob - I have setup a few and am using the cheapo 600$ version of ESXi (It's called the VSphere Essentials) without vmotion since I'm sitting on just one host so far.

Also, for future questions, is there any where like w3 schools where I can search this? The VMWare forums, while helpful, show a lot of very old topics and the commands of which are no longer relevant at this time.

I'm reading up about cloning the hard disk. I suppose this is actually possible... Clonezilla perhaps?

Thanks!
 
Last edited:
What have you tried so far?
Now I don't have access to a ESXi but in vmware workstation there is a Compact option and Defrag option (button). After you shrink the partition and make sure you wipe the unpartitioned space (or nullify it) you may try that if esxi has it, or try to migrate to workstation and then back to esxi. And always backup before any manipulation.
 
Storage vMotion it to a new datastore as thin provisioned. It won't matter how much you have provisioned, if you only have 150 GB allocated within the OS, it won't grow any larger than that.
 
Storage vMotion it to a new datastore as thin provisioned. It won't matter how much you have provisioned, if you only have 150 GB allocated within the OS, it won't grow any larger than that.
He already mentioned he's on the essentials version which lacks vmotion.
 
He already mentioned he's on the essentials version which lacks vmotion.

If you power it down, you should be able to move the storage with Essentials Plus. Or just unlicense it if you're within 60 days of install.

Or just clone it with a hardware change of making the disk 150 GB.
 
If you power it down, you should be able to move the storage with Essentials Plus. Or just unlicense it if you're within 60 days of install.

Or just clone it with a hardware change of making the disk 150 GB.
All technically true and legally grey :p
 
Thanks for the replies guys...

What have you tried so far?
Now I don't have access to a ESXi but in vmware workstation there is a Compact option and Defrag option (button). After you shrink the partition and make sure you wipe the unpartitioned space (or nullify it) you may try that if esxi has it, or try to migrate to workstation and then back to esxi. And always backup before any manipulation.

I've tried so far -
1. Shrinking the disk, using V2V - Results in an unusable VM - I could be doing this wrong, but I've also read online from the same non official sources that YMMV on this one and that it's a hit or miss.
2. De Partitioning the Drives, Moving them to a different datastore and re registering them again.
3. Doing "Punching holes" in the vmdk after doing what I did in #2, with the vmkfstools -K

Clonezilla might work. Whatever you use has to understand the guest OS.

You can't shrink a VM directly, however you could export the VM with a smaller size if it is thin provisioned and the space is not used.
Either that or clonezilla the partition itself is your best bet IMO.

This is for ESXI 5.X but the rules have stayed the same: https://pubs.vmware.com/vsphere-50/index.jsp?topic=/com.vmware.vmtools.install.doc/GUID-A42FA14C-7D67-44A7-823B-854AA9F5FD3E.html

Thanks for this... I think I'll try this first, as I have some experience with Clonezilla, mostly with our client Ubuntu workstations

Easiest thing to do is to just make a smaller disk and migrate data.

Most filesystems/etc don't support shrinking anyway.

Unfortunately, I'm not super sure on how to migrate the data reliably, since there are some apps installed in it. It's *Probably* not as simple as a copy / paste. I'm not too well versed in linux to know for sure what goes on under the hood after an install.


Storage vMotion it to a new datastore as thin provisioned. It won't matter how much you have provisioned, if you only have 150 GB allocated within the OS, it won't grow any larger than that.

All technically true and legally grey :p

If you power it down, you should be able to move the storage with Essentials Plus. Or just unlicense it if you're within 60 days of install.

Or just clone it with a hardware change of making the disk 150 GB.

I'll try this when I run out of options, especially since this will only be a one time thing. Thanks!


I've tried this already and the clone failed. Not sure what I'm doing wrong. I shall try redoing it. What's your success rate on this? Is there any technique or pointer aside from what's written?
 
Last edited:
What was the error when the clone failed? Use vmware converter?

I'll re-try this one soon, didn't get it the first time.

Re: Clonezilla, It's failing on me when cloning from a larger to a smaller disk.

I've done this before with ubuntu, also using ext3, but for some reason, it's not working this time even using the -icds and -k1 parameters.

I'm guessing it's probably because I'm trying to clone more than one partition as opposed to cloning just one partition before with ubuntu, and I'm missing a step. Just not so sure if it's in the saving partition (I just saved the partitions in one go), or in restoring it - just used advanced mode and icds/k1.

Willing to try other options in a bit, and sorry for the delayed response. Just takes time to do each clone/restore.

Thanks!

Edit: It seems I've been doing V2V conversion wrong.

I was originally:
1. copying the files via scp
2. converting the vm files
3. uploading it back

I tried now:
1. using the esxi server as both target and destination
2. picking the vm
3. deciding what the renamed vm is now.

The conversion / cloning is now a success, but still can't get the disk shrink to work.

On initial convert, the new VM shows the smaller size (in the options it shows the smaller size as well, say 40GB -> 30GB), but after booting and shutting down, the clone now shows the original, larger size. Gparted confirms this as I see a the remaining 10GB of unpartitioned space. What else should I be doing?

Should I be doing thinly provisioned instead of the standard default thick?

Edit3:

Tried modifying the extents - BEFORE powering up the VM after V2V.

doing a ls -lh still shows the old size of 40GB.

Looks like I need to modify extents AND thinly provision? Am I doing this right?

Either way, thanks for the help everyone!
 
Last edited:
Quick update.

It seems like this will work IF:

1. V2V from thick provisioned to thinly provisioned.
2. Modify extents before powering up the cloned VM
3. V2V from thinly provisioned to thick provisioned again.

I think I could actually stop after #2, but #3 confirms what I've done. Is there any shortcut to this? Bigger VMs take quite a bit of time to convert.

Sorry for the delays in replies. I'm from the other side of the world and don't have access to work on weekends. A new dev server coming soon (Ryzen Gen 3 where are you???) will change that.

I tried running ESXi 6.5 U2 on an old Quad Core 2.3 Kentsfield Xeon and it ran very slowly...
 
too many complicated responses in this thread.

Do it right. Rebuild the VM from scratch migrate over to it.
 
Thisk is best practice if you have VAAI, and sometimes you have ahole engineers that will overprovision the storage too much unless you do thick.

Is that actually still a thing with VAAI? I understand the part about having people that don't look at the underlying storage before provisioning disk and having to go back behind them and move stuff around.
 
Is that actually still a thing with VAAI? I understand the part about having people that don't look at the underlying storage before provisioning disk and having to go back behind them and move stuff around.
Thats ones of the biggest benefits with VAAI, while not substantial it does provide a little better performance/latency for the VM being thick provisioned (its usually best practice depending on the storage vendor).
Its the best of both worlds, the client thinks they get all the space, but its not actually using it from a storage admin perspective (I find this extremely useful for greedy qa/engineers).
When on local storage we'd have to argue all day with them and have to transfer it to convert it for them.
 
Thats ones of the biggest benefits with VAAI, while not substantial it does provide a little better performance/latency for the VM being thick provisioned (its usually best practice depending on the storage vendor).
Its the best of both worlds, the client thinks they get all the space, but its not actually using it from a storage admin perspective (I find this extremely useful for greedy qa/engineers).
When on local storage we'd have to argue all day with them and have to transfer it to convert it for them.

I've been using NAAI with NetApp AFF using NFS and thin provisioning since my vSphere 5.5/Horizon 5.3 VDI environment. Works great. I've yet to find a reason to use thick provisioning, currently on 6.5 and 7.6, need to upgrade to 7.8, probably do that next month.
 
Careful there while trying to shrink physical VM files. Something I can tell you for sure as this did happen to me before. It's quite easy for you to damage your VDMK files, it will be some trouble to restore them if that happens right? Well, lucky here. As I have tested before this method does work, see for yourself at https://www.diskinternals.com/vmfs-recovery/restore-a-vmdk-file/ You can restore both the .vmdk file and the -flat.vmdk file with this tool. Super handy and simple to pick up.
 
Thanks. What's the best way to back up?

Export the file via the browser? Veeam (not sure if the cheapest ESXi with the free Veeam would work)? Make a copy with the datastore browser (although AFAIK the vmdk-flat files aren't copied like this).
 
A good rule going forward that we use. OS gets a drive and application gets a drive. If there is excessive data store that gets a drive. That way if I need to modify drives I can modify the drive with the appopriate role. Then when I need to move or anything else I do so as needed. Another good rule depending in your storage array is to lazy zero thick provision. What that means is the user sees they get all the space. The Middleware reflects they get all the space but the storage grows the space up to the max you set so it isn't all consumed at one shot. This method is BAD for systems where you need the data in one place like a defragmented storage array. The only way to fix that is to storage migrate the VM.
 
Back
Top