JUMP TO SECTIONChoose a lesson section
What you'll be able to explain.
- 01Distinguish a physical host, hypervisor, VM, virtual disk, virtual switch and datastore.
- 02Recognize CPU contention, memory pressure, storage latency and guest OS signals.
- 03Explain why VMware snapshots and Hyper-V checkpoints are not a substitute for independent backups.
- 04Evaluate host evacuation and maintenance readiness before starting a disruptive change.
The guest is not the host.
Virtualization separates a guest's software environment from the physical hardware while still depending on that hardware.
Host & hypervisor
A physical host supplies CPU, RAM, network adapters and storage connectivity. The hypervisor schedules workloads and manages virtual devices; examples include VMware ESXi and Microsoft Hyper-V.
VM & guest
A virtual machine has configured vCPUs, virtual RAM, virtual disks and virtual NICs. The guest OS sees those devices, but capacity is ultimately constrained by real host resources.
Datastore & network
A datastore holds VM files and disks. Virtual switches, port groups or VM switches connect guest NICs to networks; VLAN selection and physical uplinks must agree.
Operational takeawayShared infrastructure creates shared symptoms: one datastore or physical NIC incident can impact many seemingly unrelated VMs.
Allocated is not the same as available.
Overcommit and scheduling are powerful but can obscure where performance is being lost.
CPU contention
High vCPU allocation does not guarantee physical CPU time. Look for host contention and scheduling indicators such as CPU ready rather than increasing vCPU counts blindly.
Memory pressure
Guest memory demand competes with other VMs and host services. Ballooning or host swapping under pressure can create latency; check reservations before migrations.
Storage latency
A datastore can have ample nominal capacity yet suffer I/O delays. Consider snapshot growth, backup contention, rebuild activity and storage network health.
Operational takeawayCheck host and guest perspectives together. A slow application need not mean the application code is at fault.
Snapshot ≠ backup.
A rollback aid is convenient, but it is not a separate recovery strategy.
VMware snapshots
vSphere snapshot delta disks depend on the base virtual disk. They can grow, increase consolidation work and cause datastore pressure; vendor guidance warns against using them as backups.
Hyper-V checkpoints
Standard checkpoints capture VM state including memory and can be unsafe for certain replicated workloads. Production checkpoints use supported consistency mechanisms such as VSS or filesystem freeze.
Independent recovery
Use supported, tested backup processes with independent retention and restore verification. A short-lived checkpoint around a change can supplement—not replace—those protections.
Checkpoint: local rollback convenience, still depends on VM storage
Backup: independently protected restore point, restore must be tested
Recovery proof: boot + data integrity + application workflowOperational takeawayBefore deleting a checkpoint, use the hypervisor's supported merge/consolidation workflow. Do not manually delete backing delta files.
Follow a packet out of the guest.
Misplaced virtual networking settings are among the easiest issues to misdiagnose.
Guest interface
Inspect guest IP, gateway, DNS, link state and route selection. These answer whether the guest's own network stack is configured properly.
Virtual switch
Verify vNIC attachment, correct virtual port group or switch, VLAN, and any port security or virtual networking rules.
Physical uplink
Trace upstream NIC teaming and switchport configuration. An intact vNIC does not prove the host's physical uplink and VLAN path are working.
Operational takeawayCorrelate guest, hypervisor and upstream network evidence before editing multiple layers.
Maintenance mode is a dependency check.
Updating a host is not equivalent to patching an isolated laptop. You must know how its VMs will keep running—or explicitly arrange downtime.
Cluster evacuation
In supported configurations, migrate running workloads to compatible hosts with adequate compute, memory and storage/network access. Automatic DRS evacuation depends on cluster settings.
Standalone host
Without a compatible migration destination, schedule and communicate required guest downtime; ensure recovery and rollback readiness before a host reboot.
Verify after change
Check host version/firmware, health alarms, VM placement, datastore access, network paths, guest services and application transactions.
Ticket: Host maintenance mode stuck
- Two hosts in a cluster; target host still runs an important VM
- Destination host has insufficient unreserved RAM for that VM's reservation
- Change window begins in 15 minutes
Pause remediation. Review the VM reservation and compatible destination capacity with the change owner; arrange an approved migration or reschedule with a documented downtime plan.
Forcing the host update does not resolve a failed evacuation and may interrupt production.
Can you defend the decision?
Try answering from memory before expanding each explanation. These checks support learning; they are not an exam-readiness score.
01A datastore is 94% full, and a VM has several aging snapshots. Is deleting a delta disk directly a safe first action?+
No. Snapshot chains reference base and delta files. Inspect space and snapshot status, verify backups, then use the supported hypervisor consolidation process with adequate headroom.
02Hyper-V offers Standard and Production checkpoints. What is the important distinction?+
Standard captures memory and device state, while Production uses guest consistency mechanisms such as VSS/filesystem freeze and does not capture running memory state. Neither is an independent backup.
03Why can a host with 'free memory' still refuse a VM migration?+
Destination compatibility, available unreserved capacity, VM memory reservations, and additional host or cluster constraints can block migration even when one headline metric looks sufficient.
Read from the source.
Vendor procedures depend on product version, hardware compatibility, and the environment's approved change controls. Verify the current documentation for any production task.