A 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.
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.
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 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.
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.
8 comments have been added so far
Gret article, Jeff. Another useful technique I’ve found for migrating to vSAN is to leverage XvMotion (sometimes called Unified vMotion). This comes in handy for two reasons: (1) it is included with vSphere Essentials Plus and higher, and (2) it allows you to non-disruptively migrate VMs from VMFS or NFS to vSAN without needing to physically connect the vSAN hosts to the “legacy” VMFS/NFS datastores. The “legacy” compute cluster remains connected to the “legacy” VMFS/NFS storage, and the “new” vSAN cluster remains solely connected to the vsanDatastore. Of course for this to work, both clusters must have matching EVC levels, so we typically keep the EVC level at the lowest common level during migration, and then raise the EVC level on the vSAN cluster post-migration, which is non-disruptive.
Hi Bill. Thank you for the feedback. I tend to keep it short and sweet as specific steps on using a solution are usually documented elsewhere. XvMotion is certainly another good option. Thank you for bringing that up. You are correct in stating one needs to be mindful of EVC levels. I am glad you mentioned that, as well. Thanks again.
How did you map the vSanDatastore to the existing cluster? I have to migrate the VMs from 5.5. All existing datastores are NFS mounted.
@MArio – it is the other way around. Map your NFS datastores to the new vSAN cluster.
How can I contact you directly? I have a few more questions surrounding this.
Please DM me on Twitter @jhuntervmware
Great article, Jeff. I´m having problems here using vSphere Replication since we have a vSAN AF cluster with dedup and compression enabled but even specifying a custom created Storage policy that have 0% Allocation space, seems that migrated VMs are not benefiting of dedup and in some case the ratio are getting worse that were before the beginning of the migration. Do you have any ideas what of can be going wrong? Thanks, Felipe
It is very difficult to troubleshoot issues through a blog site. I recommend opening a support request with VMware Support.