Performance-tuning, Optimization, and Upgrades
Performance signals
Learn the counters, not just the fixes. CPU ready time is the percentage of time a vCPU was ready but not scheduled; sustained values above roughly 5% suggest contention, and high co-stop indicates an oversized SMP VM. Memory pressure escalates from ballooning to compression to host swapping; swapping is the worst and should be rare. Datastore latency, queue depth, and network drops complete the picture. Use shares for relative priority, reservations for guarantees, and limits sparingly-limits can hide problems and hurt throughput.
Optimization and upgrades
Right-size VMs before adding hardware. Use DRS to balance clusters, Storage I/O Control to share datastore queues, and Network I/O Control on distributed switches. Keep snapshots short-lived; they grow delta disks and degrade performance. EVC masks CPU features for vMotion compatibility; set the baseline to the oldest CPU generation in the cluster. Upgrade order is vCenter first, then ESXi, then VMware Tools, then virtual hardware. vSphere Lifecycle Manager images simplify drift detection and remediation. Check interoperability before every upgrade.
Traps
Do not fix CPU contention by lowering limits. Do not assume more vCPUs always help; they can increase co-stop. Do not upgrade ESXi before vCenter. Do not leave snapshots as backups. Do not set EVC above the capabilities of the oldest host.
Worked example: A VM shows 12% CPU ready and its host is at 90% CPU utilization. The VM has 8 vCPUs on a 16-core host. Adding vCPUs would worsen co-stop. First reduce idle vCPUs to 4, then add a host or rebalance with DRS. Recheck ready time after each change.
Rule of thumb: Measure ready, balloon, swap, and latency before changing resources; then upgrade in the order vCenter → ESXi → Tools → hardware.