Using vSphere vMotion for Zero‑Downtime Host Maintenance

Problem: Needing to service ESXi hosts without stopping workloads

During a scheduled firmware upgrade, the operations team must evacuate running virtual machines from a host. Powering off VMs is unacceptable for latency‑sensitive services, and manual migration scripts are error‑prone. The goal is to move each VM to another host while it remains powered on, verify the move succeeded, and then proceed with the host maintenance.

Thesis: vSphere vMotion provides a supported, zero‑downtime path when its prerequisites are met

vMotion copies a VM’s active memory and device state over a dedicated VMkernel network, then pauses the VM for a brief quiesce (typically under 200 ms) to sync the final memory bitmap and switch execution to the destination host. If the environment satisfies CPU compatibility, shared storage, and network requirements, the migration appears seamless to most workloads.

Section 1: Core prerequisites

• CPU compatibility: Source and destination hosts must expose the same CPU feature set. If they differ, enable Enhanced vMotion Compatibility (EVC) at the cluster level to mask the differences.
• Shared storage: The VM’s virtual disks must reside on a datastore accessible from both hosts (VMFS, NFS, vSAN, or vVOLs). Verify with esxcli storage core device list that the same LUN appears on each host.
• vMotion VMkernel network: Create a VMkernel adapter tagged for vMotion, preferably on a 10 GbE or faster link, isolated from other traffic. Enable jumbo frames (MTU 9000) on the physical switches and the VMkernel adapter to reduce packet loss.

Section 2: Worked example – migrating a test VM

Assume a vCenter Server at vc01.example.com, a datacenter DC01, and a cluster CLUST01 with two hosts esxi01 and esxi02. The VM to move is named web01.

1. Verify vMotion VMkernel adapter (run on each host with root privileges):

   esxcli network ip interface list | grep vmk
   # Look for an interface, e.g., vmk2, with the vMotion tag
   esxcli network ip interface tag add -i vmk2 -t vMotion
   

2. Check shared storage visibility:

   esxcli storage core device list | grep -A2 "naa."
   # Ensure the same naa. ID appears on both hosts

3. Perform the migration via the vCenter GUI (requires the "Virtual machine > Migration > Migrate" privilege):
   1. Locate web01 in the inventory, right‑click → Migrate.
   2. Select "Change compute resource only" and choose esxi02 as the destination host.
   3. Leave the storage selection unchanged (shared datastore).
   4. Finish the wizard; vCenter creates a vMotion task.
4. Confirm completion via command line (optional, requires read‑only access):

   # Get the VMID
   vim-cmd vmsvc/getallvms | grep web01
   # Suppose the VMID is 42
   vim-cmd vmsvc/power.getstate 42   # Should show "Powered on" before and after
   # Monitor the task
   vim-cmd vmsvc/task/list | grep vMotion
   

5. Practical verification: After the task completes, check /var/log/vmkernel.log on both hosts for lines like "Completed migration of VM web01" and note the reported quiesce time (should be < 200 ms).

Section 3: Trade‑offs and limitations

• Quiesce latency: The brief pause can be noticed by ultra‑low‑latency applications (e.g., high‑frequency trading). Test with a representative workload if latency tolerances are tight.
• Incompatible devices: VMs using USB passthrough, direct‑path I/O, or certain GPUs cannot be vMotion‑ed unless the destination host provides identical hardware or the device is disabled before migration.
• EVC baseline: If the cluster’s EVC mode is set to a newer CPU generation than the oldest host in the cluster, some VMs may fail to power on after migration. Verify the baseline matches the lowest CPU you intend to support (vim-cmd hostsvc/evc/evc_state).
• Network bandwidth: Saturated vMotion links cause packet loss and migration failures. Monitor utilization (esxcli network ip interface ipv4 get -i vmk2) and consider dedicating a separate 10 GbE+ link or using Network I/O Control to reserve bandwidth.

Actionable closing: Add vMotion validation to your runbook

1. During host‑maintenance planning, run the prerequisite checks (CPU, storage, VMkernel adapter) on both source and target hosts.
2. Select a low‑risk VM (e.g., a test web server) for a trial vMotion and record the quiesce time from the logs.
3. If the trial succeeds, proceed with the production VMs using the same procedure.
4. After maintenance, run a reverse vMotion to return VMs to the original host, confirming bidirectional mobility.
5. Document any observed latency impact and adjust application tolerance thresholds accordingly.

By following these steps, you can confidently use vSphere vMotion to keep services running while you service the underlying hardware.