VMware ESXi and vSphere Cluster Management

Use vSphere Storage vMotion to Migrate Virtual Machine Files Between Datastores

Learn how to use vSphere Storage vMotion to move VM files between datastores with minimal downtime, including prerequisites, disk formats, monitoring, verification, and troubleshooting.

What Storage vMotion Does

Storage vMotion is a vSphere capability that relocates a virtual machine's storage files from one datastore to another. A datastore is a logical storage container presented to ESXi hosts for virtual machine files.

In supported environments, Storage vMotion can move an eligible virtual machine while it remains powered on. This makes it useful when you need to relieve capacity pressure, change storage performance tiers, evacuate a datastore, or satisfy a storage policy without scheduling a guest operating system shutdown.

Storage vMotion changes storage placement; it does not normally change the ESXi host running the VM. By contrast, vMotion moves a running VM's compute execution from one ESXi host to another. A cold migration is performed while the VM is powered off and can include moving its compute location, storage, or both.

Migration method	Primary change	Typical VM power state	Does compute host change?	Does datastore change?	Common use case
Storage vMotion	VM storage files	Powered on when supported	Normally no	Yes	Move a workload to another storage tier
vMotion	VM compute execution	Powered on	Yes	Normally no	Balance workloads across ESXi hosts
Cold migration	Compute, storage, or both	Powered off	Optional	Optional	Move a VM when online migration is unavailable

Which VM Files Are Moved?

The primary storage objects are virtual disk files, commonly called VMDK files. A VMDK represents a VM's virtual hard drive. A VM can have several virtual disks, and the migration wizard may allow each disk to be assigned to a different destination datastore.

Depending on the VM configuration and current activity, the migration can also involve supporting files such as:

VMX: the virtual machine configuration file.
NVRAM: firmware state used by configurations such as UEFI.
Log files: diagnostic and runtime logs associated with the VM.
Snapshot files: delta disks and snapshot metadata. Snapshots can substantially affect the amount of data and space involved.
Swap-related files: VM swap files, where the configuration places them with the VM or otherwise includes them in the relocation.

Do not assume that every file is stored in the same folder or datastore. Review the VM's storage layout and use the advanced placement options when the environment supports per-disk placement.

Prerequisites and Compatibility Checks

Perform validation before opening the migration wizard. Storage vMotion depends on vCenter Server, ESXi host access, permissions, licensing, VM configuration, storage connectivity, and vSphere version support.

Check	Why it matters	How to validate	Example issue if not satisfied
vCenter access and permissions	The task must be initiated and authorized centrally	Sign in to vCenter Server and review the user's VM migration and datastore privileges	The wizard is unavailable or submission is denied
Source and destination visibility	The relevant ESXi host must be able to access the destination	Check datastore mounts and host visibility in the vSphere Client	The destination datastore does not appear
Free capacity	Space may be needed for disks, snapshots, conversion overhead, and headroom	Compare required files and expected growth with usable datastore capacity	The task fails during copy or commit
Datastore health	Connectivity and storage status affect reliability	Review alarms, paths, latency, maintenance status, and accessibility	Migration pauses or fails because of storage errors
Storage policy	The destination must satisfy required placement and protection rules	Check VM policy compliance and destination compatibility	The VM becomes noncompliant after migration
VM configuration	Special devices and disk types can limit migration choices	Review snapshots, RDMs, shared disks, encryption, replication, and backup activity	Online storage migration is rejected
Feature and licensing support	Available migration combinations differ by vSphere edition and version	Review the environment's licensed features and compatibility checks	Storage-only migration cannot be selected

A powered-off VM can usually be moved through a cold migration, but an online relocation is specifically the Storage vMotion use case. Licensing, vSphere version, cluster configuration, storage type, and the combination of source and destination storage can affect availability.

Selecting the Migration Type

Locate the target VM in the vSphere inventory.
Open the VM's Migrate action.
Select the option that changes the VM's storage or datastore placement.
Use a combined compute-and-storage migration only when you also intend to change the VM's ESXi host or compute resource.

For a storage-only migration, the expected result is that the VM remains registered and normally continues running on its current ESXi host while its files move to the selected datastore.

Choosing a Destination Datastore

Choose the destination based on more than free space. Consider capacity, performance tier, availability, storage policy, failure-domain requirements, expected growth, and the operational purpose of the move.

VMFS: a clustered filesystem commonly presented from block storage.
NFS: file-based storage presented by an NFS server.
vVol: storage that represents VM objects through storage-system-managed virtual volumes.
vSAN: a distributed storage service that uses local devices across participating hosts.

The available choices depend on the hosts, cluster, permissions, storage connectivity, policies, and vSphere release. A datastore may be visible in the inventory but still be unsuitable for a particular VM or disk.

A datastore cluster groups datastores for placement and balancing. Storage DRS can recommend or automate placement within such a cluster. Review Storage DRS automation settings before accepting an automatically suggested destination, especially during a planned evacuation or performance-sensitive move.

Read every compatibility warning in the wizard. A warning about accessibility, policy compliance, disk type, snapshots, encryption, or capacity is a reason to investigate before proceeding, not merely a message to dismiss.

Virtual Disk Formats and Placement

Storage migration can also change a virtual disk's provisioning format. The common formats are thin provisioned, thick provisioned lazy zeroed, and thick provisioned eager zeroed.

Disk format	Initial datastore capacity consumption	When blocks are zeroed	Potential advantages	Operational considerations
Thin provision	Space grows as data is written	As blocks receive data	Efficient initial use of capacity	Requires monitoring to prevent datastore overcommitment and exhaustion
Thick provision lazy zeroed	Full capacity is allocated initially	When each block is first written	Predictable allocation without the full creation-time zeroing cost	First writes can incur zeroing work
Thick provision eager zeroed	Full capacity is allocated initially	All blocks are zeroed during creation or conversion	Suitable for requirements that need eagerly zeroed space and some specialized workloads	Consumes full capacity immediately and can take longer to create or convert

Changing format affects destination capacity, data written, migration duration, and possibly performance characteristics. Some features, including certain fault-tolerance configurations, can have specific disk-format requirements. Confirm the requirements for the VM and workload before converting.

When available, advanced configuration permits individual VMDKs to use different destination datastores. This is useful for placing a database data disk, log disk, and operating system disk on separate storage tiers. Avoid unnecessary conversions or disk-layout changes: they can increase the amount of data written and extend the period of storage load.

Running and Monitoring Storage vMotion

Review the source and destination datastore selections.
Confirm the chosen disk format for each virtual disk.
Check advanced file placement, snapshot handling, and any policy messages.
Review the migration summary carefully.
Submit the task and monitor it in Recent Tasks.

Use task details and Events to identify validation failures, pauses, retries, or completion messages. After submission, inspect the VM's datastore information rather than relying only on the task percentage.

Migration duration depends on virtual disk size, changed-block rate, source and destination storage performance, network or storage-path bandwidth, snapshots, disk conversion, and concurrent activity. A heavily used database or file server can generate changes faster than a low-I/O VM. Large moves may increase datastore latency or guest I/O wait, so schedule them during lower-activity periods, migrate fewer VMs concurrently, or apply available operational controls.

Practical Example: Relieve a Nearly Full Datastore

Identify a powered-on VM whose files are on a datastore approaching its capacity limit.
Inspect candidate datastores and confirm adequate usable space, host accessibility, health, performance, and policy compatibility.
Open the VM's migration workflow and choose the storage or datastore change option.
Select the destination datastore and retain the current disk format unless a deliberate conversion is part of the plan.
Review the summary, submit the task, and monitor Recent Tasks and datastore latency.
After completion, verify the VM's new datastore, guest availability, application operation, and source capacity recovery.

This procedure can relieve capacity pressure without shutting down an eligible VM, but it does not remove the need to investigate why the datastore became full or to plan future capacity.

Practical Example: Move to Higher-Performance Storage

Compare the current and target storage tiers for latency, throughput, availability, and policy characteristics.
Assess the application's I/O pattern and choose a migration window that limits user impact.
Use storage migration to place the VM files on the faster datastore while retaining the intended provisioning format.
Monitor storage metrics during and after the move.
Validate guest and application performance against measurements taken before migration.

Practical Example: Convert a Thick Disk to Thin

Confirm that thin provisioning meets the VM's storage policy, capacity-management rules, and operational risk tolerance.
Choose storage migration and select thin provisioning for the applicable virtual disk.
Confirm that the destination has enough usable capacity for the migration process and that oversubscription controls are understood.
After completion, verify the disk format and monitor datastore utilization and growth.

Thin provisioning reduces initial physical consumption; it does not eliminate the need to reserve capacity for actual guest writes, snapshots, metadata, and operational headroom.

Practical Example: Evacuate a Datastore

Inventory all VMs, disks, snapshots, templates, and other required files on the datastore.
Check alternate datastore capacity, connectivity, health, policy compatibility, and performance.
Migrate VMs in planned batches while monitoring latency, throughput, and task failures.
Confirm that no required active VM files remain before placing the source datastore into maintenance or beginning storage work.
Retain or remove residual files only according to the organization's cleanup and retention policy.

Post-Migration Verification

Confirm that the migration task completed successfully.
Verify the VM's datastore summary and check every intended virtual disk.
Confirm the guest operating system is available and that critical applications function normally.
Check destination capacity, storage alarms, latency, and policy compliance.
Test or review backup jobs, replication, monitoring, snapshots, and storage integrations.
Confirm that old source files were removed only after a successful completed migration. Investigate residual files before deleting anything manually.

Snapshots, backup products, replication systems, and monitoring tools may need revalidation after a datastore change. A VM can be healthy while a dependent protection or automation workflow is not.

Operational Use Cases and Limitations

Common uses include rebalancing datastore capacity, moving workloads to faster or less expensive storage, evacuating storage for maintenance, retiring a datastore, and meeting storage policy requirements.

Storage vMotion is not a substitute for all storage maintenance procedures. The relevant ESXi hosts must retain appropriate datastore visibility and access, and dependent services must be considered. Special configurations can restrict eligibility or require additional planning, including:

Active snapshots and snapshot consolidation requirements.
Linked clones or other dependency-based disk chains.
Replication, backup locks, and protection jobs currently using the VM.
Encrypted VMs and destination encryption or key-management requirements.
Shared disks, clustered applications, raw device mappings, and special virtual devices.
Storage policies or storage types that are not compatible with the target.

Storage-intensive workloads can experience latency during a large relocation. Schedule migrations, throttle or batch them where possible, and avoid combining several costly disk conversions with peak application activity.

PowerCLI Validation Examples

The vSphere Client is usually the safest starting point for a one-off migration. PowerCLI can help inventory the VM, inspect datastores, and confirm host visibility before using automation.

# Identify the VM and power state
$vm = Get-VM -Name "App-VM01"
$vm | Select-Object Name, PowerState

# Inspect candidate datastore capacity
Get-Datastore -Name "Tier1-01","Tier2-01" |
  Select-Object Name, Type, CapacityGB, FreeSpaceGB

# Review the VM's current host and datastore relationships
$vm | Select-Object Name, VMHost, Datastore

Use Get-VMHost and datastore accessibility information to confirm that the required host can see the destination. A Move-VM operation with datastore-related parameters may be appropriate when supported by the installed PowerCLI version and environment, but validate the exact syntax and compatibility in the applicable VMware documentation before production use. Test automation with a noncritical VM first.

Troubleshooting Storage vMotion

Symptom or task error category	Likely cause	Verification step	Corrective action
Destination datastore is missing	It is not mounted, accessible, healthy, or permitted for the relevant host or user	Check host mounts, datastore status, permissions, and compatibility messages	Correct connectivity or permissions, exit maintenance mode when appropriate, or choose another datastore
Insufficient space	Free capacity does not cover disks, snapshots, conversion overhead, or growth	Calculate required space using actual files and the selected format	Free space, select another destination, reduce snapshot-related overhead when appropriate, or change the plan
Online migration cannot start	Licensing, version, configuration, device, or storage combination is unsupported	Review wizard compatibility checks, VM hardware, RDMs, shared disks, encryption, and policy requirements	Resolve the incompatibility, use a supported workflow, or power off for a cold migration if suitable
Migration is unusually slow	Large disks, high guest write activity, snapshots, conversion, or saturated storage paths	Monitor task progress, datastore latency, host storage metrics, and guest activity	Schedule lower-I/O work, migrate fewer VMs, avoid unnecessary conversion, and resolve bottlenecks
VM works but backup, replication, or policy checks fail	Dependent tools need revalidation or the destination violates a policy	Run protection tests and inspect policy compliance	Update integrations, remediate policy placement, and document the new datastore

Summary

Storage vMotion moves VM files between datastores while an eligible VM can remain powered on. A reliable migration requires capacity planning, datastore accessibility, permissions, policy and compatibility checks, careful disk-format decisions, progress monitoring, and post-migration validation. Treat snapshots, encryption, shared disks, replication, backup locks, and storage-intensive workloads as planning factors rather than assuming every VM can be moved identically.

For related study, review vSphere Storage vMotion migration procedures.