In the animal kingdom, the wildebeest is famous for migrating in herds. You’ll never find a wildebeest off on its own. In the plains of Tanzania and Kenya, more than a million wildebeest migrate in an enormous loop every year. On the other hand, the snow leopard is a solitary migrator, each animal coming down on its own, every winter, from the mountains of central Asia to the forests at lower altitudes. Now let’s talk about virtual machine migration. Like the wildebeest, some of your VMs will move to their new hosting location in a group. Other VMs are like the snow leopard, able to make independent, solitary journeys to their new home.
When you move your virtual machines to a new hosting location using JetStream Migrate, you have the option to create groups of VMs that should migrate together. That’s because many applications have dependencies, and moving their VMs together avoids operational disruption. For example, a web portal might act as a single business service, but actually comprise a front-end web server, an application server and a back-end database, each running on its own VM. As an administrator, you’ll want to move those VMs (and their data) to their destination concurrently, and bring them up together.
There are lot of application dependencies like this, and there are a number of ways to identify them. If you’ve configured DRS affinity rules, for example for the VMs in the web portal example, that’s a clear indication that the VMs should migrate as a group. Interestingly if you have anti-affinity rules for some applications, it’s likely that those VMs should be migrated as a group as well, because even though you don’t want the VMs behind an HA application pair running on the same host, you really don’t want them running in different data centers, even briefly.
Another way to identify application dependencies is to use VMware’s vRealize Infrastructure Navigator, which is a part of the vRealize Suite. The vRealize Infrastructure Navigator provides automated discovery of application services, displays relationships, and maps dependencies of applications on virtualized compute, storage, and network resources.
In JetStream Migrate, it’s easy to define a migration group and identify the VMs that it should contain.
Play the below video about VM Group Migration.
Why not just always migrate all the VMs in a cluster as a group? For one thing, that will be sending a lot of data to the destination concurrently. Migrating an unnecessarily large group of VMs could impact application performance, especially if bandwidth to the destination isn’t unlimited. Additionally, there are advantages to migrating your snow leopard VMs independently. In JetStream Migrate, you can select a number of VMs to migrate independently, and choose the “auto final migration” option. When you do this, the VMs will migrate to their destination and go live automatically, one after another.
Play the video below about Independent VM Migration.
This ability to automate the migration and startup of your VMs at their destination can save a lot of time and effort. Even if there’s an error and one VM fails to migrate for some reason, that won’t stop the others from migrating.
The ability to migrate VMs independently with auto-startup and the ability to migrate VMs in groups with administrator oversight is just one of the features in JetStream Migrate that give you greater control over your migration projects. In future blog posts, we’ll cover some of the other features that make JetStream Migrate a unique and powerful solution for live migration of VMs from one VMware environment to another.
As first published in VMblog.com
