1

This question is similar to Best practices for thin-provisioning Linux servers (on VMware)

However my question is a touch different.

We have P2Ved quite a few servers (win/linux) and we needed to use the block level copy so we used Thin provisioning when migrating and we have set these servers in production assuming the Thin provisioning usage will be inline with the actual data used by servers but we are proved wrong as we see the VMDK's grow even though the actual disk usage within guest vms are low due to logs/backups /what not processes touching blocks and the VMDK can only grow and not shrink.

We do not want this to affect us at some night where the Datastore fills up entirely.

We looked at tools like sdelete / punching zeros however this needs us to remove all snapshots., which we cannot due to our backup system utilizing CBT . Also this does not work with Linux .

We also looked at suggestions where we should just V2V and create a new disk that is of a different size however this is bit too much of work considering the servers are already live .

Instead of making drastic changes to the setup, I was considering using windows/Linux disk tools to change the shrink the FS/Volumes inside the OS to a comfortable size so even if one VM uses all of its available space the Host will not run out of datastore space.

Example Numbers: Our Datastore : 1 TB. VM's Provisioned Usage : 2TB ( THIN ) VM's Actual Usage ( 100 GB )

Now if we use DiskMgmt tool in windows to shrink the basic volume to be about 200 GB and in Linux LVM to change LV / VG & partition to around 200G , this way VM has some headroom to grow but cannot grow too much.

My question is would this work i.e the vmdk growth will stop at the size of the OS disk part and would this become a sort of middle ground between thin/thick provision or would this not work and say the thin provisioned VMs VMDKs will still grow a lot beyond the partition /volume limit we set at the OS level?

One side question : what would happen if a datastore fills up would we be able to still use the Vsphere web client/etc or ssh to move some of the VMs to another datastore easily or is this is going to be a pure disaster?

3
  • Your question makes it sound like you've over provisioned your datastore and you're trying to "play games" with your virtual machine storage to avoid a problem of your datastore running out of space. None of this sounds like a sound and reasonable thing to me. Why don't you address the real issue, which is that your datastore isn't large enough?
    – joeqwerty
    Jul 8, 2016 at 20:27
  • Its not about the Datastore not being large enough, it is more than 2x the actual foot print but it is still smaller than the total of all thin provisioned disks. i.e 2.4T thin provisoned disk only holding 300G data for example
    – paimpozhil
    Jul 8, 2016 at 20:35
  • Even if I deal the problem somehow it is interesting to me to learn how the underlying storages allot blocks and to understand how it works.
    – paimpozhil
    Jul 8, 2016 at 20:35

1 Answer 1

0

To answer the question myself.

Shrinking the filesystem does fix the problem, ie the disk usage does not go beyond a certain limit however there is some gotcha's when the file system is shrinked the OS moves all the files / orders them according the diskmap on the begining of the partition, and this operation actually causes the Think provisioned VMDKs to grow to a considerable size upto 2x the actual size.

Personally We ended up V2Ving every server with over provision to manageable size and that was much easier / less time consuming than the Shrinking/playing with FS level.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .