In my case ‘var/log’ was full, it being one of the smaller 10GB virtual disks.
The beauty of vCSA having 16 disks all in separate files is the ease with which you can grow one.
Get onto the console via virtual console or SSH, run a shell, then you can 'df -h' to confirm the full mount point, then use 'lsblk' to trace that back from it’s ‘Dev/wrapper’ mountpoint to an actual device like ‘Dev/sde’. E being the 5th letter of the alphabet correlates with it being a 10GB device here and also my disk 5 in the VM settings.
Now take a backup. Of course you're already doing nightly backups but then check that they're actually working, mine hadn't been for six weeks without my noticing due to an NFS permissions issue.
Gracefully shutdown vCSA taking note of which host it’s on. Connect to that host and edit settings for the vCSA, edit that virtual disk to increase its size, feel free to expand any other disks while you're there, it's not like most virtual storage isn't thin provisioned anyhow. I took the opportunity to increase my RAM and CPU count too as I’m not resource constrained and I figured 4 vCPUs and 24GB would make my vCenter snappier. Power back on and get a coffee while it boots/starts services.
If you get 'editing host resources is disabled because this host is managed by vCenter' you can workaround by SSHing to the host and restarting vpxa and hostd - this will kick you out of the GUI, but then once you have re-authenticated you can make changes.
Console or SSH in again, open a shell and run the ‘/usr/lib/applmgmt/support/scripts/autogrow.sh‘ script, it should find your extra space and grow both the partition and the file system.
Done.
No comments:
Post a Comment