While it is easy to create new virtual machines on a new vSAN powered vSphere cluster, sometimes the process of identifying the best way to migrate existing workloads over can seem a bit confusing.
What workloads do you move first?
What is the best Migration method?
What about Physical machines?
The purpose of this blog series is to cover these and other questions to help plan your migration and make it a success.
Picking First Workloads To Migrate
For the first workloads to migrate, I recommend picking a virtual machine
- That has relatively little dependencies on other virtual machines. highly chatty virtual machines that are part of large application meshes ideally should be migrated together.
- A Virtual machine that is not a tier 1 core network service (For example a Domain Controller that holds all 5 FSMO roles).
- A Virtual Machine that is not going to need special migration considerations (Clustered Applications, users of RDMs, users of in-guest iSCSI connections, users of hardware pass-through).
A good example would be an internal IT ticketing system, or a system that’s outage would only be immediately noticeable to the infrastructure staff.
It may be tempting to select 40 virtual machines and click migrate, but slowly ramping up from a test VM to a larger and larger number of virtual machines has some benefits.
- It helps you identify networking issues early before you impact tier 1 workloads.
- That new all-flash vSAN cluster may be able to handle 10 incoming storage vMotions, but that old, slow storage array you are moving off of may struggle to read the data and serve existing workloads. There is some built-in throttling, but if the storage you are migrating off of has performance problems large-scale migrations can make this problem worse. (To the point that a scheduled offline migration of a less important but highly storage demanding workload may help ease a lot of the burden to spread up the overall migration).
Pre and Post-migration checklists
Prior to the migration identify:
- Does this workload have a good/working backup?
- Who will be completing the validation that this workload is functioning as expected after the migration? It can be problematic to schedule late-night migrations that are only verified when the early shift comes into the office.
- Who owns this workload and is it still in use (Migrations can be a great time to clean up zombie VMs that should have been reclaimed years ago).
- What dependencies does this workload have (Software or hardware)? Some more odd examples of this include hardware MAC ID bound software licensing (that will need to be cloned to a new virtual NIC if the NIC changes).
Once this workload is migrated be sure to immediately check:
- Can I still connect to it or ping it (This could be a sign that a VLAN or VxLAN was not configured properly on the switch ports for the new cluster)
- What does the performance look like? Is disk latency relatively low (below 5ms) once the migration is complete?
- Do I need to upgrade the VMware hardware version, and upgrade VMtools.
Housecleaning tips during migrations
During migration, I find it a good time to also review some best practices. One of my personal favorites is making sure EVC is properly configured. No cluster should be without an EVC configuration even it is simply setting EVC to be at the highest level that it can run at. This will have zero performance impact turning EVC on at this setting.
CPU compatibility
Now, this is generally not a bottleneck moving from an older cluster to a newer cluster but it is still something to review. If a virtual machine is moving to a cluster that uses older generation CPUs you will need to have had EVC – Enhanced vMotion Compatibility enabled. It is worth noting that EVC should always be setup on the new cluster at the highest level it will support. Given EVC is normally turned on cluster-wide, if an older cluster needs EVC adjusted you may want to look at using per virtual machine EVC considerations. Remember setting the EVC mode of a virtual machine requires it restart.
