Troubleshooting practice questions

4 GHz (based on share ratio)

Why it fails: Shares determine relative entitlement only during contention, not an absolute guaranteed figure, so 4 GHz is not guaranteed. Deriving a value from the 2000:1000:500 ratio is tempting, but the reservation of 2 GHz is the actual guaranteed minimum.

8 GHz (all host CPU)

Why it fails: A reservation guarantees only the configured 2 GHz; shares govern contention beyond reservations, so the VM cannot be guaranteed the entire 8 GHz host capacity. Claiming all host CPU is tempting when the VM holds the largest share count, but shares never promise total host resources.

0 GHz (no guarantee without reservation)

Why it fails: The VM's explicit 2 GHz reservation guarantees that amount regardless of shares, so zero is wrong. Assuming no reservation exists is tempting because shares alone provide no minimum, but here a reservation is configured, making 2 GHz the guaranteed floor.

Increase the CPU shares for the VM.

Why it fails: Shares only determine relative entitlement during CPU contention between VMs; they do not reduce ready time when the host has free cores. Raising shares is correct when a competing VM starves this one, but the stem shows no such contention.

Increase the number of vCPUs to 8 to improve parallelism.

Why it fails: Adding vCPUs increases the co-scheduling demand placed on the host, raising %RDY further. Extra vCPUs suit genuinely parallel workloads that are CPU-bound but not contended; here the host already has spare physical cores, so the wait reflects scheduling, not insufficient parallelism.

Increase the memory allocation to 32 GB.

Why it fails: %RDY measures CPU scheduler wait, so adding memory leaves the contention untouched. Memory sizing addresses ballooning, swapping or overcommitment, and would be the correct action when esxtop shows high swap or memory pressure rather than elevated ready time.

The VM's virtual disks are experiencing high latency.

Why it fails: %RDY measures CPU ready time — the interval a vCPU spends waiting for a physical core — so it reports nothing about storage latency. Disk latency appears in esxtop's DAVG/cmd or KAVG counters. It is tempting because storage delay also causes intermittent VM sluggishness, but the metric cited here is purely a CPU scheduler statistic.

The VM is experiencing memory ballooning.

Why it fails: Memory ballooning is a memory-reclamation mechanism, tracked via esxtop's MCTLSZ or SWCUR counters, not %RDY, which is a CPU scheduler metric. It is tempting because ballooning also degrades VM performance intermittently, but the administrator observed CPU ready time, so memory pressure is not what this reading indicates.

The VM is using its CPU resources efficiently.

Why it fails: High %RDY indicates waiting, not efficiency.

The host must be taken out of maintenance mode for the remediation to proceed.

Why it fails: Maintenance mode is required for vLCM remediation, so exiting it would not resolve a firmware incompatibility and would instead block remediation. It is tempting because maintenance mode is a real prerequisite, but the error names firmware version, not host state, as the failing condition.

The ESXi 8.0 image has deprecated certain drivers that are still in use.

Why it fails: Deprecated drivers produce driver or device compatibility warnings, not the firmware-version mismatch vLCM reported, so this misreads the error's axis. Driver deprecation is tempting because it genuinely blocks ESXi 8.0 remediation, but only when the image omits a driver the host's hardware requires.

The vLCM image is corrupted and needs to be re-imported.

Why it fails: A corrupted vLCM image typically fails validation or import, not with a specific firmware-version incompatibility message naming the host. Re-importing is tempting because image corruption does cause remediation failures, but the error's explicit firmware reference points to the host's firmware level, not the depot.

LLDP on the VDS.

Why it fails: LLDP advertises neighbour and VLAN information between switches and hosts; it carries no packet payload, so no frames from the VM can be inspected. Packet capture requires a port mirroring session, which is what the scenario demands.

NetFlow on the VDS.

Why it fails: NetFlow exports summary metadata about flows — addresses, ports, byte counts — not packet contents, so payload-level troubleshooting is impossible. Full frame capture needs a mirrored session; NetFlow suits traffic profiling and capacity analysis instead.

Traffic shaping on the VDS.

Why it fails: Traffic shaping meters and limits throughput on a port group; it does not duplicate frames to a capture target. It suits bandwidth policing for noisy neighbours, whereas port mirroring (a distributed port group or session) is the feature that copies a VM's traffic for analysis.

Enable Storage I/O Control on the datastore.

Why it fails: Storage I/O Control throttles and prioritises datastore I/O during contention; it does not increase the 1GbE link capacity that is saturated, so latency persists. It is tempting because SIOC addresses noisy-neighbour latency, and it would be correct when multiple VMs contend for a datastore that still has spare bandwidth.

Convert the datastore from NFS to VMFS.

Why it fails: VMFS is block storage, so converting replaces the NFS transport rather than adding bandwidth; the 1GbE link remains the constraint and the migration itself is disruptive. It is tempting because VMFS suits block workloads, and it would be correct when NFS-specific protocol overhead, not link saturation, causes the latency.

Increase the memory reservation for the VM.

Why it fails: Memory reservation governs RAM allocation and swap behaviour, not the network throughput carrying NFS traffic, so it cannot relieve the 1GbE saturation causing latency. It is tempting because reservations help memory-constrained VMs, and it would be correct where ballooning or swapping, not storage transport, is the bottleneck.

Create one distributed port group with VLAN 100, and use VLAN tagging on the VMs for management and vMotion.

Why it fails: Tagging inside guest VMs leaves the management and vMotion traffic sharing the production port group's broadcast domain, so isolation is not achieved. Guest tagging suits environments where a single uplink must carry many VLANs to external switches, not host-level traffic separation.

Use standard switches for management and vMotion to avoid complexity.

Why it fails: Standard switches cannot be centrally managed across the cluster, so per-host VLAN configuration must be replicated manually and the distributed switch's requirements go unmet. They suit single-host or small environments where centralised management and consistent policy across many hosts are not required.

Create one distributed port group with VLAN trunk (4095) and use port-based VLAN filtering on the VMs.

Why it fails: A single trunk port group with port-based VLAN filtering pushes VLAN separation onto guest OS tagging, so management and production traffic share one uplink and isolation is not enforced at the virtual switch. Trunking suits physical appliances or nested virtualisation needing many VLANs.

Create two port groups: one for production (VLAN 100) and one for management+vMotion (VLAN 200) because vMotion can share VLAN with management.

Why it fails: Incorrect: Management and vMotion should be on separate VLANs to avoid resource contention and security risks; sharing a VLAN is not a recommended best practice.

The vCenter Server's account lockout policy has been triggered.

Why it fails: Account lockout governs authentication attempts, not certificate trust; it cannot corrupt or invalidate an ESXi host certificate. It is tempting because lockouts do block host additions, but only after repeated credential failures, producing a distinct authentication error rather than a tampered-certificate warning.

The ESXi host's SSH keys have been rotated.

Why it fails: Rotating SSH keys affects remote shell authentication only and leaves the TLS certificate presented to vCenter untouched. Key rotation is the correct action when SSH access fails after a security hardening cycle, not when certificate validation fails.

The ESXi host's certificate has expired.

Why it fails: An expired certificate produces a distinct expiry or validity-period error, not a tampering or invalid-signature message. Expiry is tempting because certificate problems commonly cause host-add failures, but vCenter reports tampering when the certificate's signature or thumbprint does not match the expected CA-issued value.

Enable VLAN tagging on the physical switch port

Why it fails: The physical switch port already trunks VLAN 100, so enabling tagging there changes nothing. It tempts administrators who assume the uplink is untagged, but the mismatch lies on the ESXi side: the port group's VLAN ID must match the trunk's native or allowed configuration.

Change the VLAN ID to 0

Why it fails: Setting the port group VLAN ID to 0 marks traffic as untagged, so frames leave the host without a VLAN 100 tag and the trunk drops them. It tempts anyone treating 0 as a default, but 0 means no tagging, not VLAN 100.

Add a second physical NIC to the standard switch

Why it fails: A second physical NIC adds no path to the gateway when the existing uplink already shows link up; the fault is VLAN tagging, since the port group must carry VLAN ID 100 through the trunk. A second NIC suits redundancy or separate traffic flows, not a single-VM connectivity fault.

Disk Kernel Latency

Why it fails: Disk Kernel Latency measures storage stack response, not vCPU scheduling delay. It is tempting because latency metrics often indicate contention generally, and it would be the correct choice when diagnosing datastore or VMFS performance problems rather than CPU ready time.

Memory Swap In Rate

Why it fails: Swap in rate indicates memory pressure and ballooning, not vCPU scheduling contention. It is tempting because swapping degrades performance broadly, and it would be the correct metric when diagnosing ESXi host memory overcommitment rather than CPU ready time.

Network Packet Drop Rate

Why it fails: Packet drop rate reflects network congestion or NIC saturation, not the time vCPUs spend waiting for physical cores. It is tempting because drops signal resource contention, and it would be correct when troubleshooting vMotion, vSAN or uplink throughput issues instead of CPU ready.

Increase memory resource allocation for management VMs

Why it fails: Memory allocation for management VMs is a capacity and performance tuning decision, not a security control; it neither restricts access nor reduces exposed services on the host. Hardening concerns disabling unnecessary services, locking down DCUI and SSH, and enforcing strict permissions. Extra memory would be relevant when management appliances are resource-starved.

Enable SNMP v3

Why it fails: SNMP v3 adds authentication and encryption for monitoring traffic, but it is an observability protocol, not a hardening control for the hypervisor itself. The hardening guidance targets disabling unused services and restricting access; enabling an agent expands the attack surface. SNMP v3 would be chosen where encrypted monitoring polling is genuinely required.

Reset the vLCM image.

Why it fails: Resetting the vLCM image alters the desired-state configuration rather than investigating the network error, potentially widening the fault. It is tempting because image resets resolve corrupted desired-state definitions, and would be correct when remediation fails due to an invalid or inconsistent image specification.

Restart the vLCM service.

Why it fails: Restarting the vLCM service assumes the fault lies in the service itself, yet the error explicitly indicates a network failure, so connectivity must be checked first. It is tempting because service restarts fix stuck vLCM tasks, and would be correct if the service were unresponsive rather than reporting network errors.

Reboot the host.

Why it fails: Rebooting the host discards diagnostic state and does not address the reported network error, delaying identification of the actual connectivity fault. It is tempting because reboots clear many transient ESXi issues, and would be reasonable once logs confirm a hung management agent rather than a network problem.

Remove the host from the cluster and re-add it after a clean installation.

Why it fails: Removing and re-adding the host is too drastic and does not address the hardware compatibility plug-in issue.

Use the vSphere Client to export the host's hardware compatibility report.

Why it fails: Exporting a report does not fix the issue; it only provides information.

Manually add the host's hardware to the vCenter server's HCL database.

Why it fails: You cannot manually add hardware to the HCL database.

The vDS is not configured with a VLAN trunking policy.

Why it fails: VLAN trunking governs how multiple VLANs traverse uplinks; the port group already carries the correct VLAN ID, so trunking is irrelevant. Trunking would be the right answer if VMs on several VLANs needed to cross a single physical uplink to other hosts.

The VM's network adapter is configured with the wrong MAC address.

Why it fails: A wrong MAC address would break all communication, including with VMs on the same host, yet those work. MAC configuration matters when resolving duplicate address or static assignment faults, but the pattern here — same-host success, cross-host failure — indicates the uplink path.

The distributed port group has forging transmits set to reject.

Why it fails: Forging transmits blocks frames whose source MAC differs from the port's assigned MAC; it does not stop same-VLAN delivery across hosts. It is the correct control when preventing MAC spoofing, but here the symptom points to the vDS uplink or teaming configuration.

Unmount and delete the VMFS datastore, then recreate it and restore from backup.

Why it fails: Unmounting and deleting the datastore is a drastic action that would result in data loss. It should only be considered if the datastore is irrecoverably corrupted. The administrator should first attempt to restore access through less destructive means, such as checking for APD/PDL and re-establishing paths. Deleting the datastore is a last resort.

Rescan the storage adapter to discover the LUN and restore access.

Why it fails: A rescan may be necessary, but if the LUN is already presented and the datastore is still inaccessible, the issue is likely due to stale paths or an APD condition. A rescan alone may not resolve the problem if the host has lost its reservation or if there are permanent device loss (PDL) conditions. The administrator should first check for APD/PDL and then take appropriate action.

Check the VMFS metadata and run vmfsanalyzer to determine if the datastore is corrupt.

Why it fails: Running vmfsanalyzer is a diagnostic step, but it is not the first action. The datastore may be inaccessible due to an all paths down (APD) or permanent device loss (PDL) condition, not corruption. The administrator should first verify path status and attempt to restore connectivity before analyzing metadata.

Increase the CPU shares for all VMs to high priority.

Why it fails: CPU shares determine relative priority during contention, but setting all VMs to high shares makes them equal, so no VM gains an advantage. Shares do not reduce overall contention or ready time; they only affect distribution when there is competition. This action does not address the root cause of high ready time, which is excessive vCPU allocation relative to physical cores.

Enable CPU affinity for all VMs to pin them to specific physical cores.

Why it fails: CPU affinity can reduce scheduling flexibility and may cause imbalances, leading to higher ready time for VMs that cannot run on busy cores. While affinity can be useful for niche cases, it is not a general solution for reducing CPU ready time in an overcommitted cluster. It often exacerbates the problem by preventing the scheduler from efficiently distributing load across all cores.

Disable hyperthreading on all hosts to ensure each vCPU maps to a physical core.

Why it fails: Disabling hyperthreading reduces the number of logical processors, which decreases scheduling capacity and likely increases CPU ready time. Hyperthreading allows the scheduler to use logical cores for additional parallelism, and while it can introduce some contention, it generally improves throughput for many workloads. Disabling it is counterproductive in an overcommitted environment.

The physical CPU cores are running below their rated clock speed, so each vCPU takes longer to execute.

Why it fails: Reduced clock speed would increase the time each vCPU actually runs, but ready time specifically measures waiting before execution, not execution duration. The scenario states vCPUs exceed physical cores, which is the textbook cause of scheduling delay. Clock throttling does not explain the run-queue wait.

The VM's memory reservation is too low, causing the vCPU to stall while pages are faulted from disk.

Why it fails: Low memory reservation can trigger ballooning or swapping, which would show up as memory-related metrics such as MEMCTL or SWAP, not as CPU ready time. Memory stalls and CPU scheduling delays are distinct conditions. This option confuses memory pressure with CPU contention.

The guest operating system is running too many background services, which inflates the ready time reported by esxtop.

Why it fails: Ready time is measured by the hypervisor as the interval between when a vCPU is ready to execute and when it is actually scheduled on a physical core. Guest background services increase CPU usage but do not directly create ready time unless the host lacks capacity. This option misplaces the cause inside the guest.

GAVG (guest average latency) in the virtual machine view of esxtop

Why it fails: GAVG is the sum of KAVG and DAVG, representing the total latency experienced by the guest operating system. While it is an important end-to-end metric, it includes both host and array components. Using GAVG alone would not distinguish whether the array or the host stack is responsible for the latency.

QAVG (queue average latency) in the virtual machine view of esxtop

Why it fails: QAVG is not a standard esxtop metric; the correct queue-related metric is KAVG. Even if it existed, it would measure queuing time rather than the device response time. The administrator needs a device-level latency metric to compare against the array's reported latency.

KAVG (kernel average latency) in the device view of esxtop

Why it fails: KAVG measures the time an I/O request spends in the VMkernel queue before being issued to the device. It is useful for diagnosing host-side queuing but does not represent the round-trip latency seen by the storage array. Comparing KAVG to array latency would not accurately isolate the source of the delay.

Change the port group VLAN ID to 4095.

Why it fails: Setting the port group VLAN ID to 4095 would enable Virtual Guest Tagging, requiring the guest OS to tag traffic. The guest is not tagging (it has a static IP in the correct subnet, implying untagged traffic). This change would break connectivity further. The current VLAN ID 10 is correct for the access port configuration.

Verify that the physical switch port is configured as a trunk.

Why it fails: The physical switch port is already configured as an access port for VLAN 10, which is correct for a standard switch with VLAN ID 10 on the port group. Changing it to a trunk would not match the port group configuration and could cause further issues. The problem is likely not the physical switch port mode, since it aligns with the port group.

Restart the management agents on the ESXi host.

Why it fails: Restarting management agents is a drastic step and unlikely to resolve a single VM's connectivity issue. It could disrupt host management and other VMs. The problem is isolated to one VM, so the focus should be on the VM's configuration, not host-level services. This is not an appropriate next step.