VMware ESXi and vSphere Cluster Management
vSphere Storage vMotion Explained
Learn how vSphere Storage vMotion moves powered-on VM files between datastores, including use cases, requirements, disk conversions, restrictions, and validation steps.
What Is vSphere Storage vMotion?
vSphere Storage vMotion is a live migration capability that relocates a powered-on virtual machine's storage files from one datastore to another without interrupting the virtual machine. A datastore is a vSphere storage container that holds VM files, while an ESXi host is the hypervisor on which the VM executes.
During a storage-only migration, the VM remains powered on and continues running. Its virtual disks and other files are moved to the destination datastore, but the VM's active execution location does not change. In other words, Storage vMotion moves storage, not compute execution.
Storage vMotion Compared with vSphere vMotion
vSphere vMotion moves a running VM's execution from one ESXi host to another. Storage vMotion moves the VM's files between datastores while keeping the VM on its current host. These capabilities address different migration dimensions: compute location versus storage location.
| Migration type | What moves | Does the VM remain powered on? | Does the VM remain on the same ESXi host? |
|---|---|---|---|
| vSphere vMotion | The VM's active execution location moves between ESXi hosts. | Yes, when the migration requirements are met. | No. The destination host becomes the execution location. |
| Storage vMotion | VM storage files move between datastores. | Yes. | Yes. The current ESXi host continues running the VM. |
For example, use standard vMotion when an ESXi host needs maintenance and the VM must run elsewhere. Use Storage vMotion when storage needs maintenance or redistribution but the VM can continue running on its current host.
For related host-migration concepts, review Enhanced vMotion Explained and CPU Compatibility for vMotion.
Common Storage vMotion Use Cases
| Use case | Migration goal | Expected operational result |
|---|---|---|
| Storage maintenance | Evacuate VM files from a storage device or datastore before maintenance or reconfiguration. | The original storage can be serviced without shutting down the VM. |
| Storage load redistribution | Spread VMs or individual virtual disks across storage volumes. | Capacity usage and storage workload are distributed more evenly. |
| Datastore upgrade | Move VMs while transitioning between datastore formats, such as the historical VMFS2-to-VMFS5 example. | VM files are placed on the selected datastore format without planned VM downtime. |
Evacuating Storage for Maintenance
Suppose a running application VM uses a datastore on an array that requires reconfiguration. Storage vMotion can move the VM's files to another reachable datastore. Once the migration completes, the original storage can be taken out of service while the application VM remains powered on.
Balancing Capacity and Storage Workload
If one datastore has high demand or limited free capacity, move one or more VMs, or selected virtual disks, to a less-utilized datastore. This can improve capacity distribution and may help distribute storage activity. Capacity balancing does not automatically guarantee better application performance; the destination must also provide suitable storage resources.
Changing Datastore Format
Storage vMotion can help relocate VMs when an environment transitions between datastore formats. Compatibility must be checked before selecting the destination, especially when VMFS versions and virtual disk sizes are involved.
Which VM Files Are Affected?
A Storage vMotion operation can affect the VM files stored with the VM, including:
- Virtual disk files: VMDK files that contain the VM's virtual disks.
- Virtual machine configuration files: Files that describe the VM's virtual hardware and settings.
- Snapshot-related files: Files associated with the VM's snapshot state.
- NVRAM files: Files that store firmware-related settings.
At the destination, file names are changed to match the VM's inventory name. This destination-side renaming behavior applies during the migration and cannot be disabled.
The rename behavior is separate from the VM's identity and inventory placement. The important operational result is that the VM continues to be managed as the same inventory object while its files are relocated and named according to the destination convention.
Changing Virtual Disk Provisioning During Migration
Storage vMotion can relocate a virtual disk while changing its provisioning format. Thin provisioning consumes datastore capacity as disk blocks are used. A thick-provisioned lazy-zeroed disk allocates its space when created and zeroes blocks on first write. A thick-provisioned eager-zeroed disk allocates and zeroes its space when created.
| Source disk provisioning | Destination disk provisioning | Typical purpose |
|---|---|---|
| Thick provision lazy zeroed | Thin provisioned | Reclaim or reduce initially consumed datastore capacity when thin provisioning is appropriate. |
| Thick provision eager zeroed | Thin provisioned | Change a preallocated disk to capacity-on-use storage when the workload does not require the original thick format. |
| Thin provisioned | Thick provision lazy zeroed | Prepare a disk for a workload or operational policy that requires thick allocation. |
| Thin provisioned | Thick provision eager zeroed | Prepare a disk for a workload with eager-zeroed thick-disk requirements. |
Choose a conversion only after considering capacity, workload requirements, and destination free space. Converting a thick disk to thin can reduce initially consumed capacity, but the disk may grow as the guest uses additional blocks. Converting to thick provisioning requires enough destination capacity for the allocated disk, and eager-zeroed thick conversion also requires the destination to perform the zeroing operation.
For additional disk-capacity concepts, see Inflate Thin Disk and Dynamically Increase Virtual Disks Size.
Storage vMotion Requirements and Restrictions
Validate every requirement before starting. A migration can remain unavailable even when the VM is powered on and both datastores appear in the vSphere inventory.
| Requirement or restriction | Reason or effect | Validation action |
|---|---|---|
| The current ESXi host must access both source and destination datastores. | The host must read the source files and write or place them on the destination. | Confirm that the VM's current host sees both datastores and that the destination is mounted and reachable. |
| The host running the VM must have licensing that includes Storage vMotion. | Without the required entitlement, the operation may be unavailable or fail. | Review the vSphere license assigned to the host or applicable cluster. |
| VMDKs must use persistent disk mode, or the VM disks must be raw device mappings. | Noneligible disk modes cannot participate in the described operation. | Review each virtual disk's mode and identify any RDM usage. |
| VMware Tools installation must not be in progress. | The migration is blocked while VMware Tools installation activity is occurring. | Wait for the installation to complete before retrying. |
| A virtual disk larger than 2 TB cannot move from VMFS5 to VMFS3. | The VMFS3 destination is not supported for that migration direction and disk size. | Check source and destination VMFS versions and compare them with every virtual disk size. |
Persistent disk mode is the required VMDK mode for the described Storage vMotion operation. A Raw Device Mapping (RDM) maps a VM to a raw storage device and is included as an allowed disk type. Review RDM details before migration because an RDM is not the same as an ordinary VMDK file.
See Raw Device Mapping (RDM) for related storage concepts.
Pre-Migration Planning and Validation
- Identify the current host. Determine which ESXi host is currently running the VM. Storage access must be validated from that host, not merely from another host in the cluster.
- Confirm destination reachability. Verify that the current host can access both the source datastore and the proposed destination datastore.
- Check destination capacity. Ensure the destination has enough space for the files being moved and for the selected provisioning format. A thick destination may require more immediately allocated capacity than a thin destination.
- Review virtual disk modes. Confirm that VMDKs use persistent disk mode and identify whether any disks are RDMs.
- Check VMware Tools activity. Make sure a VMware Tools installation is not currently running.
- Compare datastore versions. Check source and destination VMFS versions when compatibility or the greater-than-2-TB restriction could apply.
- Verify licensing. Confirm that the required vSphere license capability is available for the host running the VM.
- Choose the provisioning result deliberately. If changing from thick to thin or thin to thick, verify that the target capacity and workload requirements support the selected result.
Datastore visibility is a practical prerequisite for many migrations. You can review datastore contents and placement concepts with Browse VMFS Datastores.
What Happens Operationally?
Storage vMotion transfers the VM's storage representation to the destination while the guest continues to run. The migration must account for changes made to active files while the VM is powered on, then complete the storage transition so the VM uses the destination copy.
When the operation succeeds, the VM remains powered on, its storage resides on the destination datastore, and its execution remains on the same ESXi host. A storage-only migration does not itself relocate the VM to another ESXi host. If both compute and storage locations must change, the required migration design may involve vMotion together with Storage vMotion, subject to the applicable compatibility and licensing requirements.
Troubleshooting Storage vMotion
Destination Datastore Is Unavailable
Symptom: The migration cannot start because the destination datastore is unavailable.
Likely cause: The ESXi host currently running the VM does not have access to both datastores.
Resolution: Present, mount, or otherwise make the destination datastore accessible to the current host, then validate access again before retrying.
Storage vMotion Is Unavailable Because of Entitlement
Symptom: Storage vMotion is unavailable or fails due to licensing.
Likely cause: The host running the VM is not licensed for the Storage vMotion capability.
Resolution: Confirm that the applied vSphere licensing includes Storage vMotion.
Migration Is Blocked While the VM Runs
Symptom: The VM is powered on, but migration is blocked.
Likely cause: VMware Tools installation is in progress.
Resolution: Allow the VMware Tools installation to complete, verify that no installation activity remains, and then start the migration.
Large Disk Cannot Move to an Older VMFS Datastore
Symptom: A large virtual disk cannot be moved to the proposed destination.
Likely cause: The disk is larger than 2 TB and the migration is from VMFS5 to VMFS3.
Resolution: Select a compatible destination datastore rather than VMFS3, and verify the datastore versions before attempting the operation again.
Virtual Disks Are Not Eligible
Symptom: The VM's disks are not eligible for the intended migration.
Likely cause: The VMDKs are not in persistent mode and are not represented as RDMs.
Resolution: Review the disk configuration and use an eligible disk configuration before migration.
Exam-Relevant Summary
- Storage vMotion moves a powered-on VM's storage files between datastores without interrupting the VM.
- The VM remains on its current ESXi host; Storage vMotion does not move the VM's active execution location.
- Standard vMotion changes the ESXi host on which a running VM executes.
- Storage vMotion can relocate configuration, virtual disk, snapshot-related, and NVRAM files.
- Destination file names are changed to match the VM inventory name, and this renaming cannot be disabled.
- Provisioning conversions can include thick lazy-zeroed to thin, thick eager-zeroed to thin, and thin to either thick format.
- The current host must access both datastores, have the required Storage vMotion license, and use eligible persistent VMDKs or RDMs.
- VMware Tools installation activity blocks the described migration.
- A virtual disk larger than 2 TB cannot move from VMFS5 to VMFS3.