Reclaim unused space on thin provisioned disk?

[Dragec]

Hi all.

I have ESXi host with 300GB space, and 5 Linux guests. All of them have been configured to use thin provisioned disk, and to use max 200GB.

First guest used about 100GB. So I tried to remove temp and some large files. Although I removed around 30GB from it, ESXi still shows that it is using 100GB.

A read on the forum that it isn't possible to reclaim this freed space without VMotion and moving this VM to another datastore.

Is this really true? Is there any tool or procedure to reclaim unused space without downtime?

[PaulSvirin]

And what about sdelete: http://communities.vmware.com/thread/226985

?

---

iSCSI SAN software

http://www.starwindsoftware.com

[Dragec]

As mentioned in original post, I have Linux guests. So I dont' think I can use sdelete.

[AWo]

Yes. You need SVmotion and to change the type from thick to thin.

AWo

VCP 3 & 4

Author @ vmwire.net

\[:o]===\[o:]

=Would you like to have this posting as a ringtone on your cell phone?=

=Send "Posting" to 911 for only $999999,99!=

[Dragec]

Disks are already thin provisioned.

So, I guess, only option is:

- To move VD temporarily to another datastore, using SVmotion choosing thin option and minimal size

- To move shrinked VD back to original datastore

Am i right?

[AWo]

Yes.

AWo

VCP 3 & 4

Author @ vmwire.net

\[:o]===\[o:]

=Would you like to have this posting as a ringtone on your cell phone?=

=Send "Posting" to 911 for only $999999,99!=

[candace]

I have a Linux VM with 2 virtual disks both using LVM. I have tried storage vMotioning to another LUN with thin provisioning but it is not freeing up any space. It should be freeing up over 100 GB. Is there an sdelete like function to run in Linux that is sometimes necessary?

[AWo]

If your virtual disk was thick provisioned before you can't shrink them. The manual says:

(Thick) This is the default virtual disk format. The thick virtual disk does not change its size and from the very beginning occupies the entire datastore space provisioned to it. Thick format does not zero out the blocks in the allocated space. It is not possible to convert the thick disk into thin.

I think it is natural that thick provisioned disk can't get shrinked.

AWo

VCP 3 & 4

Author @ vmwire.net

\[:o]===\[o:]

=Would you like to have this posting as a ringtone on your cell phone?=

=Send "Posting" to 911 for only $999999,99!=

[J1mbo]

Depeding on the distro, there is secure-delete (apt-get install secure-delete). the use sfill -fz.

Find a test system first!!

Then as said s-vmotion or cold datastore migration depending on your license. ESX will "drop" any sector that's just zeros hence the required space is reduced again.

HTH

EDIT - a couple of other options here.

Please award points to any useful answer.

[continuum]

what sdelete does on Windows can be done with dd on Linux

see

http://www.feyrer.de/g4u/#shrinkimg




___________________________________

VMX-parameters- Workstation FAQ -[ MOA-liveCD|http://sanbarrow.com/moa241.html] - VM-Sickbay

[candace]

Hi,

Thanks for the response. The two virtual disks are already thin provisioned. I confirmed this by looking into the properties of the VM. The virtual disk in question did at one stage use all the space but has had up to 80 GB removed in the OS. I'll have a look at the dd solution I see in this thread.

[scotty_p]

Is it still the case that you can't convert thick to thin and zero them out. We're running ESX 4.0. I have a VM that I've tried converting to thin. It is configured for 85GB, but only has about 38GB used. Is there anything I can do to reclaim the space? Thanks.

root@vpesx02 lpord02-thin# vmkfstools -i lpord02-thin.vmdk -d thin lpord02-thin2.vmdk

Destination disk format: VMFS thin-provisioned

Cloning disk 'lpord02-thin.vmdk'...

Clone: 100% done.

Then removed the disk from the VM and added the lpord02-thin2.vmdk disk.

Here is the results of du -h

root@vpesx02 lpord02-thin# du -h lpord02-thin2-flat.vmdk

85G lpord02-thin2-flat.vmdk

On the actual Linux VM you can see that all the space is not in use.

root@lpord02-thin ~# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda1 494M 269M 200M 58% /

/dev/sda5 76G 36G 37G 50% /usr

/dev/sda2 2.0G 644M 1.3G 35% /var

tmpfs 1.5G 0 1.5G 0% /dev/shm

[DSTAVERT]

VMware Standalone Converter is the best way to shrink the disk. Convert to a smaller disk which results in a file level copy to the new destination vmdk.

[seemayur]

Hey, sorry to revive an old thread, but if you are still looking for an answer to this...

on a Linux guest, you need to use DD of something similar to write Zero's on all of the deleted space on the VD. Then do a sVmotion and you can choose to convert to thin provisioned or use same format (since you are already thing provisioned).

This process will definetly work, but I caution you, if you are over allocated, when you run the DD (or sdelete on Windows), the disk space on the VD will get used up to it's maximum before all of the space is reclaimed.

if you have a situation, where one of your VM is only using 10GB of a 100GB VD, when you run the DD process, it will use up that 100GB. So, if you do not have 90GB free on the datastore, it will crash ..

Mayur

[jfield]

I am pretty sure I have found the solution to this one. It works for me, and makes some sense (it's a bug).

After using "sdelete -c C:", when you Storage vMotion the thin disk to another volume to reclaim the zeroed space, it must be to a volume with a different block size.

Simple as that. Works fine for me.

Jules.

[continuum]

>  After using "sdelete -c C:", when you Storage vMotion the thin disk  to another volume to reclaim the zeroed space, it must be to a volume  with a different block size.

makes no sense at all to me

[jfield]

On Linux, instead of "sdelete -c C:", do this:

     dd if=/dev/zero of=BIGFILE bs=1024000

     rm -f BIGFILE

Then do the Storage vMotion thing ( or "migrate datastore" if you prefer those terms ).

[continuum]

some posts earlier I posted a link that explains how to use dd - no need to explain that again.

Your talk about blocksize makes no sense to me.

Consider you have a vmdk  with nominal size of 1500 Gb - currently using 200 Gb on a 8Mb blocksize VMFS.
If you use sdelete or dd to wipe unused space and later move the vmdk to a VMFS with different blocksize it will either fail immediatly or at some time later

[jfield]

If your VMDK is 1500 Gb then it can only be handled by VMFS filesystems with 8Mb block size, so you can't migrate it to a VMFS with a different block size (8Mb is the largest allowed), so you're screwed.

The block size affects the limit on the maximum size of a file allowed on that filesystem/volume. 8Mb ==> max 2GB file, 4Mb ==> max 1TB file, 2Mb ==> max 512MB file, 1Mb ==> max 256GB file.

So no, with a 1500GB file, you can't do it. Sorry, you're screwed.

Your only option would be to take it off-line (power it down), and use VMware Converter to import it from itself again, slightly changing the max allowed disk size to force it to do a file-based copy of the VMDK. That will remove all the empty space from the image as it's a file by file copy of the VM, not a block by block copy that Storage vMotion does.

[continuum]

You do not need to explain this to me - I just complained about your post because in this context blocksize will be understood as the VMFS-blocksize while you obviously meant blocksize for the dd command.

So your post with "the solution" will be probably missunderstood