I encountered a Health Message for my VCSA 188.8.131.52200 Build Number 5326079.
This led me to Increasing the disk space for the VMware vCenter Server Appliance in vSphere 6.0 (2126276) | VMware KB
However, in the process, I noticed a more serious issue with /storage/log (/dev/mapper/log_vg-log). It was at 98% capacity.
According to the KB article and other reliable sources, I needed to increase VMDK5 to resolve the immediate issue with /storage/log. So, I right clicked the vCenter VM, selected “Edit Settings,” clicked “Manage other disks” (on the Virtual Hardware tab), and increased Hard disk 5 from 10GB to 15GB.
Here is the original configuration:
…and here is how it looked after modification (the sizes were grayed out at the time because vCenter was being backed up by a program that utilizes snapshots and you cannot alter disk size when snapshots are present). Anyway, you will see that Hard disk 5 went from 10 to 15 GB.:
Here is the SSH/Shell before and after:
The Wrong Trousers
Notice something unexpected? Apparently, for my implementation, Disk 5 correlates to /storage/db and NOT /storage/log. In fact, based on this result, it appears that Disk 6 is the one that needs to be grown. Again, that does NOT correlate to other documentation as Disk 6 is referenced as /storage/db in those places.
On a whim and a prayer, I repeated the process for Disk 6, hoping to grow the /storage/log VMDK. Disk 6 was initially 10GB. I changed it to 20GB. Annnnd, bingo:
I recently encountered an issue where an ESXi host upgrade caused it to lose it’s connection to an iSCSI datastore. I was finally able to get the iSCSI issue resolved, but then I had an issue where I needed to name the newly created connection the same as the previous. The “old” one was still listed as an “inactive” datastore. I couldn’t name it the same as the old one, but there was no option to delete the old datastore reference.
I finally figured out that I had to remove all VMs from inventory that were still dependent on the “old” datastore. As soon as I deleted those VMs from inventory, the “inactive” datastore was automatically removed. Then I could rename my new iSCSI datastore to match the one that the system marked inactive when the original issue happened during the upgrade.
ESXi patches, express patches, and updates can be obtained from: https://my.vmware.com/group/vmware/patch
Understanding the difference between an ESXi patch, express patch, and update:
- An update is a service pack with many fixes included.
- An express patch is a small service pack with a few dozen updates.
- A patch is a single update.
So, essentially, there is nothing significantly different between the three.
Review the following blog entry to understand the cumulative capabilities of the update files: https://blogs.vmware.com/vsphere/2013/10/are-esxi-patches-cumulative.html
In short, every ESXi update/express patch/patch is cumulative as long as you apply it as such. To achieve this when patching from the command line, use the “esxcli software vib update -d <patch archive>” command, where <patch archive> is the path to the ESXi file that you downloaded from my.vmware.com and then uploaded to your ESXi server’s datastore.
I found this blog entry today and hope that I will never have to use something like Eassos Partition Manager to (try to) recover a corrupt VM.