For troubleshooting purposes, users may need to access the ESXi Direct Console User Interface (DCUI), either remotely through an out-of-band system like an iDRAC or iLO, or directly from the physical server.
For auditing purposes, all login methods to ESXi (SSH, API, Host Client, and DCUI) are recorded, and a corresponding vSphere Event called UserLoginSessionEvent is generated for easy filtering.
Here is another tidbit on how you can leverage the power of vSphere Events, which now includes over 2K+ as of vSphere 8.0 Update 1 to help monitor when an ESXi filesystem and/or partition is low on disk space.
With vSphere 6.7 or later, we have two events that you can use to help alert when either an ESXi ramdisk (e.g. /var) or VFAT partition (e.g. bootbanks) has filled up.
When either of these occur, you can easily find them under the Monitor->Events section for an ESXi host as shown in the screenshot below.
When converging or importing a vCenter Server environment that does not already include NSX, VMware Cloud Foundation (VCF) will automatically deploy NSX as part of the converge or import workflow. While the deployed NSX version will be compatible with the existing environment, it may have implications for future VCF upgrade paths.
The current behavior in VCF 9.1.0 is to deploy the latest NSX version that is compatible with the source vCenter Server version. However, depending on when the converge or import workflow is performed, that NSX version could be a back-in-time release that does not have a direct upgrade path to the current version of VCF.
Below is an example to help illustrate the current behavior. Let us assume we are starting with a vCenter Server 8.0 Update 3c environment. As of this blog post, the Interoperability Matrix, which is the source used to determine component compatibility, shows NSX 4.2.4.1 as the latest compatible version.
