In my last post I talked about the what and the why and considered the planning element of a migration. This post focussed on the execution and the options which are available.
The How – Migrating
As mentioned previously, we’re fortunate that physical server numbers are less than they once were but there are usually still some kicking around (usually the ones which run some mission critical business function). The question is then how these are handled which will vary depending on the situation. For example, is a lift and shift exercise to quickly exit the data center, is there a desire for transformation to reduce operating costs associated with these servers, or can they simply be left in situ on the basis that they will be refreshed at a later date as part of normal BAU process? Ultimately, this will dictate what products are required for the job – e.g. P2V agent-based products or something that just needs to handle virtual machines.
I remember years ago using SRM to migrate VMs from one data centre to another as part of a migration rather than a DR (which was it’s primary purpose at the time). It must have been common enough that VMware has built a migration tool out of it – HCX.
HCX is a real game-changer when it comes to migrations because it provides a lot of very useful functionality, some of which I’ll describe below. As a result HCX has become the de facto standard when it comes to the (V2V) migrations that VMware PS are involved in. The first thing to note is that HCX requires NSX at the destination (it’s not mandatory at the source).
The first decision point is whether you need IP changes should or need to be avoided. HCX has a feature called Network Extension which can stretch a VLAN associated with a vSphere Distributed Port Group or overlay from the source to the NSX enabled destination. This allows VMs to be moved whilst maintained the IP address and even MAC address which can be useful in terms of not breaking applications, but also maintaining the network security profile. Typically in most cases, maintaining IP addresses is the only game in town. In the past, overlapping IP spaces associated with mergers and data center consolidations, have become less of an issue in a software-defined networks world. An alternative to network extension is stretching networks at the physical layer (e.g. Cisco EVPN) but most tend to avoid this route in my experience. If IP addresses will change during migration then Network Extension is not necessary and workloads can simply be migrated between two independent networks.
After that, it’s a question of the migration approach itself. This largely boils down to three questions;
- Is the source environment vSphere based?
- Is an outage acceptable?
- Is scheduling necessary?
First of all, if you’re moving from a non-vSphere environment, you are limited to HCX OS Assisted Migration which uses an OS agent to replicate image. This will involve a period of downtime when the replicated target takes over from the source.
If the source platform is vSphere 5.5 based (or later) you have rather more options.
HCX Bulk Migration – uses vSphere Replication to replicate the VMs, allows scheduling within a migration window and involves a brief outage (reboot) when the VMs are migrated (SRM, hello?). It supports 100 VMs concurrently. Actually, this method is supported with vSphere 5.0 and above.
HCX Cold Migration – used for migrating VMs which are in a powered-off state and uses the NFC protocol for file copy.
HCX vMotion – Normal vMotion we all know and love, the VM will remain online but like Cold Migration, it is for moving one VM at a time without scheduling.
HCX Replication Assisted vMotion – similar to Bulk Migration in that it uses vSphere Replication to replicate the VMs ahead of time, but rather than a ‘failover’ it uses vMotion technology to sync the remaining delta at migration time (i.e. very fast vMotion within the migration window). There are a number of caveats around this, Hardware Version 9, no physical RDMs etc. so it’s important to validate these as part of your migration design.
vCloudburst Blog 