vSphere Performance and Scaling practice questions

Configure the VM to use multiple paths with Round Robin policy.

Why it fails: Path policy affects throughput, not latency.

Assign a separate VMDK for each critical VM on a dedicated datastore.

Why it fails: This is not a standard practice and does not guarantee low latency.

Enable Storage I/O Control (SIOC) on the datastore.

Why it fails: SIOC manages congestion but does not improve underlying latency.

Implement vSAN using HDDs with a flash cache tier.

Why it fails: HDDs still have higher latency than all-flash VDI requirements.

Deploy a centralized all-flash FC SAN with multiple paths.

Why it fails: Centralized SAN may become a bottleneck as VDI scales.

Use a single NFS datastore on a large spinning-disk array.

Why it fails: Single datastore creates a bottleneck and lacks IOPS.

NUMA node mismatch causing cross-node memory access.

Why it fails: Cross-node NUMA access adds memory latency, not scheduler wait; CPU ready reflects vCPUs waiting for physical cores, and 16 vCPUs across two sockets still leaves the 4-vCPU VM within a single node. NUMA affinity matters when a VM's vCPU count exceeds one node's cores.

CPU hot-add is enabled on the VM.

Why it fails: CPU hot-add merely permits adding vCPUs while powered on; it does not itself consume ready time. It tempts because it is a CPU-related VM setting, but it would be relevant to a question about vNUMA topology or unsupported hot-add configurations, not scheduler contention.

Memory over-provisioning causing ballooning.

Why it fails: Ballooning reclaims guest memory and inflates CPU usage inside the guest, but it does not create ready time, which measures vCPUs waiting on the physical scheduler. It tempts because memory over-commitment is a common performance culprit, yet the host has ample 256 GB and the symptom is CPU-specific.

Disable deduplication and compression on the vSAN datastore.

Why it fails: Deduplication and compression reduce capacity consumption, not read latency; disabling them adds write amplification without addressing the read path. It is tempting because these features do consume CPU and memory, so administrators blame them for performance, but they would be the correct focus only when capacity savings matter more than throughput.

Reconfigure the disk groups to use multiple cache devices.

Why it fails: Each disk group supports only a single cache device, so multiple cache devices per disk group cannot be configured; the fix would be additional disk groups. It is tempting because cache capacity does drive read performance, and adding cache devices would be correct when a host has unused physical disks available for new disk groups.

Increase the network bandwidth between hosts.

Why it fails: Bandwidth affects inter-host traffic, but read latency in an all-flash vSAN cluster typically stems from the cache tier or disk group configuration, not link saturation. Increasing bandwidth is tempting because network bottlenecks do cause latency, and it would be correct if monitoring showed vSAN VMkernel interfaces saturated during the affected workload.

Set DRS migration threshold to the most aggressive setting.

Why it fails: Setting the DRS migration threshold to the most aggressive level is not recommended because it causes frequent vMotions, increasing overhead and potentially causing more scheduling delays.

Enable Distributed Power Management (DPM).

Why it fails: DPM is designed for power savings and can cause delays when hosts are powered on or off, making it unsuitable for latency-sensitive workloads.

Enable Enhanced vMotion Compatibility (EVC).

Why it fails: EVC ensures CPU compatibility across hosts but does not directly address CPU scheduling delays.

Create separate standard switches for VM traffic and management.

Why it fails: Standard switches still lack advanced features.

Enable SR-IOV on the physical NICs and assign virtual functions to VMs.

Why it fails: SR-IOV may prevent vMotion and other features.

Use a single vSphere Standard Switch for all traffic.

Why it fails: Standard switch lacks QoS and jumbo frame support.

Memory ballooning due to memory over-commitment.

Why it fails: Ballooning is a memory-reclamation mechanism; it raises guest CPU consumption but does not make vCPUs wait for physical cores, which is what ready time measures. It tempts because over-commitment is a frequent performance issue, but it would be correct for memory-related symptoms such as swapping.

Using CPU affinity to pin VMs to specific cores.

Why it fails: Affinity can reduce ready time by preventing migration.

High disk latency on the datastore.

Why it fails: Disk latency delays storage I/O and can stall a vCPU in a virtual machine monitor wait state, but it registers as disk or I/O latency metrics, not CPU ready. It tempts because storage bottlenecks degrade VM performance broadly, yet ready time specifically measures scheduler wait for physical cores.

Separate vMotion traffic onto a different VLAN.

Why it fails: Separating vMotion traffic onto a different VLAN helps reduce congestion and improves performance for vMotion, but it does not directly reduce network latency for general VM traffic. It is more about isolating management traffic.

Increase the MTU on the vSphere Standard Switch to 9000.

Why it fails: Increasing the MTU on the vSphere Standard Switch alone does not enable jumbo frames; the physical network must also support and be configured for jumbo frames. Without end-to-end consistency, fragmentation can occur, negating the benefits. Option B is the correct phrasing for enabling jumbo frames.

PowerCLI scripts that retrieve performance data.

Why it fails: PowerCLI is a scripting tool, not a monitoring method.

VMware Workstation.

Why it fails: Workstation is not for monitoring vSphere.

vCenter Log Insight.

Why it fails: Log Insight is for log analysis, not performance metrics.

Disable DRS for the VDI cluster to prevent VMs from migrating during peak hours.

Why it fails: Disabling DRS may cause imbalance, not improve cache performance.

Change the VM storage policy to RAID-5 erasure coding to reduce capacity overhead, freeing cache for reads.

Why it fails: RAID-5 erasure coding reduces usable capacity overhead but consumes additional CPU and disk operations per read, and it does not enlarge the NVMe read cache. RAID-5 is the correct policy when capacity efficiency matters more than latency, not when cache hit ratio and read latency are the symptoms.

Add more SATA SSD capacity disks to each host to increase overall storage performance.

Why it fails: Adding SATA SSD capacity disks expands the capacity tier, not the NVMe cache tier, so the 60% cache hit ratio and 15 ms read latency remain unchanged. Capacity disks are the right remedy when the disk group is running out of space, not when read caching is the bottleneck.

Enable DPM and set the cluster to aggressive power management.

Why it fails: DPM consolidates VMs, increasing contention.

Increase the number of vCPUs on the ERP VM to 12 to distribute load.

Why it fails: More vCPUs can increase ready time due to co-scheduling.

Increase the memory allocation of the ERP VM to reduce ballooning.

Why it fails: Memory does not affect CPU ready time.

Increase the number of outstanding I/O requests per virtual disk in the VM settings.

Why it fails: Incorrect: Increasing outstanding requests can increase queue depth and latency.

Disable SIOC on the datastore to avoid overhead.

Why it fails: Incorrect: Disabling SIOC removes I/O management, which can worsen latency under contention.

Enable SIOC on the datastore and set the latency threshold to a higher value.

Why it fails: Incorrect: A higher threshold reduces sensitivity, potentially increasing latency.

resxtop

Why it fails: resxtop is the remote CLI equivalent of esxtop, offering live per-host counters but no persistent historical database or cluster-wide aggregation. It fits ad-hoc remote troubleshooting of one host; the stem's requirement for retained historical data across 200 VMs exceeds its scope.

esxtop with output logged to a file

Why it fails: esxtop logged to a file captures real-time metrics but provides no built-in historical retention, aggregation or long-term trending across ten hosts. It suits interactive, single-host troubleshooting sessions; cluster-wide historical data with minimal overhead requires a central monitoring platform.

vRealize Operations Manager

Why it fails: vRealize Operations Manager delivers historical data and analytics but deploys analytics nodes, adapters and a database, adding substantial infrastructure overhead. It suits long-term capacity planning and dashboards; the stem's least-overhead constraint favours the built-in vSphere performance charts instead.

The CPU reservation is preventing the VM from using more than the reserved amount.

Why it fails: Incorrect: Reservation guarantees a minimum, not a maximum.

The CPU shares are too low, causing the VM to be starved.

Why it fails: Incorrect: Shares determine priority, not a hard cap.

DRS is not migrating the VM to a host with more resources.

Why it fails: Incorrect: DRS migration would not cap CPU usage on the current host.

Add one additional disk group to each host to increase storage performance.

Why it fails: Incorrect: Adding disk groups can improve parallelism but does not directly reduce the overhead from FTT=2.

Remove one host from the cluster to reduce network traffic.

Why it fails: Incorrect: Removing a host would reduce fault tolerance and may cause data unavailability.

Add a fourth host to the vSAN cluster to distribute the load.

Why it fails: Incorrect: Adding a host may help with capacity but not directly with latency; the cluster already meets minimum requirements.

A firewall is blocking return traffic from that client.

Why it fails: TIME_WAIT is a normal TCP state after the local side closes a connection; a firewall blocking return traffic would instead produce SYN timeouts or resets. Firewall rules are a valid suspect when connections fail to establish, not when they close cleanly.

The host's TCP stack is misconfigured for high traffic.

Why it fails: TIME_WAIT is a normal TCP state after a connection closes, not evidence of stack misconfiguration; the exhibit's pattern reflects ordinary HTTPS session teardown between the host and vCenter. Tuning TCP parameters addresses throughput or port exhaustion under heavy load, which the stem does not describe.

The host is under memory pressure and dropping connections.

Why it fails: Memory pressure causes VM swapping or hostd failures, not TIME_WAIT sockets, which persist after orderly connection closure. The state is generated by normal TCP teardown, so it appears regardless of memory. Memory reclamation tuning would be relevant only if the exhibit showed ballooning or swap activity.

Migrate the database VM to a host with fewer VMs.

Why it fails: While it might help, the issue is likely NUMA-related and migration is a temporary fix.

Enable CPU hot-add for the database VM.

Why it fails: CPU hot-add lets vCPUs be added to a running VM, but the database VM already has 16 vCPUs pinned to cores 0-15, and the 15% CPU ready plus high co-stop indicate scheduler wait from that pinning, not a shortage of vCPUs. Hot-add is the right choice when a VM needs additional processors without downtime, not when affinity constraints are stalling vCPU scheduling.

Increase the number of vCPUs for the database VM to 32.

Why it fails: More vCPUs would increase contention and likely worsen performance.

esxcli: Used for managing virtual machine snapshots

Why it fails: Incorrect — esxcli does not manage snapshots; that is done via PowerCLI or vSphere Client.

vmkfstools: Used for managing ESXi host network settings

Why it fails: Incorrect — network settings are managed with esxcli, not vmkfstools.

Increase the virtual disk shares for the VM

Why it fails: Increasing shares only provides relative priority but may not guarantee latency improvements.

Move the VM to another datastore

Why it fails: This may spread load but does not directly address the root cause of latency on the current datastore.

Set a higher I/O limit on the VM

Why it fails: Setting a limit caps I/O but may not reduce latency; it could even worsen performance.

vSAN deduplication and compression

Why it fails: Deduplication affects capacity, not write latency directly.

vSAN object repair timer

Why it fails: The repair timer affects object availability, not performance under normal conditions.

vSAN network MTU setting

Why it fails: MTU affects throughput, not specifically cross-site write latency.