CCNA Vsphere Performance Questions

A CPU limit caps the maximum CPU MHz a virtual machine may consume, directly restricting its resource usage. Shares only affect contention priority and reservations guarantee a minimum, so neither bounds peak consumption. The limit therefore satisfies the requirement to cap a single VM's CPU consumption.

Partially automated DRS only generates migration recommendations; it never moves the VM itself. Setting the VM's automation level to Automatic lets DRS execute migrations, satisfying the requirement to relocate the VM away from the loaded host.

DAVG in the device view reports the average latency of I/O operations as measured by the ESXi host's storage stack. Comparing DAVG to the array's own reported latency helps isolate whether the delay originates in the host stack or at the array. A significant discrepancy suggests host-side queuing or path issues, while matching values point to the array.

A VM-VM affinity rule with 'must run on the same host' pins the latency-sensitive VMs together, keeping inter-VM traffic on-host and avoiding inter-host network hops. DRS still balances other workloads, but never separates members of this rule.

%RDY above 20% means the VM's virtual CPUs wait in the scheduler queue before receiving physical CPU time. With 8 vCPUs, the VM needs eight free logical cores simultaneously, so an overcommitted host causes ready time to climb, confirming CPU contention from vCPU overallocation.

The cluster has 5 hosts, so losing one host means losing 20% of the cluster's resources. Setting the admission control policy to reserve 20% of cluster resources ensures that enough capacity remains to run all VMs after a single host failure. This policy allows HA to admit VMs only if the remaining resources can accommodate them, thus maintaining performance. It is the most appropriate setting for this scenario.

Transparent Page Sharing identifies identical memory pages across VMs and maps them to a single physical page, reducing the host's memory footprint without guest involvement. In this VDI scenario, many desktops share the same OS and application binaries, so TPS can reclaim significant memory and ease overcommitment pressure while preserving consolidation ratios.

Co-stop measures time a vCPU spends ready but unable to run because its co-scheduled siblings are descheduled, typically from over-sized SMP virtual machines. Reducing vCPUs to match actual workload demand lowers scheduling skew and co-stop, improving throughput.

KAVG/cmd measures the time a command spends in the VMkernel queue before being issued to the device, while DAVG/cmd measures device service time. A low DAVG with a high KAVG means the array responds quickly once asked, but the host-side queue is the bottleneck, so this reading correctly identifies VMkernel queuing as the source of added latency.

CPU shares determine the relative priority of a VM when the host is contended. Giving trading VMs a high shares value means that during contention they receive a larger proportion of available CPU time, reducing queuing delay. Shares work only under contention, which matches the scaling scenario where multiple workloads compete for cores.

vCenter performance charts expose CPU contention metrics such as ready time and co-stop for the host, revealing whether the 95% utilisation stems from overcommitted vCPUs, resource pool limits or unbalanced DRS rules. This data identifies the cause before any remediation.

CPU ready time measures the time a VM is ready to run but is waiting for a physical core. When vCPUs exceed physical cores, the scheduler must time-slice, so VMs wait in the run queue. A READY value around 12 percent for a latency-sensitive workload directly reflects this contention and is the primary contributor here.

Over-commitment of vCPUs causes high CPU ready time: 6 VMs × 8 vCPUs = 48 vCPUs on 32 physical cores, so the scheduler forces VMs to wait for physical cores. Reducing vCPU counts on the non-database VMs lowers contention, directly addressing the ready-time constraint.

With 16 vCPUs on a 12-core-per-socket host, the VM spans both NUMA nodes, so vCPUs access memory attached to the remote node. High Remote memory values and CPU cost confirm this, while low CPU ready rules out scheduling contention.

Fewer vCPUs reduce the number of co-scheduled vCPU worlds competing for the host's 16 physical cores, lowering the scheduler's wait time. CPU ready measures the percentage of time a vCPU is ready but waiting for a physical core, so shrinking the VM's vCPU count directly reduces contention.

Manual mode means DRS generates migration recommendations but applies none automatically. The administrator must therefore review the suggested moves and invoke vMotion to relocate VMs, correcting the imbalance. Switching to fully automated mode would change policy rather than resolve it directly.

High %RDY means vCPUs wait for physical cores. With hyper-threading, four vCPUs contend for limited logical processors, so reducing to two lowers scheduling pressure and co-stop, directly cutting ready time while still meeting the workload's needs.

A configured memory limit caps the VM's usable guest RAM below what the workload needs, so ESXi swaps pages out even though the host has free physical memory. Raising or removing the limit lets the VM retain its working set in RAM.

Co-Stop measures the percentage of time a symmetric multiprocessor virtual machine waits while its vCPUs are descheduled unevenly, directly exposing CPU ready time contention across the cluster. Monitoring it alongside CPU ready pinpoints whether oversized vCPU allocations or host overcommitment are starving virtual machines of physical cores.

Storage I/O Control (SIOC) allows you to set shares on virtual disks, which determines their relative priority for I/O resources when the datastore experiences contention. By enabling SIOC and assigning higher shares to database VMs, they receive preferential treatment during congestion. This directly addresses the requirement for preferential I/O treatment during contention.

DRS continuously monitors and balances resource usage by migrating VMs.

vMotion cannot preserve memory state when a PCIe passthrough device is attached, because direct device assignment pins the VM to host1's hardware. Removing the passthrough device first makes the VM migratable, allowing memory-state vMotion to host2.

SIOC applies per-datastore I/O shares and latency thresholds, throttling noisy-neighbour VMs when datastore latency exceeds a set limit. This directly satisfies the shared-storage scaling constraint by preventing one workload from starving others of I/O throughput.

Reservations guarantee a floor and limits impose a ceiling, independent of shares. Shares only arbitrate contention above the reservation. The pool therefore receives no less than its 2 GHz reservation and never exceeds its 4 GHz limit, even when the other pool holds higher shares.

A memory reservation guarantees that the specified amount of physical RAM is reserved for the VM. Setting it equal to the configured memory size ensures that the VM's entire memory is backed by physical RAM, eliminating memory overcommitment for that VM. This provides predictable performance and low latency, which is critical for high-bandwidth workloads.

vSphere DRS continuously balances VM placement across hosts by migrating workloads with vMotion based on CPU and memory demand, directly satisfying the requirement for automatic even distribution. Enabling it on the cluster activates initial placement plus ongoing load-balancing, which HA alone cannot provide.

CRC errors and dropped receive packets indicate corrupted frames arriving at the physical layer, typically from a damaged cable, faulty NIC, or bad transceiver. This points to the physical medium rather than switch policy or VLAN misconfiguration.

Storage IOPS capacity directly addresses the boot-storm constraint: when 1000 desktops power on simultaneously, concentrated read/write bursts can saturate the datastore and stall logons. Sizing must account for peak concurrent IOPS, not steady-state averages, since VMware's linked-clone and full-clone desktops both amplify boot-time demand.

CPU ready time indicates that the VM is waiting for physical CPU resources. Moving the VM to a less utilized host reduces contention, allowing the scheduler to allocate CPU cycles more quickly. This directly addresses the root cause by balancing the workload across the cluster. vMotion is a non-disruptive way to achieve this.

The host's physical NUMA node topology determines which memory and CPU resources are local to each other, so vSphere bases its initial placement and any rebalancing on that layout. Without knowing the node boundaries, the scheduler cannot keep a VM's vCPUs and memory within one node.

High CPU ready indicates VMs are waiting for physical CPU cycles, so reducing vCPUs cuts scheduling contention and adding hosts increases available cores. This directly relieves the oversubscription driving the elevated ready times across that cluster's hosts.

NetQueue offloads packet classification and filtering from the VMkernel to the physical NIC, letting the adapter steer flows into separate receive queues. This parallelises interrupt handling across CPU cores, cutting per-packet processing delay for the latency-sensitive VM's traffic. It directly satisfies the stem's requirement to reduce network latency in a vSphere environment.

%RDY measures the percentage of time a virtual machine's vCPUs are ready but waiting for physical CPU scheduling. A sustained 20.5 percent indicates CPU contention, meaning the host's physical cores are overcommitted relative to the running virtual machines' demand.

Large reservations lock physical pages, preventing the balloon driver from reclaiming them, so the host must swap to satisfy remaining demand. With 512 GB and overcommitment, reserved memory cannot be compressed or ballooned, forcing the VMkernel swap path and producing the high swap rate observed.

Enabling jumbo frames raises the MTU to 9000 on the virtual switch, reducing per-packet header overhead and CPU interrupts for large, sequential transfers. This satisfies the stem's performance-improvement constraint, provided every device along the path—physical switch, uplinks and guest NICs—is configured identically, otherwise fragmentation degrades throughput.

CPU affinity pins each vCPU to a specific logical processor, so the VM's four vCPUs cannot be co-scheduled onto available cores. When the scheduler cannot run all vCPUs simultaneously, the remaining ones wait, inflating %CSTP. Removing the affinity rule restores flexible co-scheduling and resolves the co-stop.

%RDY measures the percentage of time a VM was ready to run but waited for a physical CPU. A sustained value of 30.0 far exceeds the roughly 5% threshold, indicating the VM is repeatedly delayed by scheduler contention on overcommitted cores.

esxtop runs directly on the ESXi host console, sampling live CPU, memory, network and storage counters at sub-second intervals. Unlike vCenter's five-minute rollups, it exposes per-world and per-device detail, satisfying the stem's real-time host-level requirement without vCenter dependency.

Migrating the VM to a host with lower CPU utilisation directly reduces the scheduling delay causing high CPU ready time. CPU ready measures the time a vCPU waits for a physical core; moving the VM to a less contended host lowers the ready percentage, addressing the peak-hour degradation constraint without altering VM configuration.

DRS automates initial placement and ongoing load balancing, optimizing performance as VMs are added.

Resource pools support hierarchical nesting.

Ballooned memory directly evidences the hypervisor reclaiming guest pages through the balloon driver, which only inflates under genuine host memory contention. It therefore satisfies the stem's requirement for a metric proving active reclamation, unlike metrics such as active memory or consumed memory that merely describe usage without confirming pressure-driven reclaim.

Adding hosts expands the cluster's aggregate physical CPU capacity, so the same workload spreads across more cores. This lowers the vCPU-to-pCPU ratio, cutting the time VMs spend waiting in the run queue, which is precisely the overcommitment constraint the stem describes.

NFS traffic traverses the 1GbE link, so high network utilisation saturates the path and inflates disk latency. Upgrading to 10GbE, or teaming multiple NICs, raises aggregate throughput and relieves that bottleneck, directly addressing the constrained network link.

MEMCTL at 5% reflects the balloon driver reclaiming guest memory, while SWPOUT at 2% confirms the hypervisor is swapping to disk. Together these counters indicate the host has over-committed physical memory beyond what its workload demands, so ESXi is actively reclaiming pages to satisfy the configured memory constraint.

vSphere vMotion enables live migration of running workloads between hosts, supporting load balancing across a cluster without downtime. This directly satisfies the scaling constraint by allowing distributed resource scheduler to redistribute virtual machines, preventing host contention and maintaining performance as demand shifts across the virtualized environment.

Reducing vCPU count per VM decreases the number of virtual CPUs that the host scheduler must co-schedule, which can significantly lower CPU ready time. Many workloads do not require all allocated vCPUs, and over-provisioning vCPUs leads to co-scheduling overhead and increased ready time. Right-sizing VMs to their actual demand reduces contention and improves scheduling efficiency.