Vendor-neutral diagnostic workflow for modern hypervisors. Use the platform’s supported counters and logs; this is not a replacement for legacy ESX-specific procedures.
Research-based; no hands-on test claim.Define the symptom and blast radius
Record the user-visible failure, start time and recent changes. Determine whether one VM, several VMs on a host or an entire service is affected. Check whether the console works when network access fails. A working console narrows the problem but does not establish that the guest application is healthy.
Compare with an unaffected VM using the same host, storage or network. Note which dependency is shared. Avoid rebooting immediately unless the incident plan requires it, because transient counters and logs may be lost.
Inspect the layers in a consistent order
Within the guest, check application logs, resource pressure and recent updates. At the virtual network layer, inspect adapter state, VLAN or port-group placement, addressing and DNS. At storage, compare latency, free capacity and errors across the guest and backing datastore.
On the host, inspect contention, hardware health and management events. A guest CPU percentage may not describe time spent waiting for host scheduling. Use the hypervisor’s own documented measurements rather than interpreting every counter as though it were a physical server metric.
Change one variable with a recovery path
Form a testable hypothesis, such as a storage slowdown shared by VMs on one datastore. Capture a baseline and choose a low-risk check before adding resources or moving workloads. A migration can move the symptom while obscuring the cause.
Before resizing, changing controllers or restarting, confirm application impact, backup readiness and rollback limits. Do not delete snapshot or virtual-disk files manually to recover space. A storage emergency needs the platform’s supported consolidation or recovery procedure.
Verify the original workload
After a change, repeat the user operation and compare the same measurements over a representative period. Check other VMs sharing the affected resources. A fast login immediately after a reboot does not prove that a recurring workload problem is resolved.
Retain the timeline, relevant counters, platform versions and change outcome for escalation. If evidence points to hardware, storage or a vendor defect, stop speculative tuning and use the supported support path with the collected record.