vms-to-vsan-2A frequently asked question from customers considering vSAN is “How do I migrate virtual machines from my old storage to vSAN?” There are a few ways this can be done and a number of solutions to facilitate the migration. This blog article discusses a few of these options and concludes with a link to a click-through demo showing the migration of VMs to vSAN.

Storage vMotion

The easiest method in most cases is to use Storage vMotion. This feature is included in vSphere Standard and higher editions of vSphere and vSphere with Operations Management. Existing storage must be accessible by the hosts in the vSAN cluster. In other words, the cluster will have access to both the vSAN datastore and the storage you are migrating the VMs from (SAN, NAS, etc.). The process is simple: Select one or more VMs in the vSphere Web Client, right-click the selection and click Migrate. Choose the storage-only option, select the vSAN datastore as the destination, and proceed with the last few steps of the migration wizard. vSphere will copy the files – VMX, NVRAM, VMDK(s), etc. – from the old storage to the vSAN datastore. Note that vSphere will potentially be copying large amounts of data. The process can take a significant amount of time depending on how much data must be migrated and how fast your storage is. In most cases, it is best to do just a few VMs at a time. This method does not require any downtime. The VMs continue to run as they are being migrated.

Host-Based Replication

Another option is using host-based VM replication. An example of this is vSphere Replication, which is included with vSphere Essentials Plus Kit and higher editions of vSphere and vSphere with Operations Management. Other VM-level replication solutions such as Dell EMC RecoverPoint for VMs could be used just the same. Array-based replication solutions are not supported with vSAN.

Host-based replication does not require the vSAN cluster to have access to the existing storage. For example: An existing vSphere cluster utilizes the source SAN or NAS datastores. A new vSphere with vSAN cluster is deployed. The new vSphere with vSAN cluster does not require access to the old SAN or NAS datastores.

vSphere Replication

vSphere Replication is deployed in the target cluster – the vSAN cluster, in this case – as a virtual appliance. Once the vSphere Replication appliance is deployed and configured, replication can be configured for the VMs on the old cluster. It is possible to configure replication one VM at a time or select multiple VMs and configure replication for all of them. Once the data has been replicated to the target vSAN cluster, vSphere Replication can be used to “recover” the VMs on the new vSAN cluster. This procedure does require just a bit of downtime so it is best to schedule the recovery/migration of the VMs during a maintenance window.

Site Recovery Manager

Migrating larger numbers of VMs commonly requires some orchestration. VMware Site Recovery Manager (SRM) with vSphere Replication is an excellent solution for migrating many VMs. vSphere Replication (by itself) is limited to recovering/migrating one VM at a time. SRM enables the migration of up to 2000 VMs concurrently. SRM provides the ability to prioritize the order in which VMs are migrated and automatically change IP addresses, if needed. It also  includes test functionality so that organizations can non-disruptively test a migration plan while production continues to run unaffected. The ability to test a migration plan multiple times before actually performing the migration naturally adds a higher level of confidence in the migration plan.

Click-Through Demo

There are other methods for performing migrations, but Storage vMotion and host-based replication are the two most common and easiest ways. If you want to get a closer look at using Storage vMotion and vSphere Replication to migrate VMs, please see the click-through demo below.

Click-Through Demo – Migrating VMs to vSAN

As a footnote, keep in mind it is a best practice to consolidate all snapshots before migrating a VM.