Storage vMotion

Storage vMotion

Storage vMotion

VMware vSphere Storage vMotion facilitates the live migration of virtual machine files from one datastore to another without service interruption.

Storage vMotion is to virtual machine files as standard vMotion is to virtual machine running instances. 

Using Storage vMotion, a virtual machine can be migrated from one datastore to another while the virtual machine is running, i.e. without downtime.

A virtual machine and all its virtual disks may be stored in a single location, or in separate locations.  Storage vMotion offers an attractive method for migrating virtual machine data from one set of storage to another, as the virtual machine can remain running while the data movement happens in the background without involvement or even awareness of the virtual machine’s OS.


The virtual machine itself does not change hosts during a migration with Storage vMotion, only the VM virtual disks are migrated.

VMware Storage vMotion describes the process by which files that make up the virtual machine (VM), e.g. meta-data files (.vmx, .log, .vswp, etc.) and virtual disk files (.VMDK) are relocated from one datastore to another without powering off the VM and without disconnecting users.

I.e. there is no downtime or service disruption on the running virtual machine. The process is completely transparent to the virtual machine or the end user.

VMware Storage VMotion:

• provides an intuitive interface for live migration of virtual machine disk files
• facilitates migration of VM files within and across storage arrays with no downtime or disruption in service
• relocates virtual machine disk files from one shared storage location to another shared storage location with zero downtime, continuous service availability and complete transaction integrity
• enables organizations to perform proactive storage migrations, simplify array migrations, improve virtual machine storage performance and free up valuable storage capacity.

Storage vMotion use cases include:

• array maintenance – move virtual machine files off of arrays for array maintenance or upgrade
• datastore maintenance – transform virtual disks from thick-provisioned to thin-provisioned or vice-versa, reclaim space, etc.

Over the different vSphere releases, VMware has deployed various mechanisms to migrate blocks from the source to the destination datastore. At vSphere 3.5, Storage vMotion used VM snapshots to migrate disks. In vSphere 4, VMware enhanced Storage vMotion by using the Changed Block Tracking (CBT) feature to track block changes during a Storage vMotion. At vSphere 5.0, VMware introduced to the Mirror Mode mechanism.

CBT used an iterative approach, after the initial copy, it checked to see if the blocks on the source datastore had been modified, if so, it copied over the “changed blocks”. It continued this iterative copy until it found no new modified blocks. At which time, vSphere would “stun” the VM and perform a switch-over from the source to the target datastore.

CBT kept track of blocks that were changed during the migration process and then applyed those changes to the destination disk. Mirror Mode mirrors every write from the source to destination disk while the migration is taking place.

With the Mirror Mode mechanism, the Mirror Driver is enabled on a VM that is being Storage vMotioned, and then the “Datamover” process is used to perform a single-pass block copy of the source disk to the destination disk. Mirror Driver mirrors (forks) any writes to the source AND destination disks. I.e. for any writes that go to the source disk, the same data is also sent to the destination disk. This removes the need for any iterative block copies.

“Mirror Mode enables a single-pass block copy of the source disk to the destination disk by mirroring I/Os of copied blocks.”

When both the source and the destination have acknowledged the write, the write will then be acknowledged to the virtual machine. Because of this, it is unnecessary to do re-iterative copies and the Storage vMotion process is more efficient with Mirror Mode.


vSphere Storage vMotion performs up to four parallel disk migrations per vSphere Storage vMotion operation.

Storage vMotion uses a synchronous mirroring approach to migrate a virtual disk from one datastore to another datastore on the same physical host. This is implemented by using two concurrent processes: a bulk copy process and an I/O mirroring process.

• Bulk copy process
• Clone
• Single pass bulk copy of the disk blocks from the source to destination datastore
• I/O mirroring process
• Runs concurrently with the bulk copy process
• Any virtual disk changes are copied/mirrored to both source and destination datastores

Storage vMotion mirrors I/O only to the disk region that has already been copied by the bulk copy process. Guest writes to a disk region that the bulk copy process has not yet copied are not mirrored because changes to this disk region will be copied by the bulk copy process eventually.

vSphere 5.1 (and later) vMotion follows an almost identical model for migrating a virtual disk, but uses a network transport for migrating the data.

Enhanced vMotion:
VMware vSphere 5.1 and later versions combine standard vMotion with VMware vSphere Storage vMotion in a single migration. This means you can live-migrate an entire virtual machine between hosts, between clusters or between physical data centers—without disruption or shared storage between the involved hosts. This capability to migrate virtual machines between hosts that do not share datastores can only be done using the vSphere Web Client.



VMware Reference:

• Storage vMotion Requirements and Limitations
• vSphere 5.1 Storage Enhancements – Part 7: Storage vMotion
• What’s New in VMware vSphere 5.0 - Storage
• vSphere Storage vMotion
• VMware vSphere 5.1 vMotion Performance and Best Practices