The Great VMware Exodus

Learn about the challenges of migrating from VMware to another hypervisor and explore an alternative solution: migrating VMs into containers

With the seemingly endless announcements coming out of VMware / Broadcom regarding license and product changes, it's no wonder VMware customers are worried about the future.

It's also pretty obvious that the VMware competitors are loving the opportunity to tell a story about how you can switch to their solution, with no complications at all - and some of them even have the tooling to assist with this.

So, what's the problem?

Well, a migration, like any IT project, needs two things:

1. Planning; and
2. Execution.

With something as critical as your hypervisor, you don't just tear in without knowing exactly what you need to do and how to do it. At least, not if you want it to go well.

Even if the replacement vendors claim to have all the tools, to complete a migration like this you should expect to spend many hours on the planning and execution. As a rule of thumb, 8 hours per VM would be a good starting point to help you estimate the overall time you might need, with actual data copy time on top of that.

When scoping out your estimate, you will need to consider:

• Completing a full VM inventory
• VM dependency mapping - which VMs rely on each other and in what ways
• Outage planning - scheduling downtime with all affected parties
• DR planning - what to do if it all goes wrong, and how will you offer DR with the new hypervisor
• Backup and Recovery planning - how will you perform VM backups with the new hypervisor
• License implication planning - for example MAC address changes and Windows reactivation
• and much more, including whether your app vendor even supports hypervisors other than VMware.

If you have just a handful of VMs, this might be a trivial process. When you get into the hundreds or even thousands of VMs, the time/cost is very real. More often than not, you will also need to engage the services of an external consultant to help you, so then the costs start to stack up fast.

Even worse, VMware has for a long time sold its software as bundles, and these bundles include a range of ancillary tools. If you are looking to eject VMware from your estate, it's not just the hypervisor you need to consider, it's the replacement of the operational management tooling that surrounds it too. Then there's your VMware-trained IT staff, who likely have a decade's worth of experience managing your platform, and who now need to be retrained in something new.

So what's the alternative?

Don't migrate from VMware to another hypervisor.

This is very much a differentiated, and maybe even a confrontational suggestion...  but why not? Because it's a move sideways. Other than saving you VMware license fees (which I'm sure are significant), it doesn't move your business forward in any way.

Take this change for the opportunity it is and invest the time and money that you would need to spend on changing hypervisors and instead:

Migrate your VMs into Containers.

To be clear, this isn't saying that you should completely refactor your application to native microservices and onto a platform such as Kubernetes - although, if you can, great (and many ISVs already support their apps in containers) - instead start with something as simple as spinning up a Ubuntu container, using rsync to copy files over from your VM, install any required application components, and then use a solution like supervisord as the "PID1" process that the container runs as (and running this on plain old Docker on bare metal with shared storage). Sure, this is a derivative of a "lift and shift", but at least it gets you onto a more flexible platform and way of working.

There are even tools from cloud providers such as Google and AWS to help you to move to their platforms, but for a Linux engineer who has had some exposure to containers, it's relatively straightforward to do it yourself.

Lots of container solution vendors are trying to convince you to switch to KubeVirt (or their variant of it), which is a way of running VMs managed by Kubernetes. While that is a neat technology, it really is just a VM-to-VM migration. Don't get confused by the Kubernetes component of this. I'm talking about actually putting the contents of your VM into a container, not a VM masquerading as a container.

So, if you want to move on from the VMware ecosystem, you have a choice to make:

• Spend $$ and move sideways; or
• Spend (likely the same) $$ and move forward.

As a former CIO, I know which option I would prefer.

What will you do?

Neil