Live Migration with vSphere vMotion for Hardware Maintenance

Problem: Maintenance Without Downtime

When an ESXi host needs firmware updates, component replacement, or power cycling, taking the virtual machines offline can disrupt services. vSphere vMotion lets you move a powered‑on VM to another host while it continues to run, eliminating the perceived downtime.

How vMotion Works

vMotion copies a VM’s memory pages over a dedicated VMkernel network while tracking changes with a bitmap. After the bulk copy, the remaining dirty pages are transferred in a brief stop‑copy phase, and the VM resumes execution on the destination host. The process requires compatible CPUs, shared storage, and a low‑latency vMotion network.

Prerequisites and Configuration

1. Ensure both source and destination ESXi hosts run the same vSphere version and have access to the same datastore (VMFS, NFS, or vSAN).
2. Verify CPU compatibility: same vendor and instruction set, or enable Enhanced vMotion Compatibility (EVC) mode to mask newer instructions.
3. Create a VMkernel adapter for vMotion on each host:

   # Example: add a VMkernel port named vmk1 on vSwitch0
   esxcli network ip interface add --interface-name=vmk1 --port-group-name=vMotionPG --mtu=9000
   esxcli network ip interface ipv4 set --interface-name=vmk1 --ipv4=192.168.10.10 --netmask=255.255.255.0 --type=static
   esxcli network ip interface tag add --interface-name=vmk1 --tag=vMotion
   

4. Assign sufficient bandwidth (at least 1 GbE, preferably 10 GbE) and keep latency under ~10 ms round‑trip.

Worked Example: Migrating a Critical Web Tier VM

Assume a web tier VM named web01 runs on esxi01 and you need to perform maintenance on that host.

1. Log in to vCenter Server, select web01, and choose Migrate → Change compute resource only.
2. Pick esxi02 as the destination host and confirm that the vMotion network is selected.
3. Initiate the migration. vCenter shows a progress bar; the bulk copy phase may take several seconds depending on memory size and network speed.
4. When the stop‑copy phase completes, the VM switches to esxi02. You can observe the host change in the VM’s summary tab.
5. After the migration, verify that the web service continues to respond to requests.

Trade‑offs and Limitations

• CPU compatibility: Moving to a host with an older or different CPU generation fails unless EVC mode is enabled, which may hide some CPU features.
• Network isolation: Sharing the vMotion VMkernel adapter with other traffic (e.g., vSAN, management) can cause packet loss and increase migration time or cause timeouts.
• Memory‑intensive workloads: Large VMs may experience longer copy phases, temporarily higher network utilization, and a slightly longer stop‑copy phase.
• Storage latency: If shared storage exhibits high latency, the overall migration duration increases.

Verification and Closing Steps

After the migration, you can confirm success without claiming any specific test results:

• Check the VM’s runtime host in vCenter or via the command line: vim-cmd vmsvc/get.summary and look for the host field.
• Inspect the vmware.log on the destination host for lines containing "Migration completed" (you would see such entries if the migration succeeded).
• Measure downtime from an external client by pinging the VM’s IP address during the migration; a successful vMotion typically shows zero or sub‑second packet loss.
• If you need to roll back, simply migrate the VM back to the original host using the same procedure; this only changes state if you actually perform the reverse migration.

By meeting the CPU, storage, and network prerequisites and following the steps above, you can use vSphere vMotion to perform hardware maintenance with minimal impact on running services.