2.4 Managing Virtual Machines Through vCenter: Day-2 Operations
Key Takeaways
- vSphere vMotion moves a running VM's compute state between hosts; Storage vMotion moves its files between datastores; both are live and require no guest downtime.
- Snapshots create a delta (child) disk and freeze the parent VMDK; they capture a point in time for short-lived rollback and are explicitly not a backup mechanism.
- Resource controls apply in a fixed order of authority: reservations guarantee a floor, limits impose a ceiling, and shares only arbitrate when contention actually exists.
- Content Libraries provide the supported way to publish and subscribe VM templates, OVF items, and ISOs across vCenter instances in a VCF fleet.
- VMware Tools supplies the guest drivers, quiesced snapshot support, heartbeat used by vSphere HA VM Monitoring, and guest customization hooks; a VM without Tools loses those capabilities.
2.4 Managing Virtual Machines Through vCenter: Day-2 Operations
Exam Focus: The official 2V0-17.25 blueprint separates deploying a virtual machine from managing one. This section covers the management half — the day-2 operations an administrator performs against a running workload through vCenter. Expect scenario items that describe a symptom (a migration that will not proceed, a datastore filling unexpectedly, an application starved of CPU) and ask which mechanism explains or resolves it.
Live Migration: vMotion and Storage vMotion
Two distinct migration technologies exist, and exam scenarios routinely test whether a candidate can tell which one applies.
| Capability | vSphere vMotion | Storage vMotion |
|---|---|---|
| What moves | Compute state: memory, CPU registers, device state | Virtual disk files (VMDK, swap, config) |
| What stays | Storage location is unchanged | Host and memory state are unchanged |
| Typical driver | Host maintenance, DRS load balancing | Datastore evacuation, storage rebalancing, policy change |
| Network requirement | VMkernel adapter tagged for vMotion traffic on every participating host | None specific; uses the storage path |
| Guest impact | None — the VM keeps running and retains its IP and MAC | None — the VM keeps running |
A combined operation, sometimes called compute-and-storage vMotion, moves both at once and is what makes cross-cluster and cross-vCenter relocation possible.
Why a vMotion is rejected. The most common blockers are worth memorising because they appear as distractors:
- The destination host cannot see a network backing one of the VM's port groups.
- CPU feature mismatch between source and destination generations, which is what Enhanced vMotion Compatibility (EVC) exists to mask by presenting a common baseline feature set to guests.
- A device that pins the VM to hardware, such as a mounted host-local ISO, a passthrough PCI device, or an attached physical serial port.
Snapshots: Mechanics and Boundaries
When a snapshot is taken, vSphere stops writing to the base VMDK and creates a delta (child) disk. All subsequent writes land in the delta. The parent becomes read-only and preserves the point-in-time image.
Several consequences follow directly from that design, and each is examinable:
- Snapshots consume capacity that grows with change rate. A busy database with a forgotten snapshot can consume as much space as the original disk. Unexpected datastore growth traced to a long-lived snapshot is a classic scenario.
- Performance degrades as the chain lengthens, because reads may have to traverse multiple delta disks to assemble current data.
- Deleting a snapshot triggers consolidation, which commits delta data back into the parent. Consolidation is I/O intensive; it is not an instant operation.
- A snapshot is not a backup. It lives on the same datastore and depends on the same base disk. Losing the datastore loses both.
A memory snapshot additionally captures the VM's running memory state, allowing a revert to a powered-on running state, at the cost of a longer stun. A quiesced snapshot uses VMware Tools to flush the guest file system to a consistent state before the delta is created — which is why Tools is a prerequisite for application-consistent snapshots.
Resource Controls: Shares, Reservations, and Limits
Three distinct controls govern how a VM competes for CPU and memory. Candidates lose marks by conflating them.
| Control | Guarantees | Applies when | Failure mode if misused |
|---|---|---|---|
| Reservation | A guaranteed minimum of physical resource | Always — held even when idle | Blocks VM power-on when unreservable capacity is exhausted; also constrains HA admission control |
| Limit | An enforced ceiling the VM may never exceed | Always | Silent, persistent throttling even on a completely idle host — the hardest to diagnose |
| Shares | Relative priority weighting | Only during contention | No effect at all when resources are plentiful, which surprises administrators expecting a guarantee |
[!WARNING] The idle-host throttling trap. A scenario describes an application performing poorly on a host with abundant free CPU. Shares cannot cause this, because shares are inert without contention. A limit can, and does, because it is enforced unconditionally. When a scenario pairs "plenty of free resource" with "still slow", look for a limit.
Resource pools apply the same three controls to a group of VMs, allowing an administrator to carve a cluster's capacity between tenants or tiers.
Templates and Content Libraries
Standardised deployment depends on golden images. A VM template is a non-bootable master copy cloned to produce new VMs, usually paired with a guest customization specification that sets hostname, network identity, and domain membership at first boot so clones do not collide.
In a multi-vCenter VCF fleet, the supported distribution mechanism is the Content Library:
- A published (local) library holds the source items — VM templates, OVF/OVA packages, ISOs, and scripts.
- Subscribed libraries in other vCenter instances consume that content, either downloading immediately or on demand.
- Synchronisation keeps every workload domain aligned to the same approved image, which is what makes an image standard enforceable rather than aspirational.
This library model is also the foundation for the provider content libraries that VCF Automation exposes to tenants, covered later in Chapter 9.
VMware Tools and Guest Integration
VMware Tools is easy to dismiss as an optional add-on. It is not, and its absence produces symptoms that appear unrelated:
- Quiesced snapshots are unavailable, so backup integrations fall back to crash-consistent copies.
- Guest heartbeat stops, which disables vSphere HA VM Monitoring — HA can still restart the VM after a host failure, but it can no longer detect a hung guest on a healthy host.
- Graceful shutdown and restart from vCenter degrade to a hard power operation.
- Guest customization cannot run, so cloned VMs keep the template's identity.
Exam Watch: Key Scenarios and Candidate Traps
[!IMPORTANT] Match the migration to the problem. Evacuating a datastore that is nearly full is a Storage vMotion task. Placing a host into maintenance mode is a vMotion task. A scenario that mentions both a full datastore and host maintenance is testing whether you can separate them.
[!TIP] Trace unexplained datastore growth to snapshots first. If consumed space exceeds provisioned disk size and a snapshot exists, delta growth is almost always the cause, and consolidation is the remedy.
An application owner reports sustained poor CPU performance for a virtual machine. The administrator confirms the ESX host is only 20 percent utilised, no other VMs are contending for CPU, and the cluster has ample headroom. Which configuration most likely explains the symptom?
A monitoring alert reports that a datastore is nearly full. Investigation shows one virtual machine consuming substantially more space than the sum of its provisioned virtual disks, and a snapshot taken six weeks ago is still present. What is the correct explanation and remedy?
A VCF administrator must ensure that every workload domain in the fleet deploys virtual machines from the same approved golden image, and that updating the image in one place propagates to the others. Which vCenter capability meets this requirement?
After a guest operating system hangs on a healthy ESX host, an administrator discovers that vSphere HA never restarted the affected virtual machine even though VM Monitoring is enabled on the cluster. Which condition best explains this?