Large organizations are married to the VMware suite of products. We can quibble about numbers for adoption of Hyper-V and KVM, but VMware dominates the enterprise virtualization market, just as Kubernetes is the unquestioned champion of containers.

Virtual Machines (VMs) are a mature technology, created and refined before large-scale adoption of public cloud services. Cloud-native workloads are often designed for containers, and containerized workloads are designed to fail. You can tear one down on one cloud, and reinstantiate it on another. Near-instant reinastantiation is the defense against downtime.

VMs take a different approach. A VM is meant to keep existing for long periods of time, despite migrations and outages. Failure is to be avoided as much as possible. This presents a problem as more organizations pursue a multi-cloud IT strategy.

The key technology for highly available VMs is vMotion: the ability to move a VM from one node in a cluster to another with no downtime. However, as data centers themselves become increasingly virtualized, using cloud computing services such as Microsoft Azure, Google Compute Engine, and Amazon EC2, there’s a growing requirement to be able to move VMs between cloud infrastructures. This is not a supported feature of vMotion.

Routed vMotion solves this problem, and an explanation of what routed vMotion is, along with an exploration of how it can improve management and reliability in your organisation, is the focus of this blog post.

Routed vMotion

Routed vMotion, for our purposes, describes moving VMs between clusters (instead of just between nodes). The clusters may be in different subnets and/or data centers.

This is especially useful in deployments where VMs can’t simply be torn down and re-instantiated as containers can; instead, they need to be moved from one cluster to another with as low a switchover latency as possible, for example to continue serving a web application during data center downtime.

vMotion, in its standard form, limits how far a VM can realistically be moved. This is because VMware ESXi requires all nodes in a cluster to be reachable by the same layer 3 subnet, an architecture not always possible in deployments. (It is actually possible to stretch a cluster between two sites, but this is not a feature designed for multi-cloud deployments; it requires a certain level of control over the architecture at both sites).

Routed vMotion allows migrating of VMs between clusters, which allows them to be moved between subnets. An example of this in action might be as simple as moving a VM from a test lab (in subnet 10.1.1.0/24) to production (10.0.0.0/24); or as complex as live, frequent migrations of virtual servers between public and private cloud infrastructures for speed, reliability, and pricing reasons.

This technology becomes increasingly important as providers transition from simply renting data center space to obtaining compute and storage from multiple cloud providers on an as-needed basis. VMs can be vMotioned between a cheaper, slower cloud provider to a faster, more expensive one as needed, and moved back to the low-priority pool when appropriate.

This would be useful in a scenario in which many web server VMs are placed behind a load balancer, adjusting the number of VMs running in the high-priority pool commensurate with the amount of load on the web application.

Another application of this technology is in data center migrations, where a VM can be vMotioned into a cloud provider’s infrastructure, then back down into a physical data center — or another, better, cloud provider — once the move is complete.

This increases quality of service and allows a business to give a higher uptime guarantee than they otherwise would be able to without investing in expensive, highly-available server clusters, power, and networking; a prohibitive cost for many businesses.

Instead, vMotion, hot standby, load balancing and similar technologies can be used to keep a business running even in the event of a complete power failure at their primary data center or at the data center(s) of their primary cloud provider.

Enabling a Multi-Cloud Future

Compute and storage are becoming scaleable, multi-infrastructure architectures able to grow and shrink with the customer’s changing requirements. Multi-cloud deployments offer the flexibility to move between cloud providers as needed to reduce cost, deal with variable demand, or take advantage of cloud-native, proprietary technologies like Amazon’s Rekognition.

Enterprises need to be able to take advantage of these possibilities without completely ditching their VMware environments. Routed vMotion allows VMs to be moved between clusters, and therefore between data centers and cloud providers. This gives enterprises the best of both worlds. This is why routed vMotion is going to become a crucial technology in the new wave of cloud-first, flexible data centers.