5V0-2121 HCI Master Specialist Practice Questions

In a 2-node ROBO cluster, if one host becomes isolated from the network (and therefore from the other host and the witness), it loses quorum. The remaining host, which can still communicate with the witness, forms a majority and takes ownership of the vSAN objects. vSphere HA will detect the failure of the VMs on the isolated host and restart them on the active, non-isolated host, ensuring service continuity.

vSAN Deduplication and Compression occurs as data is destaged from the write buffer (cache tier) to the capacity tier. It is not an inline process that happens upon initial write. Therefore, data must first land in the write buffer and then be moved to the capacity tier for space-saving techniques to be applied. Furthermore, deduplication happens only within a single disk group, not across the cluster.

Before any upgrade, it is critical to run a vSAN Health Check to ensure the cluster is in a healthy, stable state. Attempting to upgrade an unhealthy cluster can lead to failures or data unavailability.

The desired ESXi version, drivers, and firmware defined in the vLCM image must be compatible with the underlying server hardware, including I/O controllers. Checking the VCG is a mandatory step to prevent unsupported configurations.

After defining the desired image and performing pre-checks, the core action is to remediate the cluster. vLCM will then orchestrate the entire process, putting hosts into maintenance mode, applying the updates, and bringing them back online in a rolling fashion.

The vSphere Client provides a streamlined workflow for replacing a failed disk. From the Cluster > Configure > vSAN > Disk Management view, the failed disk will be clearly marked. Selecting this disk will present the option to replace it. The administrator can then select the newly installed, available disk from a list to take its place in the disk group. vSAN will handle the formatting and partitioning.

In a vSAN stretched cluster, when the inter-site link fails but both sites can still communicate with the witness, a decision must be made to keep one site active to prevent a split-brain scenario. The witness, along with the hosts on the preferred site, will form a quorum (majority). The preferred site will remain online and continue running VMs. The non-preferred site will lose the election, its hosts will lose access to the vSAN datastore, and its VMs will be restarted by vSphere HA on the preferred site.

For optimal vSAN performance, especially with high-performance NVMe devices, the storage controller should be in pass-through (HBA/IT) mode. This allows vSAN to have direct control over the physical devices, minimizing controller overhead and latency. Using RAID mode introduces an unnecessary layer of abstraction and potential bottleneck. Enabling the controller's cache can interfere with vSAN's caching mechanisms and is not recommended. A high queue depth is beneficial but is a characteristic of a suitable controller, not a configuration mode in itself; pass-through mode is the foundational requirement.

The 'Ensure accessibility' option does not move all data from the host entering maintenance mode. It only resynchronizes components if an object would become non-compliant (e.g., losing its last replica). For a standard FTT=1, RAID-1 object, components are on different hosts. When the first host enters maintenance, the object is still accessible via its other replica. However, when the second host fails, the object loses its remaining data component and its witness component, resulting in a loss of quorum (less than 50% of components available). This renders the object inaccessible until one of the hosts comes back online.

The key indicator here is the very low ReadCacheHitRate of 15%. This means that 85% of read requests are missing the cache and must be fetched from the slower capacity tier (magnetic disks in a hybrid cluster), which explains the higher ReadLatency (3.5ms). A healthy read cache hit rate is typically 90% or higher. The WriteBufferFree% is high (95%), and WriteLatency is low (0.8ms), indicating that writes are not the problem. The issue is a cache miss on reads, pointing to an undersized read cache for the working set of the VMs.

HCI Mesh requires that both the client cluster (consuming storage) and the server cluster (providing storage) are managed by the same vCenter Server. This allows vCenter to facilitate the mounting of the remote datastore.

HCI Mesh traffic flows directly between the ESXi hosts over their vSAN VMkernel ports. Therefore, L3 routable network connectivity is required between the vSAN networks of the client and server clusters.

This is true. The communication path for a stretched cluster is between the vSAN VMkernel ports on the data nodes and the Witness Host. However, if a separate Witness traffic VMkernel port is configured on the data hosts (a best practice to separate witness traffic), it is this port that must communicate with the vSAN traffic VMkernel port on the Witness Host. The Witness Host itself does not require a dedicated Witness traffic VMkernel port; it uses its vSAN traffic port for this communication.