I have the following environment
- VMware ESXi 5.5 U3 free, with datastore using VAAI
- Linux VM
- CentOS 6.8, 2 thin provisioned disks (PVSCSI thin VMDK's)
- 1st disk has reference OS partitioning (partition for boot, then LVM with regular root/home/swap LV's)
- 1st disk is 100GB thin provisioned thin VMDK (about 12GB physical)
- 2nd disk is 2TB thin provisioned thin VMDK disk I added
- /opt folder is currently empty
- OS was recently installed, so no cruft
My intention is to use the second disk to host the /opt mountpoint, as I will be adding data that may need to be grown in the future.
The problem here is adding the second disk via the GUI LVM manager. LVM manager sees the disk fine. Adding the disk to the existing volume group or a new one seems to work fine. Adding a new logical volume without a file system seems to work without causing the underlying VMDK file to expand.
But, the moment I try to configure an ext4 filesystem and hit OK, the LVM manager GUI stops responding, and the underlying VMDK files starts to expand. By all appearances, it seems to be doing a full format of some kind, writing to the thin provisioned disk, causing it to inflate.
Is there a way to avoid causing the underlying VMDK file to increase in physical size when adding the LV? Is the expansion due to a full format, or because LVM is trying to squeeze the /opt LV into the middle of the filesystem, so it effectively is copying OS data to the end of the partition (which would imply that simply waiting, it would eventually finish without causing the disk to fully inflate)
update-1
Did some experiments, it seems for a 2TB thin provisioned VMDK, ext4 formatting is both slow, and caused approximately 32GB inflation. So at least not full inflation. With the VM stopped, a punchzero operation using vmkfstools recovered approximately 31GB and shrunk the VMDK, which if followed up with a VAAI UNMAP, will completely free up the 31GB from the backend datastore storage as well. Cleanup actions are IO/IOps intensive, so prepare for datastore pain. A lot of manual steps, but may be worth it if you have a throwaway datastore and are building VM templates.
A partial solution may be doing a sparse_super
formatting of the LVM LV, as that will cause ext4 to format on the fly as blocks are written, but that postpones the pain, and there is no way to do this from the LVM GUI.