In vSphere, alarms are notifications that occur in response to certain events or conditions that occur with an object in vCenter Server. It is possible to create alarms for vCenter Server objects such as VMs, ESXi hosts, networks, and datastores. Based on the object, these alarms can monitor resource consumption or the state of the object and alert you when certain conditions have been met, such as high resource usage or low disk space. Alarms are very useful because they allow you to be more proactive in the administration of your vSphere environment. How to add a new partition to an existing Linux server, How to setup and configure a lamp stack, ESXI 6.7 ALARM: Seat disk exhaustion on 10, how to setup up WatchGuard Log and Report Server in a VM, how to encrypt a partition with Cryptsetup on Linux and how to disable RC4 Cipher Algorithms support in SSH Server.
Note: vCenter Server provides a list of default alarms, which monitor the operations of vSphere inventory objects. Each alarm type has three types of actions in common:
- Send a notification email: Informs you of the condition by email.
- Send a notification trap: Informs you of the condition by Simple Network Management Protocol (SNMP) trap.
- Run a command: Runs a script in order to correct the problem the object is experiencing.Few weeks ago, I upgraded ESXi hosts from 6.0 to 6.7 and everything went well. However, I observed this alarm on the Vcenter server a few days ago.
From checks online, I saw that this was a common error with esxi 6.7, where the disk size of a particular SEAT partition is almost exhausted and will be fixed in newer releases. Trying to log into Vcenter server again yesterday, I got the error below
This meant I could not log into Vcenter or access all servers and hosts. However, I could log in individually into the hosts. So, I decided to fix this.
There are two ways to fix this temporarily. However, the permanent fix will be in newer releases/patches from VMware. The first way to fix this is to increase the disk size of the partition, however, this will also fill up in no time. The second method is what I will be showing today.
Log in to the Virtual Center appliance as root
– Stop all services but postgres
service-control --stop –all
service-control --start vmware-vpostgres
Truncate DB (to run with the script file below
/opt/vmware/vpostgres/current/bin/psql -U postgres -v TaskMaxAgeInDays=0 -v EventMaxAgeInDays=0 -v StatMaxAgeInDays=0 -d VCDB -t -q -f /download-path/2110031_Postgres_task_event_stat.sql
(The script file will be downloaded on the VMware portal and imported to a directory on the server)
Run vacuum
/opt/vmware/vpostgres/current/bin/vacuumdb -U postgres -d VCDB –verbose
Then start all services
service-control --start –all
This should clear the SEAT partition and allow you back into the vCenter. You will then need to ensure that your vCenter is patched to the latest version, 6.7 U3C to permanently resolve this.
I hope you found this blog post helpful. If you have any questions, please let me know in the comment session.