That left me with diagnosing the actual problem. Once those completed, I restarted my vCenter services and everything came back up. So, after I grew the appropriate VMDK and extended the partition with the vpxd_servicecfg storage lvm autogrow command, I was able to finish the procedure in the first KB article by executing the truncate table vpx_event cascade and truncate table vpx_event_arg cascade database commands. but we know how to find vCenter when it's down (please forgive the shameless plug). Of course, in order to follow that procedure, I had to track down the VCSA VM so that I could modify its hardware. And, VMware has another fine KB article about how to grow a VCSA partition! Rather than deleting files to make free space, I could simply expand the VMDK to accomplish the same goal. I did a bit of research into how to free up some space on there, but the general feeling I got was 'don't delete any of those files!' and I wasn't feeling overly brave. So, I had to free up some disk space so that I could free up some disk space. I'll admit to chuckling when I saw the 'hint' line. When I tried to execute them, I got the following message: The problem that I ran into is that the truncate commands (that free up space) were failing to run because there wasn't enough space on the partition. Well, VMware has a fine KB Article about a full seat partition and how to solve it. I established an SSH session to the server and went through the basics, and what do you know, 'df -h' revealed that the /storage/seat partition was 100% full. The VM was still running and responding to pings, but the service wasn't working. One of my customers recently had one of their vCenter 6 Server Appliances go offline.

Log disk exhaustion vcenter