Migrating Virtual Services
Avi Vantage supports easy migration of virtual services from one Avi Service Engine (SE) to another. This capability can be useful in cases where an Avi SE needs to be disabled. For example, an Avi SE host may need to be disabled for maintenance.
Using the steps in this article, the virtual services on an Avi SE can be migrated to another Avi SE. The migration is transparent to end users of the virtual service. Existing sessions continue with very minimal or no perceived interruption.
Note: Migration is not supported on a legacy active/standby SE group.
Migrating an Individual Virtual Service
- Navigate to Applications > Virtual Services.
- Click the name of the virtual service to be migrated.
- Hover the mouse over the name of the virtual service to display the quick edit menu for the virtual service.
- Click Migrate.
- Select the Avi SE to which to migrate the virtual service.
Avi Vantage shows the progress of the migration:
Note: If no other SEs are available, click Create Service Engine and select the host on which to create the SE.
Migrating All Virtual Services
- Navigate to Infrastructure > Clouds.
- Click on the cloud name.
- Select the checkbox next to the Avi SE to be disabled.
- Click Disable.
Avi Vantage migrates all virtual services that are on the disabled Avi SE to another SE. (Generally, this takes several minutes.) After all the virtual services have been migrated, the Avi SE is disabled and its health icon turns to grey. To view the virtual services that are on the targetted SE, including any migrated virtual services, click the row for the SE (not on the SE name).
Note: For more on disabling Avi SEs, read the Disable SE article.
In both of the above scenarios, no mention was made of potentially changing the definition of the SE group prior to initiating migrations. Barring such changes, migrated virtual services find themselves (re-)placed on pre-existing or newly spun-up SEs with identical hardware configurations.
However, if migration to new hardware is required, the administrator needs to change the properties of the SE group prior to undertaking any VS migrations. Changing the SE group definition has no effect on SEs that are already running. Only when new SEs are spun up does the new SE group definition come into play. Virtual services placed thereafter find themselves:
- Placed on SEs whose servers are
- attached to potentially different networks (but reachable by clients, back-end servers, and Avi Controllers), and
- equipped with more (or less) powerful CPUs having different memory and disk configurations.
- Assigned more (or less) vCPUs and different virtual disk and memory capacities.
- General information about Service Engine groups
- For information related to the SE group settings
max_scaleout_per_vs, refer to Impact of Changes to Min/Max Scaleout per Virtual Service.