How to Migrate a Virtual Machine in vSphere

🔍 New to vMotion? Before following these steps, read What is vMotion? for a full explanation of how it works and what the requirements are.

This guide covers how to perform a live VM migration (vMotion) using the vSphere Client. It assumes your environment meets the prerequisites — shared storage, a vMotion VMkernel network on both hosts, and CPU compatibility.

Before You Begin

Run through this checklist before initiating any migration:

Confirm both source and destination hosts are in the same vCenter cluster
Verify the destination host has sufficient free CPU and memory for the VM
Confirm the destination host can access the same datastore the VM is on
Check that no unsupported devices are connected to the VM (physical CD-ROM, USB passthrough)
Confirm vMotion VMkernel is enabled on both hosts: Host → Configure → VMkernel Adapters
For production/critical VMs — notify relevant teams and log a change ticket before proceeding

Step 1 — Log into vSphere Client

Open your browser and navigate to:

https://vcenter.casino.local

Step 2 — Locate the VM

In the left-hand inventory panel:

Click Hosts and Clusters or use the search bar at the top
Expand your datacenter → cluster → source host
Right-click the VM you want to migrate

Step 3 — Launch the Migrate Wizard

From the right-click context menu, select Migrate...

The Migrate Virtual Machine wizard opens. You'll be presented with migration type options.

Step 4 — Select Migration Type

Choose the appropriate migration type based on what you're moving:

Option	Use When
Change compute resource only	Moving to a different host, same datastore (standard vMotion)
Change storage only	Moving VMDKs to a different datastore, same host (Storage vMotion)
Change both compute resource and storage	Moving host AND datastore simultaneously

For a standard host-to-host vMotion, select Change compute resource only and click Next.

Step 5 — Select Destination Host

The wizard shows your cluster hosts with their current resource usage. Select the destination host.

Tips:

Hover over each host to see CPU and memory utilization
Hosts showing warnings or in maintenance mode will be highlighted — avoid these
vCenter will show a compatibility check — resolve any errors before continuing

Click Next.

Step 6 — Select vMotion Network

Select the network to use for the vMotion migration traffic. This should be your dedicated vMotion VMkernel network, not the VM or management network.

If only one network appears, it's already selected. Click Next.

Step 7 — Select VM Disk Format (Storage vMotion only)

If you chose to also move storage, you'll be prompted to select the disk format for the destination:

Format	Use Case
Same format as source	Default — keeps existing format
Thin Provision	Saves space — allocates on demand
Thick Provision Lazy Zeroed	Pre-allocated, zeroed on first write
Thick Provision Eager Zeroed	Pre-allocated, pre-zeroed — best for latency-sensitive workloads

For most migrations, Same format as source is the correct choice.

Step 8 — Select Migration Priority

Choose the vMotion priority:

Priority	Behavior
Schedule vMotion with high priority	Reserves CPU on both hosts for the migration — faster, but uses more resources
Schedule normal vMotion	Lower resource reservation — may take longer but less impact on running workloads

For production migrations during business hours, use normal priority to avoid impacting other VMs. For maintenance window migrations where speed matters, use high priority.

Step 9 — Review and Finish

The wizard displays a summary of all your selections:

Source host
Destination host
VM disk location
Network selection
Priority

Review everything carefully. If anything looks wrong, click Back to correct it.

When satisfied, click Finish to start the migration.

Step 10 — Monitor the Migration

The migration task appears in the Recent Tasks pane at the bottom of the vSphere Client. You can also monitor it from:

A typical vMotion for a lightly loaded VM completes in 30–120 seconds depending on memory size and network speed. Heavily loaded VMs with large working sets take longer.

Verifying Success

After the task completes:

Click on the VM in inventory — the Summary tab should show the new host under Host
Verify the VM is still running: power state should show Powered On
Ping the VM or test its application to confirm network connectivity was maintained
Check Recent Tasks — the vMotion task should show Completed status

Troubleshooting Common Issues

Error	Likely Cause	Fix
`Compatibility check failed`	CPU features mismatch	Enable EVC on the cluster, or choose a host with compatible CPUs
`A general system error occurred`	vMotion network misconfigured	Verify VMkernel vMotion tag on both hosts
`Not enough resources`	Destination host is at capacity	Free up resources on destination or choose a different host
`The VM has a device that prevents migration`	Physical CD-ROM, USB passthrough attached	Disconnect the device and retry
`Migration network not found`	No vMotion VMkernel on destination	Add and tag VMkernel adapter for vMotion on destination host

Notes for the Casino Environment

Critical VMs (SQL01, HORIZON01, CAMSVR01) — always log a change ticket and notify the relevant team before migrating
Slot Management SQL cluster — migrate the secondary replica first, then fail over before migrating the primary to avoid AG disruption
Never migrate during peak floor hours (Friday 6 PM – Monday 6 AM) unless it's an emergency
After any migration, verify LogicMonitor is still showing the VM as monitored under the correct host

🔍 Want to understand the technology behind this? Read What is vMotion?