Wednesday, June 19, 2019

vCenter appliance 6.5 to 6.7U1 upgrade

Yesterday I performed an upgrade of a vCenter appliance to 6.7U1. All went well but there was one thing in the upgrade process that more or less surprised me. I got the following message:
The default partition '/' has only 4.1 GB of available space.
So the root partition had not enough space to have the backup of both the database and the historical data. You can give an alternative path with space to proceed.
When searching I found this article: "Export path provided does not have enough disk space" error upgrading to vCenter Server Appliance 6.0 (2113947) Which lets you make a new disk. I opted for looking on the vcsa to see if there was a alternative:

Filesystem                                Size  Used Avail Use% Mounted on
devtmpfs                                   16G     0   16G   0% /dev
tmpfs                                      16G   32K   16G   1% /dev/shm
tmpfs                                      16G  684K   16G   1% /run
tmpfs                                      16G     0   16G   0% /sys/fs/cgroup
/dev/sda3                                  11G  6.0G  4.1G  60% /
tmpfs                                      16G  1.4M   16G   1% /tmp
/dev/sda1                                 120M   35M   80M  30% /boot
/dev/mapper/log_vg-log                     25G  3.6G   20G  16% /storage/log
/dev/mapper/seat_vg-seat                   50G  8.5G   39G  19% /storage/seat
/dev/mapper/autodeploy_vg-autodeploy       25G   57M   24G   1% /storage/autodeploy
/dev/mapper/imagebuilder_vg-imagebuilder   25G   45M   24G   1% /storage/imagebuilder
/dev/mapper/dblog_vg-dblog                 25G  3.5G   20G  15% /storage/dblog
/dev/mapper/db_vg-db                       25G  907M   23G   4% /storage/db
/dev/mapper/core_vg-core                   50G   52M   47G   1% /storage/core
/dev/mapper/netdump_vg-netdump            9.8G   23M  9.2G   1% /storage/netdump

/dev/mapper/updatemgr_vg-updatemgr         99G  3.3G   91G   4% /storage/updatemgr

So, plenty of space on the update manager disk. And that is what I used:
/storage/updatemgr was filled in as path. This worked and while the export ran I monitorered the disk usage. When the export finished the status was this:

Filesystem                                Size  Used Avail Use% Mounted on
devtmpfs                                   16G     0   16G   0% /dev
tmpfs                                      16G   32K   16G   1% /dev/shm
tmpfs                                      16G  684K   16G   1% /run
tmpfs                                      16G     0   16G   0% /sys/fs/cgroup
/dev/sda3                                  11G  6.0G  4.1G  60% /
tmpfs                                      16G  139M   16G   1% /tmp
/dev/sda1                                 120M   35M   80M  30% /boot
/dev/mapper/log_vg-log                     25G  3.6G   20G  16% /storage/log
/dev/mapper/seat_vg-seat                   50G  8.5G   39G  19% /storage/seat
/dev/mapper/autodeploy_vg-autodeploy       25G   58M   24G   1% /storage/autodeploy
/dev/mapper/imagebuilder_vg-imagebuilder   25G   45M   24G   1% /storage/imagebuilder
/dev/mapper/dblog_vg-dblog                 25G  3.5G   20G  15% /storage/dblog
/dev/mapper/db_vg-db                       25G  907M   23G   4% /storage/db
/dev/mapper/core_vg-core                   50G   52M   47G   1% /storage/core
/dev/mapper/netdump_vg-netdump            9.8G   23M  9.2G   1% /storage/netdump

/dev/mapper/updatemgr_vg-updatemgr         99G  5.9G   88G   7% /storage/updatemgr

So, YMMV but this looks like a very simple alternative to adding a whole new disk.
If you have a very large vSphere environment, maybe a better solution is to add a disk before starting the upgrade procedure.


No comments:

Post a Comment