Shrink Linux vmware?

[B0ssk]

I know this has been asked before, but I haven't found a conclusive and working answer.

I have several Linux guests (Debian x64) servers which are thin provisioned on ESXi 5.1.

Some of these guests have an ext3 filesystem, others ext4. But all journaled filesystems.

One particular guest has 25GB of data (400GB thin provisioned), but used 148GB on disk. I would like this guest to used around 25GB again.

I've used dd to fill the rest of the partitions with /dev/zero data and removed those zero-files again. After that I shut down the server and used vmkfstools -K foo.vmdk to punch holes in the .vmdk.

After this I expected the guest to have shrunk to about 25GB, but it's back to 148GB again...

A similar procedure works with my Windows guests (using sdelete), but not on Linux. There isn't much info available, but most resources hint on something to do this journaling filesystems.

However, I don't quite understand what the trouble is with journaling filesystems. Can anyone explain it to me?

[B0ssk]

Anyone?

Using sdelete (windows) and dd if=/dev/zero is similar.

So if it works in windows and not in linux for .vmdk's implies that it has something to do with the filesystem.

So, any ideas what's so different about a journaling filesystem?

[Ethan44]

Hi

Welcome to the communities.

A journaling file system is a fault-resilient file system in which data integrity is ensured .

Which vary OS to OS .

"a journey of a thousand miles  starts with a single step.".

[B0ssk]

Thanks.

Can you explain why that results in not being able able to shrink (punch holes) in a vmdk?

And even better, do you know a solution? Perhaps clearing the journal (if that's possible)?

[MKguy]

When writing zeros with dd in the guest you inflated your VMDK to it's (nearly) total size, right?

I'm not sure how exactly journaling filesystems like ext3/4 arrange their journal on a disk, but maybe it's done in a way so that there were no continuous zeroed VMDK-blocks to reclaim, or your files are just very fragmented. I know I was able to successfully shrink thin VMDKs of GNU/Linux guests with ext3 filesystems a while back.

Some alternative ways you could try:

Use vmkfstools -i -d thin to clone the VMDK instead.

Another thing you can try is setting the following advanced parameters temporarily to 0 and then use Storage vMotion (or a cold migration) to move the the VM to another datastore:

vsish -e set /config/VMFS3/intOpts/EnableDataMovement 0

vsish -e set /config/DataMover/intOpts/HardwareAcceleratedInit 0
vsish -e set /config/DataMover/intOpts/HardwareAcceleratedMove 0

You could use VMware Converter with the disk resizing option to decrease  the total provisioned size of the VMDK in the long term, which should  shrink the actually thin provisioned allocated part too.

[cajunitalian]

I agree, using converter has often helped me out when I need to re-shrink server files.  We often do this with the SQL Server (once a year) that we have when the backups stored locally bloat out.  Just make sure you take a snapshot before converting!

[B0ssk]

Yes with dd it was inflated to max size. And after punching holes back to the original size :/

I've tried cloning with vmkfstools -d thin -i but it's still the same original size after that.

I think I may try the vmware converter approach next week. I've done that before (for other reasons) and am certain that it will shrink back to the smallest size.

I haven't tried it, but isn't taking a snapshot contraproductive? All changes will be in the snapshot, right?

What's the exact procedure you're following for shrinking your SQL server?