This is post #10 in my December 2013 series about Linux Virtual Machine Performance Tuning. For more, please see the tag “Linux VM Performance Tuning.”
When we talked about the rationale behind storing logs centrally one big reason was thin-provisioned virtual disks. Those disks grow over time because filesystems on a virtual machine currently have no way to tell the underlying storage that they’re done using certain blocks on disk.
There is a way to make these VMs thin again, and I wrote about it as step 9 in my guide to preparing Linux Template VMs. In short, we run a script on the VM that writes zeroes to most of the free space on the VM:
#!/bin/sh
# Determine the version of RHEL
COND=`grep -i Taroon /etc/redhat-release`
if [ "$COND" = "" ]; then
export PREFIX="/usr/sbin"
else
export PREFIX="/sbin"
fi
FileSystem=`grep ext /etc/mtab| awk -F" " '{ print $2 }'`
for i in $FileSystem
do
echo $i
number=`df -B 512 $i | awk -F" " '{print $3}' | grep -v Used`
echo $number
percent=$(echo "scale=0; $number * 98 / 100" | bc )
echo $percent
dd count=`echo $percent` if=/dev/zero of=`echo $i`/zf
/bin/sync
sleep 15
rm -f $i/zf
done
VolumeGroup=`$PREFIX/vgdisplay | grep Name | awk -F" " '{ print $3 }'`
for j in $VolumeGroup
do
echo $j
$PREFIX/lvcreate -l `$PREFIX/vgdisplay $j | grep Free | awk -F" " '{ print $5 }'` -n zero $j
if [ -a /dev/$j/zero ]; then
cat /dev/zero > /dev/$j/zero
/bin/sync
sleep 15
$PREFIX/lvremove -f /dev/$j/zero
fi
done
This will balloon the VM out to it’s full allocation. Then, if you use Storage vMotion to move the VM between datastores on different arrays (or within the same array with VAAI off), and specify thin provisioning (instead of “same as source”) the datamover will extract all the zeroed out portions and make the VM thin again. And once you are done you can instruct VMware to use UNMAP commands to reclaim space on your array, if your array supports the VAAI UNMAP commands.
Another approach, if you have an array that deduplicates, is to make your VMs thick-provisioned instead, zero out their free space, and let the array do the rest of the work. This might be a better approach depending on your chargeback/showback strategy.
Either way there are considerations to make. Size of the fully-expanded VM may be an issue. Replication and backup might be an issue, perhaps needing temporary suspension. SAN traffic might be an issue, since VAAI cannot be used to re-thin the VMs. Heck, even chargeback might be an issue. If you are seeking the most fully-optimized, thinnest-provisioned disk, though, this is a way to do it.
Under Windows a similar effect can be had using the sdelete utility.
