4.3 vMotion, Storage vMotion & Snapshot Management

4.3 vMotion, Storage vMotion & Snapshot Management

Workload mobility and point-in-time recovery are foundational operational capabilities of VMware vSphere Foundation. Live migration decouples running virtual machines from specific physical hosts and storage arrays, enabling non-disruptive hardware maintenance, dynamic resource balancing via DRS, and live storage lifecycle management. Concurrently, virtual machine snapshots provide rapid, reversible checkpoints for operational tasks such as software patching and application upgrades.

---

vMotion Architecture: Memory Pre-Copy, Dirty Page Tracking & Stun Time

vSphere vMotion migrates the active execution state of a running virtual machine from one ESXi host to another while the VM remains powered on, with a brief execution pause at switchover; validate application tolerance.

The Four Architectural Migration Phases

1. Initialization & Target Pre-Allocation: vCenter coordinates with the source and target ESXi hosts. The target host instantiates a "skeleton" virtual machine container, reserving required physical compute and memory structures on the destination.
2. Iterative Memory Pre-Copy & Bitmap Tracking:
   • In the initial pre-copy pass, the VMkernel reads all physical memory pages assigned to the running VM and streams them across the dedicated vMotion network to the target host.
   • While this transfer occurs, the virtual machine continues executing guest instructions on the source host, writing to and modifying ("dirtying") memory pages.
   • To track these ongoing modifications, the VMkernel installs a Modified Page Bitmap in memory. Any page altered by a guest CPU thread during the pre-copy pass is flagged as "dirty".
   • In subsequent passes, the VMkernel transfers only the pages flagged in the bitmap. This iterative process repeats across multiple passes, with each pass transferring an increasingly small delta of dirty pages.
3. The Switchover Stun Time Phase:
   • When the remaining dirty memory pages can be transmitted within a microscopic window (typically under 100 milliseconds), the source VMkernel momentarily suspends ("stuns") the virtual machine.
   • During this sub-second stun window, guest instruction execution is frozen. The hypervisor transfers the final dirty memory delta along with the VM's active CPU instruction pointer, register states, and virtual device states to the target host.
   • The target host immediately assumes execution context and resumes guest OS processing.
4. Network Re-Routing via Reverse ARP (RARP):
   • Because the VM maintains its original virtual MAC address and IP configuration, physical top-of-rack (ToR) switches must be notified of its new physical switch port location.
   • The destination virtual switch immediately issues a broadcast Reverse Address Resolution Protocol (RARP) frame (or gratuitous ARP) on behalf of the virtual machine's MAC address.
   • Physical switches receive the frame and instantaneously update their internal Content Addressable Memory (CAM) forwarding tables, redirecting inbound network frames to the destination host's physical uplink with a brief switchover whose effect depends on the application.

---

vMotion Prerequisites & Network Architecture

For a vMotion migration to succeed, source and target hosts must meet strict architectural criteria:

1. CPU Compatibility & Enhanced vMotion Compatibility (EVC)

• Virtual machine execution relies on physical CPU instruction sets (e.g., AVX, AVX-512, SSE4.2, AES-NI). If a VM starts on a host with advanced CPU features and attempts to migrate to a host lacking those instructions, the guest OS will panic if an unhandled instruction is called.
• Enhanced vMotion Compatibility (EVC): An enterprise cluster feature that enforces a uniform CPU feature baseline across all ESXi hosts. EVC uses hardware-assisted CPU masking to hide newer CPU instruction sets from the guest operating system, presenting a consistent CPU model to all VMs. This allows seamless live migration across different processor generations (such as different Intel Xeon generations) within the same cluster.

2. VMkernel Network Design & Multi-NIC vMotion

• Dedicated VMkernel Interface: vMotion requires at least one VMkernel (vmk) network interface with the vMotion service enabled.
• Bandwidth Standards: A minimum of 1 Gbps dedicated throughput is required; 10 Gbps, 25 Gbps, or higher is strongly recommended for modern high-memory workloads.
• Multi-NIC vMotion: Administrators can bind multiple physical network adapters (uplinks) to separate VMkernel interfaces on the same virtual switch. The VMkernel automatically load-balances concurrent vMotion memory streams across all active adapters, dramatically reducing total migration duration and memory pre-copy passes for large database VMs.
• Jumbo Frames (MTU 9000): Enabling an MTU of 9000 end-to-end across virtual switches and physical network fabrics reduces CPU packet processing overhead during high-volume memory replication.
• Network Latency Boundaries: Validate latency and bandwidth against the supported migration design. Long-distance and cross-vCenter migrations have additional version, network, licensing and identity requirements; a local-cluster assumption is insufficient.

---

Storage vMotion (svMotion): Architecture & Disk Provisioning Conversion

While standard vMotion migrates execution state, Storage vMotion (svMotion) migrates virtual machine disks (.vmdk) and configuration files across datastores (VMFS, NFS, vSAN) while the VM remains powered on; validate application tolerance.

Real-Time I/O Mirroring Mechanism

Modern Storage vMotion utilizes an active I/O Mirroring architecture:

1. When svMotion initiates, the hypervisor attaches a mirror filter driver to the VM's storage execution stack.
2. In the background, the VMkernel sequentially reads blocks from the source virtual disk and writes them to the target datastore.
3. Concurrently, any new write operations generated by the active guest OS are mirrored: the driver writes the block to both the source datastore and the destination datastore simultaneously.
4. Once all original blocks are copied and target writes are synchronized, the hypervisor performs an instantaneous switchover of the disk descriptor (.vmdk), points guest I/O exclusively to the destination datastore, and safely purges the original source files.

Live Disk Provisioning Format Conversion

Storage vMotion provides the unique capability to transform virtual disk allocation formats on-the-fly during migration without taking the virtual machine offline:

---

Snapshot Mechanics: Delta Disks, Redo Logs & Write Redirection

A Virtual Machine Snapshot captures the entire state, disk data, and optionally memory state of a virtual machine at a specific point in time, enabling rapid rollbacks during risky administrative operations (such as OS patch bundles or application upgrades).

Internal Disk File Structure

When a snapshot is created on a VM with base disk vm-01.vmdk:

1. The base disk file (vm-01-flat.vmdk) is instantly locked as read-only.
2. The VMkernel creates a child delta disk (also known as a redo log), consisting of a descriptor file (vm-01-000001.vmdk) and a binary delta extent (vm-01-000001-delta.vmdk).
3. Write Redirection: All subsequent write operations issued by the guest operating system are redirected into the child delta disk. The base disk remains entirely unmodified.
4. Read Traversal: When the guest OS reads a disk block, the hypervisor checks the child delta disk first. If the block has been written since the snapshot was taken, it is served from the delta disk. If the block has not been modified, the read request traverses down the snapshot chain to the parent base disk.

Snapshot Memory State Option

When creating a snapshot, administrators can select Snapshot the virtual machine's memory:

• If enabled, ESX saves snapshot state and memory data using the snapshot files applicable to that release, including memory data files where used. Reverting to the snapshot restores the exact running execution state (including open applications and active memory buffers) without requiring a VM reboot.
• Without saved memory, consistency depends on whether supported guest/application quiescing was requested and succeeded. A non-quiesced running-VM snapshot is normally crash-consistent. Reverting a disk-only snapshot does not restore the original running memory state.

---

Performance Penalties, Limits & Best Practices

While snapshots are invaluable operational tools, improper snapshot management is one of the leading causes of storage performance degradation and unplanned outages in enterprise datacenters.

The Operational Hazards of Aged Snapshots

1. Severe Storage I/O Latency: As a snapshot chain lengthens or a delta disk expands, the hypervisor must perform multiple metadata lookups across the snapshot chain for every read request. This introduces significant storage latency, degrading IOPS and causing application time-outs.
2. Datastore Capacity Exhaustion: Delta disks expand dynamically as blocks are modified. On write-heavy virtual machines (such as transactional databases or mail servers), a delta disk can grow to match the entire configured size of the base disk. If multiple snapshots consume all free space on a datastore, affected VMs may be stunned or fail writes; the impact depends on which files need growth and the available space.
3. Snapshots Are NOT Backups: A snapshot depends 100% on the integrity of the underlying parent base disk. If the parent disk is deleted, corrupted, or lost due to SAN array failure, the child delta disk is completely useless. Snapshots do not provide off-site redundancy or independent data protection.

VMware Snapshot Best Practices

• Maximum Retention Age: Retain snapshots for a maximum of 24 to 72 hours. Snapshots should serve strictly as short-term checkpoints before software changes.
• Maximum Chain Length: While the hypervisor architecturally supports up to 32 snapshots in a traditional supported snapshot chain; native storage-specific snapshot capabilities differ, VMware strictly recommends maintaining no more than 2 to 3 snapshots in production environments.
• Regular Auditing: Implement automated vCenter alarms or VCF Operations policies to alert on snapshots older than 3 days or exceeding 50 GB in size.

---

Snapshot Consolidation Architecture

When an administrator selects Delete Snapshot or Delete All, the hypervisor commits all changed blocks from the delta disks back into the parent base disk and deletes the delta files. This process is known as Snapshot Consolidation.

The "Consolidation Needed" Condition

During automated enterprise backups leveraging the vSphere Storage APIs for Data Protection (VADP), backup software creates a temporary snapshot, mounts the base disk for reading, and instructs vCenter to delete the snapshot upon completion. If communication between the backup proxy and vCenter terminates prematurely, the snapshot deletion task may fail, leaving orphaned delta files attached to the VM.

vCenter flags this condition with a warning: 'Virtual machine disks consolidation is needed'. To resolve this without downtime, the administrator executes Consolidate from the vSphere Client. The VMkernel locks the delta hierarchy, merges the orphaned redo logs into the base virtual disk, and unlinks the delta files with potential I/O impact and a final stun; verify free space, backup-proxy locks and application tolerance.

Official Reading

Use the official 2V0-16.25 objective guide for scope and Broadcom technical documentation for the installed 9.0 component. This independent lesson was reviewed October 18, 2026; actual deployment support depends on the applicable version and configuration.

Datastore-Specific Allocation

The thin/lazy-zeroed/eager-zeroed examples describe applicable traditional virtual-disk formats. On vSAN, storage policies and object-space reservation govern allocation semantics; do not assume every target exposes the same VMFS format choices. Validate the selected datastore, backup product and application before changing allocation.

Review Takeaways

• vMotion moves running execution state with a brief switchover that must satisfy application requirements.
• Storage vMotion changes datastore placement and can perform supported disk-format conversions.
• Snapshots depend on their backing storage and do not replace independent backups.
• Snapshot consistency depends on saved memory and supported successful quiescing; consolidation can affect I/O.