VMware ESXi and vSphere Cluster Management
Use vSphere Storage vMotion to Move Virtual Machine Files Between Datastores
Learn how to use vSphere Storage vMotion to move a running VM's disks and configuration files between datastores, choose disk formats, verify results, and troubleshoot failures.
Storage vMotion is vSphere's live storage migration feature. It moves a virtual machine's storage files to another datastore while the guest operating system and applications can remain online. The VM continues to run on its current ESXi host, which is the hypervisor server that executes virtual machines.
A datastore is a vSphere storage container backed by a supported storage type. It holds VM files, while the ESXi host supplies compute resources such as CPU and memory. Storage vMotion changes the storage location; it does not primarily change the host running the VM.
What Storage vMotion Moves
A virtual machine's VM home is the datastore location containing its configuration and associated files. Depending on the selected workflow and placement choices, Storage vMotion can move:
- Virtual disk files, commonly represented by VMDK files.
- VM configuration and metadata files.
- Snapshot files and their dependent delta disks.
- Virtual machine swap files.
- Other related VM home files, logs, and auxiliary files where applicable.
A virtual disk is a VM disk device represented by one or more files. The wizard can often move all VM files together or place individual virtual disks on separate compatible datastores.
When to Use Storage vMotion
- Move workloads away from a datastore scheduled for maintenance, replacement, retirement, or migration.
- Balance capacity across datastores when one datastore is approaching its usable limit.
- Move a VM or selected disks to a higher-performance or lower-cost storage tier.
- Place disks on storage with a different protection policy or storage technology.
- Change a virtual disk provisioning format during the move when the destination and VM support the conversion.
For example, an application VM can remain powered on while its files move from an aging shared datastore to a newly provisioned datastore. Storage vMotion is not primarily a host migration operation. Use vMotion when the goal is to change the ESXi host while retaining the storage location.
Requirements and Pre-Migration Checks
vCenter Server is the management platform that inventories and orchestrates vSphere resources. The relevant ESXi host and VM should be managed by vCenter Server before starting a Storage vMotion operation.
Migration time depends on virtual disk size, the rate at which the guest changes disk blocks during the operation, datastore performance, and the available network or storage configuration. A running database VM with high write activity can take substantially longer than a lightly used file server of the same nominal size.
Storage vMotion Workflow in the vSphere Client
- Select the target virtual machine in the vSphere inventory.
- Open the Migrate action.
- Choose the migration type that changes storage or datastore placement. Exact labels vary by vSphere version and client interface.
- Select a destination datastore, datastore cluster, or other compatible storage resource.
- Choose a virtual disk format if the interface presents that option.
- Review per-disk placement options if you need to separate an operating system disk and a data disk.
- Use vSphere compatibility checks and placement recommendations, including recommendations from a datastore cluster or Storage DRS where configured.
- Review the migration summary carefully, including destination paths, policies, capacity, and disk formats.
- Submit the task.
- Monitor Recent Tasks, events, and the VM status until the operation completes.
PowerCLI alternative
PowerCLI can initiate a storage relocation with Move-VM. Validate syntax, authentication handling, storage policy parameters, and supported options against the installed PowerCLI and vSphere versions.
Move-VM -VM <VMName> -Datastore <DestinationDatastore>Virtual Disk Provisioning Formats
Provisioning controls how a virtual disk consumes and initializes datastore capacity. Format conversion can be useful during a datastore move, but the choices shown depend on datastore capabilities, policies, VM compatibility, and environment configuration.
For a capacity-constrained datastore, converting a disk to thin provisioning can reduce initial consumption, but it does not remove the need to plan for the disk's possible growth. For a workload requiring reserved capacity, selecting a thick format may be appropriate; confirm that the destination has enough space for the reservation and any other VM files.
Snapshots, Devices, and File Placement
A snapshot records a point-in-time VM disk state and creates dependent delta files. Snapshot chains can increase the amount of data and metadata involved in a migration. Unnecessary snapshots should generally be removed and consolidated before a move, using an operationally safe procedure and confirming that consolidation completes.
Review mounted CD or DVD media, attached devices, raw mappings, encryption settings, and other VM configuration restrictions before migration. Storage policies are sets of placement and capability requirements assigned to VM objects. The destination must satisfy those requirements, or the migration may be blocked or leave the VM noncompliant.
When supported, place the operating system disk and data disks on different datastores. This can distribute performance or protection requirements, but it also means that the VM's files will not all appear in one location. A datastore cluster is a group of datastores managed as a storage resource pool, often with Storage DRS; its recommendations should be reviewed rather than accepted without checking capacity and policy requirements.
Operational Considerations
- Storage vMotion generates storage reads and writes and may generate network traffic. Monitor datastore latency, host resources, storage paths, and guest I/O.
- For high-I/O production systems, schedule the move during a lower-demand period or apply the environment's available migration and resource controls.
- Confirm that encryption requirements are preserved. Encrypted VMs and disks can have additional compatibility or policy constraints.
- Shared datastores are commonly visible to multiple hosts. Local datastores may be visible only to particular hosts, which can restrict later vMotion or failover operations.
- Do not assume that nominal virtual disk size equals actual source capacity consumption, especially for thin disks and snapshot chains.
Verification After Migration
If the VM still appears associated with the original datastore, inspect each virtual disk and the VM home location. Only selected disks may have moved, or VM files may have been intentionally distributed across datastores. Refresh inventory views before drawing conclusions.
Relationship to Other Migration Types
Use enhanced vMotion concepts when a supported workflow must change both host and storage. A cold migration is different from live migration because the guest is powered off for the operation.
Troubleshooting Storage vMotion
Destination datastore is unavailable
The current ESXi host may not have access to the datastore, the datastore may conflict with the VM's policy or encryption state, or the account may lack datastore allocation privileges. Verify storage presentation and connectivity, compatibility results, storage policies, encryption constraints, and permissions.
Compatibility check fails
Read the specific compatibility message. Common causes include insufficient free space, unsupported disks or devices, policy conflicts, snapshots, encryption constraints, and datastore capability limitations. Correct the listed constraint or select another compatible destination.
Migration progresses slowly
Large disks, high guest write rates, congested storage paths, datastore latency, and snapshot chains can all increase migration time. Review host, datastore, and guest I/O metrics, reduce competing activity where safe, assess snapshot state, and schedule the operation during a lower-demand window.
Destination runs out of space
Capacity planning may have omitted snapshots, metadata, overhead, disk provisioning choices, or concurrent guest growth. Thin-provisioned source disks can have significant actual consumption. Provide more headroom, choose another datastore, reassess the format, and include all VM files in the calculation.
Source datastore still contains VM files
Only selected disks may have moved, or the VM home and disks may have been intentionally placed separately. Inspect storage settings and datastore file listings for every disk, snapshot, swap file, and VM home file. Refresh the inventory view and do not delete source files until the VM no longer references them.
Practical Migration Examples
- Datastore maintenance: Move a running application VM from an aging shared datastore to a new datastore, then verify that the source no longer contains referenced VM files.
- Capacity reclamation: Relocate a VM from an almost-full datastore to one with sufficient free capacity. Select thin provisioning only when it matches the organization's capacity-management policy.
- Storage tier change: Move database disks to a higher-performance datastore, keep the guest available, and validate application latency after completion.
- Disk format conversion: Select a thick format during the move for a workload requiring reserved capacity, then confirm destination consumption matches expectations.
- Separate VM files: Place the operating system disk and data disk on different compatible datastores when the design and wizard options support per-disk placement.
Related Learning
Review browsing VMFS datastores for file-location checks, consolidating snapshots before a move, and assigning permissions for migration access. For storage policy and automated placement planning, study DRS automation levels and the related datastore-cluster features in your environment.