One of the thrilling and stunning achievements of virtualization has been the ability to move running virtual machines between physical hosts while they are running. The moment when most engineers experienced this capability of virtualization, many were instantly hooked!

VMware vSphere is the enterprise leader in virtualization and was first to demonstrate this powerful feature of moving running virtual machines between physical hosts and even between storage devices.

VMware offered vMotion that allows moving running virtual machines between vSphere ESXi hosts. VMware Storage vMotion was introduced and allows moving running virtual machines between storage devices while they are running, with no downtime to the virtual machine, disruption to end users, or any loss of data.

Know More: Difference between VMware vMotion and Storage vMotion

In this post, we will look at Storage vMotion – A Brief Walkthrough and see how the technology works, what it is used for, and how to automate it.

Download Banner

What is Storage vMotion and How Does It Work?

As defined by VMware, Storage vMotion allows you to migrate a virtual machine and its disk files from one datastore to another while the virtual machine is running. You can choose to place the virtual machine and all its disks in a single location, or you can select separate locations for the virtual machine configuration file and each virtual disk. The execution host is not changed during the Storage vMotion progress.

Before taking advantages of Storage vMotion, it is important to make note of the requirements and limitations of the technology. What are the requirements and limitations of Storage vMotion?

Requirements and limitations of Storage vMotion

  • The virtual disks must be persistent mode or RDMs
  • You cannot be in the middle of installing VMware Tools when performing a Storage vMotion
  • You need to make a note of any VMFS3 datastores that you might target. You cannot move disks greater than 2 TB from VMFS5 to VMFS3.
  • You need to be licensed for Storage vMotion – no free license
  • If you are running vSphere ESXi 4.0 and later, Storage vMotion can be performed even without vMotion configuration
  • The host where the virtual machine currently runs must have access to both the source and destination datastores

What are the limits on Storage vMotion operations?

There are various “costs” associated with vMotion, Storage vMotion, vMotion without shared storage. VMware vSphere hosts have an overall maximum cost per host of 8. You can combine or mix and match operations to equal this cost for simultaneous operations that can happen at the same time with ESXi.

The following are host migration limits and resource costs for the various migration operations.

Operation ESXi Version Derived Limit Per Host Host Resource Cost
vMotion 5.0, 5.1, 5.5, 6.0 8 1
Storage vMotion 5.0, 5.1, 5.5, 6.1 2 4
vMotion without Shared Storage 5.1, 5.5, 6.0 2 4
Other provisioning operations 5.0, 5.1, 5.5, 6.0 8 1

How Does Storage vMotion Process Work?

The process that takes place with a Storage vMotion is well documented from VMware. However, the process involves a few steps that take place to prepare the target “shadow” VM and then cutover from the original “source” VM to this “shadow” VM that is made live.

  • The VM home directory is copied to the destination datastore along with the config, log, swap, and any snapshots).
  • The resulting “shadow” VM is made operational on the destination datastore. This VM sits awaiting the final copy of data over to the destination datastore.
  • VMware vSphere then begins copying data to the destination datastore. During the initial copy of data over to the destination datastore, Storage vMotion tracks the changes made to the source in the meantime with change block tracking (CBT).
  • The change block data copy process is iterative in nature. Data is continually copied from the source to destination datastore
  • When there is a small enough amount of data left, Storage vMotion performs a quick Fast Suspend and Resume (FSR) of the VM which happens with a vMotion to transfer the running VM over to the resulting shadow VM. This happens so quickly that the process is transparent to the VM and to end users.
  • Cleanup happens after the FSR which leads to the source home directory and VM disk files being deleted from the old source datastore.

Storage vMotion – What it is Used for

Storage has traditionally been one of the trickiest areas of infrastructure to maintain. Any maintenance tasks or reconfiguration has traditionally resulted in tremendous down time.

Back in the old days of server storage where physical LUNs hosted files and other business-critical services, it was a major event to have to move resources around. The beautiful thing about virtualized environments is the abstraction provided from the physical hardware and infrastructure to workloads. This leads to tremendous advantages over strictly physical environments, including traditional physical storage.

The functionality provided by VMware’s Storage vMotion is powerful. However, what are the day-to-day use cases that would lead to leveraging Storage vMotion in your environment. We will look at the following:

  • Migrating workloads to different storage environments
  • Ensuring performance to production virtual machines (Load Balancing Space and IO)
  • Performing maintenance on underlying physical storage
  • Storage Capacity Management
  • Transforming between virtual disk formats

Migrating workloads to different storage environments

The migration benefits and capabilities offered by Storage vMotion allows businesses to have much more flexibility in storage environments as opposed to traditional storage provisioning. With Storage vMotion, you no longer have to be permanently tied to a specific storage platform or storage LUN provisioned on a traditional SAN. Virtual Machine workloads can effectively be moved in a non-disruptive manner between storage environments.

With traditional storage environments such as adding new storage disks and arrays, storage reconfiguration and provisioning is very disruptive to the service of production workloads that may be utilizing storage. Without the ability to effectively migrate your production workloads from one storage subsystem to another, the service interruptions can be significant.

Without technologies like Storage vMotion, the disruption even to virtualized workloads can be equally significant. If a maintenance operation to underlying physical storage is scheduled, you would have to schedule the move of virtual machine evacuation from the underlying storage where maintenance operations will be performed. This would include powering off the virtual machine, moving the virtual storage from storage A to storage B, then powering the VM back on. As you can imagine, if you have tens maybe hundreds of VMs, this process would be very disruptive and time consuming.

Now, think about the same process where you have Storage vMotion at play. With Storage vMotion, the same scheduled storage maintenance can be performed without any downtime to production workloads. With Storage vMotion, the virtual machines can be migrated from storage A to storage B while it is running. To end users, the applications hosted by the virtual machines continue to operate as expected.

This also comes in extremely handy if you bring in new storage or provision a new SAN. If you have a current storage environment that is getting “long in the tooth” or coming off lease, you can simply provision new storage, attach it to the vSphere environment with access provisioned to the ESXi hosts, and then Storage vMotion the virtual machines running on old storage over to the new storage.

The flexibility in mobility this provides to production workloads allows businesses to reevaluate their storage options, even from a fiscal standpoint. With the pain point of migrating workloads from one storage solution to another removed, businesses can now entertain shorter term leases and other options that would not have been feasible with the downtime and service interruptions involved previously.

Ensuring performance to production virtual machines

Another extremely valuable capability afforded by Storage vMotion is the ability to ensure performance to production virtual machines. Storage vMotion is at the heart of a technology you can utilize called Storage DRS. Storage DRS makes use of datastore clusters. With datastore clusters, you can setup a cluster of datastores that utilize Storage vMotion to balance out the I/O and capacity usage on each respective datastore.

This works much like traditional DRS at the compute level where resources are evaluated. When those resources CPU/memory pass a certain threshold, resources are moved based on certain “aggressiveness” settings.

Storage vMotion

Creating a new Datastore Cluster and making use of Storage DRS

Storage DRS allows you to manage the aggregated resources of a datastore cluster. When Storage DRS is enabled on a datastore cluster, it is able to provide recommendations for virtual machine disk placement and migration to help balance space and I/O resources across the datastores in the datastore cluster.

This provides for many benefits by using Storage DRS, including:

  • Capacity balancing among datastores within a datastore cluster
  • I/O load balancing among datastores within a datastore cluster
  • Initial placement recommendations based on space capacity and I/O load

With the functionality of Storage DRS built into the platform, Storage DRS is able to achieve the following benefits for the storage environment:

  • Resource aggregation
  • Initial placement
  • Load balancing based on Space and IO
  • Datastore maintenance mode
  • Inter/Intra VM affinity rules

Storage DRS provides a great way to manage standalone datastores across hosts and clusters as it utilizes the datastore cluster object to aggregate datastores into a single entity and then apply thresholds to those datastores to manage moving virtual machine storage to different datastores based on capacity and load. It provides the additional benefits of easing the management pain of moving VMs to different datastores during maintenance events.

Having this automated solution is only possible with the capabilities provided by Storage vMotion which is the underlying technology at work with the Storage DRS feature. It highlights the power of the Storage vMotion functionality in providing load balancing for capacity and IO.

Performing maintenance on underlying physical storage

One of the huge advantages that comes with Storage vMotion is the ability to perform maintenance on underlying storage. With traditional storage, as mentioned, this is a huge pain point. Performing maintenance on underlying storage infrastructure with virtual environments without Storage vMotion is extremely disruptive. With no way to cleanly evacuate virtual machines from a LUN, it could mean shutting down the VM, copying it to different storage, and then powering it back on.

With Storage vMotion, you can perform the migration to different storage for running VMs without any downtime. This is a huge benefit. Additionally, as mentioned with the Storage DRS solution that makes use of Storage vMotion underneath the covers, the process to evacuate and relocate the virtual machines is automated.

With the datastore maintenance mode that is found under the actions for datastores contained in the datastore cluster, you can place the datastore in maintenance mode like you can for a vSphere ESXi host that is placed in maintenance mode. Workloads are evacuated with Storage vMotion.

Storage vMotion

Making use of placing a datastore in maintenance mode with Storage Clusters powered by Storage vMotion

In addition to allowing storage troubleshooting or reconfiguration, Storage vMotions allows other capabilities for additional storage flexibility. This includes the ability to more easily embrace new types of storage types and flexible leasing models that may have not been feasible otherwise. With Storage vMotion in use, changing or switching out storage more frequently allows these additional opportunities.

Storage Capacity Management

Managing storage capacity is often just as important as managing the performance of your storage. Especially if you have multiple datastores that house VMs, it can grow difficult to manage the capacity of the datastores in a manual way with manual intervention and moving of VMs.

Storage vMotion, working in conjunction with Storage DRS can work to optimize your storage capacity across datastores. Using the datastore cluster construct in vSphere, the multiple datastores that are part of the datastore cluster can be monitored by Storage DRS so that once capacities reach a certain threshold, VMs are proactively moved to alleviate storage capacity pressure that may build on a single datastore.

Storage vMotion

Under the Datastore Cluster Storage DRS Runtime Settings, you can utilize space thresholds

With Storage DRS using Storage vMotion to utilize capacity as efficiently as possible, it allows more effectively making use of all available storage. This is difficult to do with manual efforts. Using the configured thresholds, it allows determining the amount of space utilized on a datastore before Storage vMotion operations kick into play.

Also, you can set the Minimum space utilization difference to configure which datastores should be considered as destinations for virtual machine migrations using Storage vMotion. This is the required difference in utilization between the destination and the source datastores. This means SDRS will not move a VM from a full datastore to a relatively “equally full” datastore.

Storage vMotion

A look at the minimum space utilization difference for SDRS

Transforming between virtual disk formats

Another great benefit of performing a Storage vMotion is having the ability to perform a live disk transformation of a running virtual machine. The Storage vMotion process makes transforming disk types possible.

Let’s say you chose a 1 TB thick provisioned lazy zeroed disk when you created a virtual machine. This 1 TB disk is provisioned and storage space is consumed immediately in your datastore. However, if the server was grossly overprovisioned on space and only a small amount of the 1 TB volume is used for storing actual data, a thin provisioned disk would allow reclaiming the space consumed with the thick provisioned disks.

As you can see with the Storage vMotion process, you have the ability when changing storage to change the disk type between thick lazy/eager disks and thin provisioned disks. This is an extremely easy way to transition from a disk type that may have been chosen to be a better fit for a particular workload and/or datastore capacity.

Storage vMotion

Changing the disk type when performing a Storage vMotion

Migrating VMs with Storage vMotion in the vSphere Client

Let’s take a quick look at how to perform a storage migration using the vSphere Client. The process is rather simple. Right-click a virtual machine in the vSphere inventory, and select Migrate.

This launches the Migrate wizard. On the first Select a migration type screen, you have three choices:

Change compute resource only – Migrate the virtual machines to another host or cluster
Change storage only – Migrate the virtual machines’ storage to a compatible datastore or datastore cluster
Change both compute resource and storage – Migrate the virtual machines to a specific host or cluster and their storage to a specific datastore or datastore cluster.

The second and third options involve using Storage vMotion. You can choose to change only the storage, or change both the storage and the host housing the virtual machine.

Storage vMotion

Launching the Migrate wizard in vSphere Client for Storage vMotion

On the Select storage screen, choose the virtual disk format and the target datastore for the Storage vMotion.

Storage vMotion

Choose the virtual disk format and target datastore

Finally, on the Ready to complete screen, review the Storage vMotion operation to be performed and click Finish to begin the process.

Storage vMotion

Completing the Storage vMotion wizard

Now that we see how to do it with the vSphere Client, let’s take a look at how to automate the Storage vMotion operation.

Automating Storage vMotion Operations

VMware has done a great job of exposing the right APIs in vSphere that allow automating vSphere operations. This can easily be achieved with PowerCLI. Storage vMotion is no exception to the tasks that can be automated using PowerCLI.

A quick and easy one liner that can achieve a Storage vMotion includes the following:

  • Get-VM VM1 | Move-VM -Datastore “Datastore2”

For those familiar with the new Developer Center with the Code Capture functionality built into the vSphere Client, you can “start recording” any operation that you want to see the resulting PowerCLI code for in vSphere. The below recorded capture is for the process to perform a Storage vMotion of a particular virtual machine and changing the type of disk as it is migrated to a different datastore. You can use the output of the code capture to automate further processes such as Storage vMotion.

#—————– Start of code capture —————–

#—————QueryConfigOptionDescriptor—————
$_this = Get-View -Id ‘EnvironmentBrowser-envbrowser-1479’
$_this.QueryConfigOptionDescriptor()

#—————Config—————
$_this = Get-View -Id ‘VirtualMachine-vm-1479’
$_this.Config

#—————HasPrivilegeOnEntities—————
$entity = New-Object VMware.Vim.ManagedObjectReference[] (1)
$entity[0] = New-Object VMware.Vim.ManagedObjectReference
$entity[0].Type = ‘VirtualMachine’
$entity[0].Value = ‘vm-1479’
$sessionId = ‘52120714-0e7c-c3df-9ddf-7cb2ba3117ae’
$privId = New-Object String[] (2)
$privId[0] = ‘VirtualMachine.Interact.DeviceConnection’
$privId[1] = ‘VirtualMachine.Interact.SetCDMedia’
$_this = Get-View -Id ‘AuthorizationManager-AuthorizationManager’
$_this.HasPrivilegeOnEntities($entity, $sessionId, $privId)

#—————ListKmipServers—————
$_this = Get-View -Id ‘CryptoManagerKmip-CryptoManager’
$_this.ListKmipServers($null)

#—————HasPrivilegeOnEntities—————
$entity = New-Object VMware.Vim.ManagedObjectReference[] (1)
$entity[0] = New-Object VMware.Vim.ManagedObjectReference
$entity[0].Type = ‘Datastore’
$entity[0].Value = ‘datastore-540’
$sessionId = ‘52120714-0e7c-c3df-9ddf-7cb2ba3117ae’
$privId = New-Object String[] (1)
$privId[0] = ‘Datastore.AllocateSpace’
$_this = Get-View -Id ‘AuthorizationManager-AuthorizationManager’
$_this.HasPrivilegeOnEntities($entity, $sessionId, $privId)

#—————CheckRelocate_Task—————
$vm = New-Object VMware.Vim.ManagedObjectReference
$vm.Type = ‘VirtualMachine’
$vm.Value = ‘vm-1479’
$spec = New-Object VMware.Vim.VirtualMachineRelocateSpec
$spec.Disk = New-Object VMware.Vim.VirtualMachineRelocateSpecDiskLocator[] (1)
$spec.Disk[0] = New-Object VMware.Vim.VirtualMachineRelocateSpecDiskLocator
$spec.Disk[0].Datastore = New-Object VMware.Vim.ManagedObjectReference
$spec.Disk[0].Datastore.Type = ‘Datastore’
$spec.Disk[0].Datastore.Value = ‘datastore-540’
$spec.Disk[0].DiskId = 2000
$spec.Datastore = New-Object VMware.Vim.ManagedObjectReference
$spec.Datastore.Type = ‘Datastore’
$spec.Datastore.Value = ‘datastore-540’
$testType = New-Object String[] (4)
$testType[0] = ‘sourceTests’
$testType[1] = ‘resourcePoolTests’
$testType[2] = ‘datastoreTests’
$testType[3] = ‘hostTests’
$_this = Get-View -Id ‘VirtualMachineProvisioningChecker-ProvChecker’
$_this.CheckRelocate_Task($vm, $spec, $testType)

#—————HasPrivilegeOnEntities—————
$entity = New-Object VMware.Vim.ManagedObjectReference[] (1)
$entity[0] = New-Object VMware.Vim.ManagedObjectReference
$entity[0].Type = ‘Datastore’
$entity[0].Value = ‘datastore-540’
$sessionId = ‘52120714-0e7c-c3df-9ddf-7cb2ba3117ae’
$privId = New-Object String[] (1)
$privId[0] = ‘Datastore.AllocateSpace’
$_this = Get-View -Id ‘AuthorizationManager-AuthorizationManager’
$_this.HasPrivilegeOnEntities($entity, $sessionId, $privId)

#—————CheckRelocate_Task—————
$vm = New-Object VMware.Vim.ManagedObjectReference
$vm.Type = ‘VirtualMachine’
$vm.Value = ‘vm-1479’
$spec = New-Object VMware.Vim.VirtualMachineRelocateSpec
$spec.Disk = New-Object VMware.Vim.VirtualMachineRelocateSpecDiskLocator[] (1)
$spec.Disk[0] = New-Object VMware.Vim.VirtualMachineRelocateSpecDiskLocator
$spec.Disk[0].DiskBackingInfo = New-Object VMware.Vim.VirtualDiskFlatVer2BackingInfo
$spec.Disk[0].DiskBackingInfo.FileName = ”
$spec.Disk[0].DiskBackingInfo.ThinProvisioned = $true
$spec.Disk[0].DiskBackingInfo.DiskMode = ”
$spec.Disk[0].Datastore = New-Object VMware.Vim.ManagedObjectReference
$spec.Disk[0].Datastore.Type = ‘Datastore’
$spec.Disk[0].Datastore.Value = ‘datastore-540’
$spec.Disk[0].DiskId = 2000
$spec.Datastore = New-Object VMware.Vim.ManagedObjectReference
$spec.Datastore.Type = ‘Datastore’
$spec.Datastore.Value = ‘datastore-540’
$testType = New-Object String[] (4)
$testType[0] = ‘sourceTests’
$testType[1] = ‘resourcePoolTests’
$testType[2] = ‘datastoreTests’
$testType[3] = ‘hostTests’
$_this = Get-View -Id ‘VirtualMachineProvisioningChecker-ProvChecker’
$_this.CheckRelocate_Task($vm, $spec, $testType)

#—————RelocateVM_Task—————
$spec = New-Object VMware.Vim.VirtualMachineRelocateSpec
$spec.Disk = New-Object VMware.Vim.VirtualMachineRelocateSpecDiskLocator[] (1)
$spec.Disk[0] = New-Object VMware.Vim.VirtualMachineRelocateSpecDiskLocator
$spec.Disk[0].DiskBackingInfo = New-Object VMware.Vim.VirtualDiskFlatVer2BackingInfo
$spec.Disk[0].DiskBackingInfo.FileName = ”
$spec.Disk[0].DiskBackingInfo.ThinProvisioned = $true
$spec.Disk[0].DiskBackingInfo.DiskMode = ”
$spec.Disk[0].Datastore = New-Object VMware.Vim.ManagedObjectReference
$spec.Disk[0].Datastore.Type = ‘Datastore’
$spec.Disk[0].Datastore.Value = ‘datastore-540’
$spec.Disk[0].DiskId = 2000
$spec.Datastore = New-Object VMware.Vim.ManagedObjectReference
$spec.Datastore.Type = ‘Datastore’
$spec.Datastore.Value = ‘datastore-540’
$_this = Get-View -Id ‘VirtualMachine-vm-1479’
$_this.RelocateVM_Task($spec, $null)

#—————– End of code capture —————–

Storage vMotion is not Data Protection

Storage vMotion provides powerful capabilities to the VMware vSphere virtualized environment. This effectively allows freedom from the underlying storage when reconfiguration or other maintenance operations need to be performed. Traditional storage solutions do not provide the ability to safely and easily move production data from one location to another, especially while the workload is running. Storage vMotion effectively achieves this end goal.

However, it is important to note that Storage vMotion is not a form of data protection and is not meant to be used for disaster recovery purposes. Even with the capabilities it provides to your virtual environment, you still need to protect your data. This means you need to have a modern data protection solution that effectively allows backing up your data and storing it separately from your production infrastructure.

Vembu BDR Suite provides a powerful backup and replication solution for not only VMware but also Hyper-V environments that allows effectively backing up and replicating your data securely. This ensures the data is protected regardless of a hardware or other failure.

While VMware Storage vMotion allows migrating between storage, Vembu BDR Suite allows migrating between storage, different hypervisors and disk types. This provides functionality that is not achievable with Storage vMotion alone.

Conclusion

Storage vMotion is a great feature allowing flexibility in migrating workloads between datastores and providing an easy way to perform maintenance operations on production VMware datastores while workloads are running.

Combined with the Storage DRS and Datastore Clusters, Storage vMotion provides a great way to enhance and automate performance and capacity management along with maintenance operations.

Vembu BDR Suite allows you to effectively backup and replicate your business-critical data along with migrating between different hypervisors and disk types.

Be sure to download a fully-featured trial version of Vembu BDR Suite here.

Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.

Like what you read? Rate us
Storage vMotion – A Brief Walkthrough
Rate this post