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.
root@vcsa02 [ ~ ]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 24G 0 24G 0% /dev
tmpfs 24G 20K 24G 1% /dev/shm
tmpfs 24G 676K 24G 1% /run
tmpfs 24G 0 24G 0% /sys/fs/cgroup
/dev/sda3 11G 6.0G 4.1G 60% /
tmpfs 24G 948K 24G 1% /tmp
/dev/sda1 120M 28M 87M 24% /boot
/dev/mapper/updatemgr_vg-updatemgr 99G 1.5G 92G 2% /storage/updatemgr
/dev/mapper/autodeploy_vg-autodeploy 25G 69M 24G 1% /storage/autodeploy
/dev/mapper/log_vg-log 148G 43G 99G 31% /storage/log
/dev/mapper/dblog_vg-dblog 25G 9.7G 14G 42% /storage/dblog
/dev/mapper/imagebuilder_vg-imagebuilder 25G 45M 24G 1% /storage/imagebuilder
/dev/mapper/netdump_vg-netdump 9.8G 23M 9.2G 1% /storage/netdump
/dev/mapper/core_vg-core 99G 60M 94G 1% /storage/core
/dev/mapper/db_vg-db 296G 19G 265G 7% /storage/db
/dev/mapper/seat_vg-seat 1.4T 56G 1.3T 5% /storage/seat
tmpfs 1.0M 0 1.0M 0% /var/spool/snmp
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.
11 Comments
Jurgen Mutzberg · October 9, 2019 at 7:53 pm
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
fsck · February 5, 2020 at 10:11 pm
Thank you! I ended up with storage/seat 1,4 TB as you and now I decreased it followed your guide….Big thanks!!
Ivan · March 30, 2020 at 1:21 pm
We had 525GB seat and I did our upgrade using CLI where you can select standard disk size. This your guide was my backup solution, thanks for it. I have pointed our vmware TAM to this.
Rob · July 3, 2020 at 5:27 am
After watching a video on how to backup and restore vCenter server using it’s inbuilt service. It mentions that the restored version has to be of the same size or bigger as the original server
Do you think if i made the changes you detailed above, then made a backup, then did a restore it would have the same desired affect of reducing the volume sizes?
https://www.youtube.com/watch?v=r05k2AeQgcU
Bryan van Eeden · July 13, 2020 at 5:53 pm
Well I do believe we tested this, and the result was not satisfactory… But as things change with updates, it might work this time around.
Juho Syrjänen · October 12, 2020 at 9:42 am
Thanks, this is a good summary on how to tackle this annoying issue. 🙂
Stuart Adams · February 5, 2021 at 12:48 pm
I’ve done this an everything was successful but the size of the disk hasn’t reduced in vSphere, it shows the reduced size when running the command -df -h but not in vSphere or Veeam?
Stuart Adams · February 5, 2021 at 1:54 pm
I reread it, thanks!
Bill · March 5, 2021 at 2:17 pm
Thank you!! Very helpful. I had to shrink the underlying disk using CLI commands I found on another site and adding a new smaller disk. I tried with Standalone Converter, but it couldn’t connect to my live vCSA. So I had to do things “the hard way.” as I wasn’t upgrading but doing this in-place. Thanks again!
Mario · July 23, 2021 at 7:29 pm
Thank you! I really appreciate it. We had the issue after the previous upgrade from 6.5 to 6.7 the /SEAT partition was ballooned to 1.4 TB! Nobody, including the VMware support, had a reasonable way to fix it. We lived with it until upgrade to 7! When we run the installer, we have only one choice, X-Large size!!! With needed space of over 3TB…Your procedure helped us to bring the vCenter7 installation to what was appropriate to our organization.
Resizing VCSA seat volume | NizMoTek IT Solutions · April 23, 2020 at 1:49 pm
[…] How to shrink VCSA logical volumes before an upgrade ← Previous Post […]