VMware Virtual Machine Migration and Storage Management

3 Nov 2026, 18:2124 min readby ITYantra Admin

Comprehensive guide to VMware vMotion, Storage vMotion, cross-vCenter migration, and VMFS datastore management.

# VMware Virtual Machine Migration and Storage Management

Introduction

VMware vSphere provides powerful capabilities for moving virtual machines and their storage without downtime. vMotion enables live migration of running VMs between ESXi hosts, while Storage vMotion moves virtual disks between datastores. Cross-vCenter migration allows moving VMs between separate vSphere environments. Combined with VMFS datastore management, these capabilities form the foundation of flexible, resilient virtualized infrastructure.

This tutorial covers vMotion, Storage vMotion, cross-vCenter migration, VMFS datastore creation and management, storage policies, and best practices for VM migration and storage operations in VMware vSphere environments.

By the end of this guide, you will be able to plan and execute VM migrations, manage VMFS datastores, and implement storage policies for optimal performance and availability.

Technical Background

vMotion

vMotion migrates a running VM's memory and execution state from one ESXi host to another with no downtime. Requirements:

Shared storage (both hosts access same datastore)
vMotion-enabled VMkernel interface on each host
Compatible CPU (Enhanced vMotion Compatibility - EVC for mixed CPU generations)
Licensed vSphere edition
Gigabit+ network (10 GbE recommended)

vMotion process: 1. Pre-copy memory pages from source to target 2. Stop-and-copy (brief pause, typically milliseconds) 3. Resume execution on target host

Storage vMotion

Storage vMotion migrates VM files (vmdk, vmx, logs, etc.) from one datastore to another while the VM remains running. Uses Changed Block Tracking (CBT) to copy only changed blocks after initial full copy.

Cross-vCenter Migration

Migrate VMs between vCenter Servers using HCX (Hybrid Cloud Extension) or vSphere Replication, or manually by exporting OVF/OVA and importing on target.

VMFS Datastore

VMFS (VMware File System) is a clustered filesystem allowing multiple ESXi hosts to read/write simultaneously. VMFS 6 (vSphere 6.5+) supports:

Automatic UNMAP (space reclamation)
512e and 4K native disk formats
Concurrent access by up to 64 hosts
Datastore clusters with Storage DRS

Prerequisites

vCenter Server managing ESXi hosts
Shared storage accessible by all hosts (for vMotion)
vMotion VMkernel interfaces configured
Sufficient network bandwidth
VMware licenses for vMotion and Storage vMotion
Datastore space sufficient for destination

Architecture

vMotion Network Path

Source ESXi                      Target ESXi
┌─────────────┐                  ┌─────────────┐
│   VM 100    │──── vMotion ────▶│   VM 100    │
│  (running)  │   Memory copy    │  (running)  │
└──────┬──────┘                  └──────┬──────┘
       │                               │
    vmk0 (vMotion)              vmk0 (vMotion)
       │                               │
    10 GbE Network              10 GbE Network
       │                               │
    Shared Storage              Shared Storage
       │                               │
    VMFS Datastore            VMFS Datastore

graph LR
    subgraph Host_A [ESXi Host A]
        VM_A[VM Running]
        vMotion_A[vMotion VMkernel]
    end
    subgraph Host_B [ESXi Host B]
        VM_B[VM Migrated]
        vMotion_B[vMotion VMkernel]
    end
    subgraph Shared_Storage [VMFS Datastore]
        DS[(VMFS)]
    end
    
    VM_A == Memory Copy == vMotion_A
    vMotion_A == 10GbE Network == vMotion_B
    vMotion_B == VM Resumes == VM_B
    VM_A <== Shared Disk ==> DS
    VM_B <== Shared Disk ==> DS

Storage vMotion Flow

Source Datastore              Target Datastore
┌─────────────┐              ┌─────────────┐
│ VM Files    │──── Copy ────▶│ VM Files    │
│ (.vmdk,     │   (CBT)      │ (.vmdk,     │
│  .vmx, etc) │              │  .vmx, etc) │
└─────────────┘              └─────────────┘
       │                              │
    Same VM running                Same VM running
       │                              │
    Point to source              Point to target
    (during copy)                (after cutover)

Step-by-Step Implementation

Step 1: Configure vMotion VMkernel Interface

**Purpose**: Create dedicated VMkernel interface for vMotion traffic.

**Commands** (ESXi shell):

# List VMkernel interfaces
esxcli network ip interface ipv4 get

# Add vMotion VMkernel interface
esxcli network ip interface ipv4 add --interface-name=vmk1 --ipv4=10.0.1.10 --netmask=255.255.255.0 --type=static

# Enable vMotion on vmk1
esxcli network ip interface tag add --interface-name=vmk1 --tag=vMotion

# Verify
esxcli network ip interface tag list

**Configuration files**: `/etc/vmware/esx.conf` (managed via ESXCLI or vSphere Client)

**Explanation**: vMotion traffic should use a dedicated VMkernel interface on a separate VLAN or physical network for performance and security.

**Expected output**: vmk1 interface active with vMotion tag.

**Verification**:

esxcli network ip interface ipv4 get --interface-name=vmk1
# Shows vmk1 with IP and vMotion enabled

Step 2: Enable Enhanced vMotion Compatibility (EVC)

**Purpose**: Allow vMotion between hosts with different CPU generations.

**Procedure** (vSphere Client):

1. Navigate to Cluster → Configure → VMware EVC 2. Click Edit 3. Select EVC mode (e.g., Intel Meremont, AMD Turin) 4. Enable EVC 5. All hosts in cluster must enter maintenance mode or be rebooted for EVC change

**Explanation**: EVC masks CPU features so all hosts in cluster present a consistent CPU feature set to VMs, enabling vMotion across mixed CPU generations.

**Expected output**: EVC enabled; VMs can vMotion between hosts with different CPUs.

**Verification**:

# vSphere Client shows EVC mode for cluster
# vMotion succeeds between mixed CPU hosts

Step 3: Perform vMotion Migration

**Purpose**: Move running VM from one host to another.

**Procedure** (vSphere Client):

1. Right-click VM → Migrate 2. Select "Change compute resource only" (vMotion) 3. Select destination host 4. Select network (vMotion network) 5. Review and finish 6. Monitor migration progress

**Commands** (via govc or API):

# Using govc VMware CLI
govc host.vmotion -vm /dc1/vm/VM100 -host /dc1/host/ESXi-02

**Expected output**: VM migrated with no downtime; applications continue running.

**Verification**:

# vSphere Client shows VM on new host
# Guest OS uptime unchanged
# Applications continue running

Step 4: Perform Storage vMotion

**Purpose**: Move VM files from one datastore to another while VM is running.

**Procedure** (vSphere Client):

1. Right-click VM → Migrate 2. Select "Change storage only" (Storage vMotion) 3. Select destination datastore 4. Select storage format (thin/thick provisioning) 5. Review and finish 6. Monitor migration progress

**Expected output**: VM disk files moved to target datastore; VM remains running.

**Verification**:

# vSphere Client shows VM files on new datastore
# VM remains running throughout

Step 5: Create VMFS Datastore

**Purpose**: Provision shared storage for VMs.

**Procedure** (vSphere Client):

1. Navigate to Storage → New Datastore 2. Select type: VMFS 3. Select disk/LUN 4. Configure datastore name and VMFS version (VMFS 6) 5. Review and finish

**Commands** (ESXi shell):

# List available storage devices
esxcli storage core device list

# Create VMFS on device (typically done via vSphere Client)
# esxcli storage filesystem add is not directly available; use vmkfstools

**Expected output**: VMFS datastore created and visible to all hosts.

**Verification**:

# vSphere Client shows datastore capacity
# All hosts can access datastore

Step 6: Configure Datastore Cluster with Storage DRS

**Purpose**: Automate storage load balancing across multiple datastores.

**Procedure** (vSphere Client):

1. Right-click datacenter → New Datastore Cluster 2. Add datastores to cluster 3. Enable Storage DRS 4. Configure automation level (Manual/Automated) 5. Configure space utilization threshold

**Explanation**: Storage DRS balances VM disk placement across datastores based on space usage and I/O latency.

**Expected output**: Datastore cluster created; Storage DRS recommendations generated.

**Verification**:

# vSphere Client shows datastore cluster
# Storage DRS recommendations visible

Step 7: Configure Storage Policies (VM Storage Policies)

**Purpose**: Define storage requirements for VMs (replication, encryption, caching).

**Procedure** (vSphere Client):

1. Navigate to Policies and Profiles → VM Storage Policies 2. Create new storage policy 3. Enable capabilities (encryption, replication, caching) 4. Apply policy to VM

**Expected output**: Storage policy applied; VM placed on compliant datastore.

**Verification**:

# vSphere Client shows VM storage policy compliance
# VM datastore matches policy requirements

Configuration Examples

vMotion VMkernel Configuration

# Enable vMotion on vmk1
esxcli network ip interface add --interface-name=vmk1 --ipv4=10.0.1.10 --netmask=255.255.255.0 --type=static
esxcli network ip interface tag add --interface-name=vmk1 --tag=vMotion

# Verify vMotion enabled
esxcli network ip interface tag list | grep vMotion
# vmk1: vMotion

Datastore Creation (vmkfstools)

# Format device with VMFS (typically via vSphere Client)
vmkfstools -C vmfs6 -S "VMFS-Datastore-01" /vmfs/devices/disks/naa.xxx

# Verify
esxcli storage filesystem list | grep VMFS-Datastore-01

Storage vMotion CLI (govc)

# Storage vMotion VM to different datastore
govc vm.storage -vm /dc1/vm/VM100 -ds /dc1/datastore/VMFS-02

# Move specific disk
govc vm.change -vm /dc1/vm/VM100 -disk.name scsi0:0 -ds /dc1/datastore/VMFS-02

Cross-vCenter Migration (OVF Export/Import)

# Export VM as OVF from source vCenter
govc vm.export -f /tmp/vm100.ovf /dc1/vm/VM100

# Import OVF to target vCenter
govc import.ova -f /tmp/vm100.ova /dc2/host/Cluster-01

VMFS Datastore Growth

# Expand VMFS datastore after LUN expansion
# Via vSphere Client: Datastore → Increase Capacity
# Or ESXi shell:
esxcli storage filesystem snapshot --datastore-name=VMFS-01 --expand

Verification

vMotion Verification

# Check vMotion compatibility
esxcli network ip interface tag list | grep vMotion
# Check VMotion status on host
vim-cmd vmsvc/getallvms | grep VM100
# Monitor task in vSphere Client Tasks panel

Storage vMotion Verification

# Verify VM files location
ls /vmfs/volumes/VMFS-Datastore-01/VM100/
# Should show .vmdk, .vmx, .log, etc.

Datastore Health Verification

# ESXi shell
esxcli storage filesystem list
esxcli storage core device list
esxcli storage core path list

Expected Results

vMotion completes with no application downtime
Storage vMotion moves all VM files to target datastore
VMFS datastores accessible by all cluster hosts
Storage DRS recommendations generated for datastore cluster
Storage policies compliant

Troubleshooting

| Symptom | Possible Cause | Diagnostic Command | Corrective Action | Verification | |---------|---------------|-------------------|-------------------|--------------| | vMotion not available | vMotion VMkernel not enabled | `esxcli network ip interface tag list` | Enable vMotion on vmk interface | vMotion tag present | | vMotion fails - CPU incompatibility | Different CPU generations | vSphere Client cluster config | Enable EVC mode | vMotion succeeds | | Storage vMotion fails | Insufficient destination space | vSphere Client datastore view | Free space or add storage | Migration succeeds | | vMotion slow | 1 GbE network or congested | `esxcli network nic list` | Upgrade to 10 GbE vMotion network | Faster migration | | Datastore not visible | LUN not zoned or HBA issue | `esxcli storage core device list` | Fix zoning; rescan storage | Datastore appears | | VM locked | Another operation in progress | vSphere Client Tasks | Wait or cancel operation | VM unlocked | | Cross-vCenter migration fails | Version mismatch | vCenter versions | Upgrade to compatible versions | Migration works | | Datastore full | Too many VMs or large files | `df -h` on datastore | Add storage; move VMs | Space available | | Storage DRS not running | DRS disabled or manual mode | vSphere Client datastore cluster | Enable Storage DRS automated | Recommendations appear |

Best Practices

1. **Use dedicated 10 GbE vMotion network**: Provides sufficient bandwidth and isolates vMotion traffic. 2. **Enable EVC in mixed CPU clusters**: Allows vMotion across different CPU generations. 3. **Test vMotion during maintenance**: Verify vMotion works before production reliance. 4. **Use Storage vMotion for maintenance**: Move VMs off datastores during storage array maintenance. 5. **Monitor datastore capacity**: Alert at 75% and 85% utilization. 6. **Use VMFS 6**: Supports automatic UNMAP and 4K native devices. 7. **Separate vMotion and management networks**: Prevents vMotion traffic from affecting management. 8. **Use datastore clusters with Storage DRS**: Automates storage load balancing. 9. **Test cross-vCenter migration**: Verify inter-vCenter migration procedures before need. 10. **Document migration procedures**: Record steps for planned and emergency migrations.

Conclusion

VMware vMotion and Storage vMotion provide non-disruptive VM mobility for maintenance, load balancing, and disaster avoidance. Combined with VMFS datastores, datastore clusters, and storage policies, these capabilities enable flexible, resilient virtualized infrastructure. Proper network design, CPU compatibility, and storage capacity planning are essential for successful migration operations. Regular testing of migration procedures ensures readiness when migrations are needed.

References

VMware vMotion Documentation (https://docs.vmware.com/en/VMware-vSphere/)
VMware Storage vMotion Guide (https://docs.vmware.com/)
VMware VMFS Documentation (https://docs.vmware.com/)
VMware Storage DRS Guide (https://docs.vmware.com/)
VMware vSphere Storage Policies (https://docs.vmware.com/)
VMware Cross-vCenter Migration (https://docs.vmware.com/)

#vmware#vmotion#storage-vmotion#migration#datastore#vmfs#virtualization#vsphere