VMware ESXi and vSphere Cluster Management

vSphere Storage vMotion Explained: Live Virtual Machine Storage Migration

Learn how vSphere Storage vMotion moves powered-on VM files between datastores, including requirements, disk formats, limitations, workflow, and verification.

What Storage vMotion Does

Storage vMotion is a live migration capability in VMware vSphere. It relocates a powered-on virtual machine's storage files from one datastore to another while the VM continues running.

The VM remains on its current ESXi host, the VMware hypervisor server where its compute execution is taking place. During the operation, vSphere copies and tracks storage changes so that the VM can continue serving users and applications. Service availability is intended to continue, although the migration can still affect storage performance.

A datastore is a vSphere storage container that holds VM configuration files, virtual disks, snapshots, and related files. Storage vMotion changes the datastore placement of those files without moving the VM's execution to another host.

Storage vMotion Versus vMotion

vMotion is live migration of a running VM's compute execution from one ESXi host to another. In a normal vMotion operation, the VM usually continues using the same datastore.

Storage vMotion does the opposite: it changes the VM's datastore placement while retaining its current ESXi host. Depending on the vSphere environment and the migration type selected, a migration workflow can offer compute migration, storage migration, or both.

Capability	What moves	Does the ESXi host change?	Does the datastore change?	Typical use case
vMotion	Running VM compute execution and memory state	Yes	Normally no	Host maintenance, workload balancing, or host evacuation
Storage vMotion	VM storage files and virtual disks	No	Yes	Datastore maintenance, capacity balancing, or storage modernization
Combined migration	Compute execution and storage placement	Yes	Yes	Moving a VM to a different host and datastore in one workflow when supported

What Files Are Migrated?

Storage vMotion can relocate the files that make up a VM's storage and configuration, including:

Virtual disk files: VMDK files contain the VM's virtual disks.
Virtual machine configuration files: These describe the VM's virtual hardware and settings.
Snapshot-related files: Snapshots can create additional disk-state files that must be considered during migration.
NVRAM files: An NVRAM file stores virtual firmware settings.

When files are created at the destination, their names are aligned with the VM's inventory name. This destination naming behavior is automatic and cannot be disabled. File-based procedures, scripts, monitoring rules, and backup documentation should account for that behavior.

Common Use Cases

Evacuating a Datastore for Maintenance

Before storage-array maintenance, reconfiguration, or retirement, administrators can move powered-on VMs away from the affected datastore. The VM remains available on its current host while its files are relocated to a replacement datastore, avoiding planned VM downtime when the environment supports the operation.

Balancing Capacity and Performance

If one datastore is nearing capacity while another has suitable free space, Storage vMotion can redistribute complete VMs or selected virtual disks. This can reduce capacity pressure and help place workloads on storage with appropriate performance characteristics.

Modernizing Datastores

Storage vMotion can help move workloads from an older datastore format or storage platform to a newer supported destination. Compatibility must be checked first; not every source-to-destination combination is supported.

Separating Virtual Disks

Individual disks can sometimes be placed on different datastores. For example, an operating-system disk might use general-purpose storage while a database data disk uses higher-performance storage. Separate placement can also support different capacity, protection, or operational requirements.

Prerequisites and Migration Requirements

Requirement	Why it matters	How to validate	Effect if unmet
Host access to both datastores	The current ESXi host must read the source and write to the destination.	Check host-level datastore visibility, mount status, paths, and connectivity.	The destination may be unavailable or compatibility checks may fail.
Feature entitlement	The deployed vSphere edition and licensing must include Storage vMotion.	Review the assigned license and product capabilities for the environment.	The operation may not be available.
Eligible virtual disks	Disk mode and storage type affect whether a disk can be relocated.	Review disk modes, RDM configuration, snapshots, and migration checks.	Some disks may be rejected or require special handling.
No active VMware Tools installation	vSphere does not allow Storage vMotion to start while VMware Tools installation is in progress.	Check the VM task and guest operations status.	Wait for the installation to finish.
Compatible datastore and disk sizes	Filesystem versions and virtual disk sizes impose compatibility limits.	Compare source and destination datastore formats and disk sizes.	The migration can be blocked.
Enough destination capacity	The destination must accommodate the selected disk provisioning format and migration overhead.	Review free space, disk sizes, snapshots, and expected allocation.	The task can fail or consume unsafe amounts of free space.
Operationally suitable destination	Visibility alone does not prove that performance, connectivity, or protection is appropriate.	Check storage health, latency, paths, policies, and workload suitability.	The VM may move successfully but perform poorly or violate operational requirements.

Disk Eligibility

Persistent-mode VMDKs, whose changes are retained, are generally eligible when the surrounding datastore and VM configuration meet the requirements. RDM, or Raw Device Mapping, presents a raw storage LUN to a VM rather than using an ordinary VMDK. RDMs have their own compatibility and migration constraints, so each mapping and compatibility result must be reviewed instead of assuming that it behaves like a normal virtual disk.

Also review active snapshots, nonpersistent disk modes, and any other special storage configuration. These can change which files are present and whether a selected migration is allowed.

Important VMFS Compatibility Example

A historical compatibility restriction applies when a virtual disk larger than 2 TB is migrated from a VMFS5 datastore to VMFS3. That path is unsupported. Use a compatible destination rather than attempting to move the large disk to VMFS3.

Virtual Disk Format Conversion

Storage vMotion can relocate a virtual disk and change its provisioning format at the same time. The main formats are:

Disk format	Capacity allocation behavior	Zeroing behavior	Migration conversion option	Operational consideration
Thin Provision	Datastore capacity is consumed as data is written.	Blocks are allocated as needed.	Thick to thin or retention of thin format	Improves initial storage efficiency, but free-space monitoring is essential because growth can exhaust the datastore.
Thick Provision Lazy Zeroed	Full virtual disk capacity is reserved.	Blocks are zeroed on first write.	Thin to lazy-zeroed thick or conversion from another format	Provides reserved capacity, while first writes to previously unused blocks may require initialization work.
Thick Provision Eager Zeroed	Full virtual disk capacity is reserved.	All blocks are zeroed during creation or conversion.	Thin or lazy-zeroed thick to eager-zeroed thick when supported	Conversion can take longer and create substantial storage activity, but avoids first-write zeroing work later.

A thin-to-thick conversion reserves more datastore capacity. A thick-to-thin conversion can reduce immediately allocated capacity, but it does not remove the need to monitor the thin disk's possible growth. Eager-zeroed thick conversion can require significant time and I/O because the destination blocks are initialized before the disk is ready.

Migration Planning and Validation

Assess both datastores. Check free capacity, storage performance, connectivity, datastore health, protection requirements, and compatibility.
Define the placement goal. Decide whether all VM files should move together or whether selected virtual disks should be assigned to different datastores.
Inspect special conditions. Identify active snapshots, RDMs, nonpersistent or unusual disk modes, large VMDKs, and datastore version limitations.
Estimate temporary demand. Plan for migration read and write activity, destination allocation, snapshot-related space, and storage-network traffic.
Protect production performance. Avoid launching many storage-intensive migrations during peak demand unless capacity and performance headroom have been demonstrated.
Confirm operational controls. Verify backups, monitoring, change-control approval, maintenance windows, and rollback expectations before changing datastore placement.

High-Level Storage vMotion Workflow

Select the powered-on VM in the vSphere management interface.
Start the migration operation.
Choose the storage-only migration option when the goal is to retain the current ESXi host.
Select the destination datastore or datastore cluster placement.
When available, assign individual virtual disks to specific destination datastores.
Select or retain the desired virtual disk provisioning policy: thin, lazy-zeroed thick, or eager-zeroed thick.
Review compatibility checks and the migration summary.
Start the task and monitor its progress.
After completion, verify VM health, file placement, disk placement, capacity consumption, and source cleanup.

vSphere Client workflow
1. Select powered-on VM
2. Choose Migrate
3. Select Change storage only
4. Choose destination datastore(s)
5. Choose disk provisioning format
6. Review compatibility and summary
7. Start and monitor the task
8. Verify VM health and final file locations

Limitations and Operational Cautions

Storage vMotion is a storage relocation mechanism, not a host relocation mechanism. Use vMotion when the goal is to change the ESXi host.
Datastore compatibility can prevent migration, especially when the destination uses an older filesystem version or has constrained virtual disk support.
RDMs, snapshots, nonpersistent disks, and unusual disk modes require eligibility checks and may have special handling requirements.
The destination needs enough space for the selected provisioning format, not merely the amount of guest data currently in use.
Migration traffic can increase storage latency and consume storage-network bandwidth. Monitor source and destination performance during the task.
Current vSphere releases differ in supported datastore types, limits, licensing, and feature behavior. Verify the requirements against the deployed vSphere and ESXi versions.

Post-Migration Verification

Confirm that the task completed without errors or warnings requiring action.
Verify the VM's configuration file and virtual disk files are on the intended destination datastore or datastores.
Confirm the VM remains powered on and that the guest operating system is responsive.
Check application health, guest logs, monitoring alerts, and service availability.
Review storage latency and throughput after the move.
Verify the selected disk provisioning format and compare actual destination capacity consumption with the plan.
Confirm that source datastore files and snapshots are released as expected after the operation completes.

Troubleshooting Common Problems

Destination Cannot Be Selected

Likely causes include the current ESXi host lacking access to the destination, an incompatible datastore or disk requirement, or insufficient free capacity. Check host-level storage visibility and connectivity rather than relying only on what appears in the management inventory. Then verify free space, datastore format, disk sizes, and compatibility results.

Large-Disk Migration Is Rejected

If a VMDK larger than 2 TB is being moved from VMFS5 to VMFS3, the migration path is unsupported. Select a compatible destination datastore instead of VMFS3.

Storage vMotion Cannot Start

Check whether VMware Tools installation is in progress. Allow that task to finish, then review disk mode, RDM configuration, snapshots, and the compatibility messages for other ineligible storage.

Storage Latency Increases

Storage vMotion reads from the source and writes to the destination while the VM continues its normal I/O. Schedule the migration during lower demand, monitor datastore and network metrics, and reduce concurrent storage-intensive operations.

Destination Files Have a Different Name

Storage vMotion automatically aligns destination VM file names with the VM's inventory name. This is expected and cannot be disabled. Update file-based operating procedures if they assumed the original names would remain unchanged.

Practical Examples

Evacuating Storage for Array Maintenance

A production VM runs on an ESXi host that can access both the existing datastore and a replacement datastore. Start a storage-only migration and place the VM files on the replacement datastore. The VM stays powered on and on the same host while the source storage is evacuated.

Balancing Datastore Capacity

One datastore is nearly full while another has suitable free space and equivalent workload characteristics. Move the entire VM or selected data disks to reduce pressure on the full datastore. Confirm that the destination has enough space for the chosen provisioning format.

Converting Thick to Thin

A VM has a thick-provisioned data disk on a capacity-constrained datastore. During relocation, choose thin provisioning at the destination. This can reduce initially allocated capacity, but monitor datastore free space because the thin disk can grow as the guest writes data.

Rejecting an Incompatible Destination

A VM contains a VMDK larger than 2 TB on VMFS5, and the proposed destination is VMFS3. Do not proceed with that destination. Choose a datastore whose filesystem and disk-size support are compatible with the VMDK.

Key Terms

Storage vMotion: Live migration of a powered-on VM's storage files between datastores.
vMotion: Live migration of a running VM's compute execution between ESXi hosts.
ESXi host: The VMware hypervisor server on which a VM runs.
Datastore: A vSphere storage container for VM files and virtual disks.
VMDK: A VMware virtual machine disk file.
VMFS: VMware Virtual Machine File System datastore format.
Persistent disk mode: A mode in which virtual disk changes are retained.
Snapshot: A point-in-time VM disk state represented by snapshot-related files.
RDM: Raw Device Mapping, which presents a raw storage LUN to a VM.
NVRAM: A VM file that stores virtual firmware settings.

Summary

Storage vMotion moves the files and virtual disks of a powered-on VM between datastores while the VM remains on its current ESXi host. It is useful for datastore maintenance, capacity and performance balancing, storage modernization, and deliberate virtual disk placement.

Successful migrations depend on host access to both datastores, licensing, disk eligibility, free capacity, datastore and VMFS compatibility, and careful performance planning. Treat compatibility checks as mandatory, especially for RDMs, snapshots, special disk modes, large VMDKs, and older datastore formats. Afterward, verify task status, file locations, guest and application health, provisioning format, capacity use, and source cleanup.

For the related compute-migration concept, see vSphere Storage vMotion Explained.