Migrating VMs from Legacy Infrastructure to SimpliVity HCI

There are a number of ways to migrate VM workloads from a legacy infrastructure to SimpliVity. By design a SimpliVity deployment is simple (it’s in our name) but migrating workloads from a legacy infrastructure can seem like a daunting task and it can be. However, if the migration is planned properly it can be easily accomplished without a significant impact on VMs running in the environment. This post provides an overview of some common migration methods which can be used to move VMs from a legacy infrastructure to the SimpliVity Hyperconverged Infrastructure (HCI).

Integrating SimpliVity into an existing environment.
This is probably the most common scenario. SimpliVity is deployed to either replace the legacy environment, provide additional capacity to augment the legacy environment, or to support a specific use case/application. Regardless of the use case the existing vCenter is used and SimpliVity is deployed into the existing environment.

1. Present a SimpliVity Datastore to a host in the legacy environment.
2. Use Storage vMotion to migrate VMs to SimpliVity Datastore.
3. Use vMotion to migrate VMs to SimpliVity node.

The Storage vMotion will not have any impact on the availability of the VM being migrated. If there is processor compatibility between the legacy hosts and the SimpliVity hosts, which can be accomplished by deploying the SimpliVity nodes into a Enhanced vMotion Compatibility (EVC) enabled cluster, the VM vMotion can be done without impacting the availability of the virtual machine. If the processors are not compatible then the VM will need to be powered off and migrated using a cold vMotion. Since cold vMotions happen very quickly the downtime per VM is usually only a couple of minutes.

If the requirements are met for enhanced shared-nothing vMotion then this could also be used to live migrate storage and compute together without presenting SimpliVity storage to the legacy environment and without impact to the availability of the VM during the migration process.

This migration method could also be done by presenting the legacy storage to the SimpliVity nodes. The process would essentially be the same but the SimpliVity design would likely need to include HBAs or NICs to provide storage connectivity to the legacy storage.

A virtualized vCenter server can also be migrated on to the SimpliVity DVP, I cover the process in this post: Migrating a virtualized vCenter Server (VCSA or Windows) into the SimpliVity environment.

Migrating to a new SimpliVity environment.
In this use case the customer stands up a new vCenter environment to deploy the SimpliVity solution. Typically the reason for doing this is to get to the latest vCenter version without having to upgrade the legacy infrastructure. This is usually done when SimpliVity will be a complete replacement for the legacy infrastructure. Other reasons include moving from a Windows vCenter Deployment to a vCenter Server Appliance (VCSA), or from a physical vCenter Server to a virtual vCenter Server.

1. Migrate VMs to a specific host in the legacy environment.
2. Add the legacy host to the new vCenter managing the SimpliVity HCI environment.
3. Present SimpliVity Datastore to legacy host.
4. Use Storage vMotion to migrate VMs to the SimpliVity Datastore.
5. Use vMotion to migrate VMs to SimpliVity nodes.

In this process a legacy host is used as a “swing” host. Once the “swing” host is added to the new vCenter inventory the SimpliVity Datastore are presented to it, and it essentially becomes a compute node. The difference between using a compute node as a “swing” host and using the compute node as a permanent resource is that SimpliVity supports presenting the SimpliVity Datastore using 1 GbE connectivity for the purpose of migration – no 10 GbE switching is required.

As with the previous migration option the Storage vMotion has no impact the availability of the VM and if processors are compatible then the vMotion can also be performed without any downtime. If processors are not compatible the VM will have to be shutdown and a cold vMotion will have to be performed. Again, since cold vMotions happen very quickly the downtime per VM is usually only a couple of minutes.

Presenting Legacy Storage to SimpliVity nodes.
Another method is to present the legacy storage to the SimpliVity nodes and follow the same process to move the VM from the inventory of the legacy environment to SimpliVity nodes and then migrate storage from the legacy storage to SimpliVity Datastores.

1. Present Legacy Storage to SimpliVity nodes.
2. Power off the VM being migrated and remove it from the inventory of the legacy vCenter.
3. Add VM to the inventory of the new vCenter and power on VM.
4. Use Storage vMotion to migrate VM data to SimpliVity Datastore.

This method is commonly used when the legacy storage will continue to be part of the environment. In this case the SimpliVity design will include HBAs or NICs to provide storage connectivity to the legacy storage.

Since the VM has to be powered off to be removed from inventory there is downtime during the migration. As with the other methods this downtime is minimal, only as long as it takes to shutdown the VM, remove and add to inventory, and power on the VM.

There are other methods for migrating from a legacy infrastructure to SimpliVity HCI (V2V, import/export, 3rd party migration tools, etc), but these are the most common, usually the quickest, and have the least amount of impact on the availability of VMs being migrated.