Overview
If you're planning a large migration, it's a good idea to divide the work into large chunks, called "sprints". A sprint should contain all of the VMs running one of your applications.
Velostrata subdivides a migration sprint into a one or more Waves, which group the VMs that run your application(s) into batches for migration. This document describes how to create waves, and define their subcomponents, runbooks and jobs.
Migration Waves
To make migration more manageable, Velostrata provides a feature called Waves that batches VMs for migration, which are made up of runbooks and jobs:
- A runbook is a CSV file that specifies the VMs to be included in a wave and the configuration of target VMs. It describes the source VM, defines properties for the target VM and networks, and also contains other metadata.
- A job is the migration operation that Velostrata performs on the list of VMs in the runbook. Migration operations include creating test clones, migrating, and detaching. A full list of migration phases is listed in the migration lifecycle.
Some considerations when using Waves:
- All VMs in a wave must each undergo the the same job. For example, if a database and application server are within the same wave, you cannot have a test clone created while the other is being fully migrated.
- Runbooks contain run groups, which define the order in which VMs are migrated in a wave.
Performing operations on migration waves
Batches of VMs in a wave move between the following stages in the migration lifecycle:
- Test Clone (for VMs from vSphere only)
- Delete Test Clone
- Run-in-Cloud
- Move Back
- Full Migration
- Offline Migration
- Detach
- Cleanup
In the event of a failure to move to the next stage, you can fix the problem and run the wave again. Velostrata picks up the migration where it left off.
For example, if you run a Run-in-Cloud job on a wave containing VMs A and B, and VM B fails to complete the operation, fix B. After fixing B, you can either perform a Run In Cloud operation to bring B to the same status as A (A will not be changed). Alternatively, perform a Full Migration operation, which will bring both VMs to the same state by performing Run-in-Cloud and then migrate A and B together.