I found that especially when you migrate Windows vCenter servers to the VCSA you might end up with a deployment size that is less than optimal. Some people say; don’t worry, it’s just thin provisioned. But I’m an old-school guy and I like to keep things neat and simple. The specific use case I have is a former Windows vCenter that ended up as an X-Large VCSA. At the time of the migration no other size than X-Large was presented in the interface even though the data was nowhere near the threshold for an X-Large deployment. As you can see in the following directory listing the /storage/seat mount point is 1.4TB even though there is only 56GB in use.

And sure enough, when I did a dry run to upgrade this vCenter apparently all the provisioned space is taken into account. Because the upgrade process only allows me to select X-Large because 2.2TB of storage is needed. Even if the sum of all the data is only about 150GB.

Product improvement tip! – If any VMware employee ever gets to read this blog post. Maybe you can make future VCSA upgrades only look at used disk space instead of provisioned space. 😎

So I created a service request with VMware to see if there’s a way to reduce the deployment size during the upgrade. Unfortunately there was no documented procedure available. Even the guides and KB articles available on the internet only describe how to extend VCSA storage. So I decided to investigate if I could come up with a procedure of my own.

Turns out reducing disks – or volumes I should say – is actually very easy because the VCSA is using LVM. The required steps are:

  • Create a backup or snapshot before you begin the process
  • Stop the services: service-control --stop --all
  • Unmount the mount points you want to resize: umount /storage/seat/
  • Do a filesystem check: e2fsck -f /dev/mapper/seat_vg-seat
  • Resize the filesystem and make it a bit smaller than the size the volume will eventually become: resize2fs /dev/mapper/seat_vg-seat 9G
  • Set the logical volume to the desired size: lvreduce -L 10G /dev/seat_vg/seat
  • Now let the filesystem fill the rest of the logical volume: resize2fs /dev/mapper/seat_vg-seat
  • Mount the filesystem(s) you resized: mount /storage/seat/
  • And restart the services: service-control --start --all
  • Remove the snapshot if the procedure is successful.

On my test VCSA I resized the /storage/seat mount point and recorded the process using asciinema. There are a few extra steps I included for my environment to verify that a VCSA backup actually picks up on the resized mount point. But you can ignore those.

Also keep in mind that this procedure only resizes the mount points and logical volumes. This does not change the underlying disks themselves. But as this is intended a pre-upgrade procedure where you move everything over to a new appliance this is not an issue.

Share this if you found this interesting.

One Comment

  1. You are my hero!.
    I am so glad you posted your procedure, how to reduce the storage size.
    In my case I wanted to upgrade a tiny vcsa6.5 to 6.7 in my homelab. The initial proposal of this funny upgrade software was Medium, which wouldn’t have fit into my small, phsical home lab resources.
    Thanks to your guide I can keep all the configuration and can smoothly continue to work with a tiny vcsa v6.7

    Thanks again for this great post,
    Jurgen

    Avatar Jurgen Mutzberg

Leave a Reply

Your email address will not be published. Required fields are marked *