I am happy to announce the new version release of my community project – VMware AVI Virtual Service Migrator (formerly NSX ALB Virtual Service Migrator).
If you aren’t aware about this project, VMware AVI Virtual Service Migrator is a community project to migrate Virtual Services (and it’s dependencies – pools, poolgroups, HTTPPolicySets, VSVIPs and child virtual services, if in a Parent-Child relationship) across VMware AVI Cloud Accounts, VRF Contexts, Service Engine Groups and NSX T1 gateways. Currently the below VMware AVI cloud accounts are supported:
- vCenter Cloud
- NSX-T VLAN cloud
- NSX-T Overlay cloud
- Including VMware AVI on Azure VMware Solution (AVS)
- No-Orchestrator cloud
- Including VMware AVI on VMware Cloud on AWS (VMConAWS)
The new version v1.4 adds enhancements around virtual service migration planning, consolidation of migration workflows, job status reporting, tracking of skipped settings, additional prechecks for migration consistency, bug fixes and more.
Taken from the release notes at https://github.com/harikrishnant/VMware-AVI-Virtual-Service-Migrator/blob/main/RELEASENOTES.md
Table of Contents
Supported VMware AVI Versions
VMware AVI API Versions 18.1.2 till 30.2.2
What’s New
- Naming changes – NSX ALB Virtual Service Migrator is now renamed as VMware AVI Virtual Service Migrator
- Added option to generate migration planner workbook to assist with organizing AVI virtual services into migration batches. This will accelerate the migration planning phase.
- Consolidated the workflows for migrating virtual services of type “Normal” and “SNI_EVH”, which was handled as separate workflows in the previous versions. The migration flag “-q” or “–virtual_hosted_vs” is now deprecated. This enhancement will reduce the number of migration batches involved.
- Improved job status reporting options. Status spreadsheets are generated in *.xlsx format for each of the migration modes.
- Included tracking of skipped settings as part of migration in a separate spreadsheet which can be reviewed post-migration of a batch.
- Added support for migrating virtual services that have WAF policies without a PSM group (learning group)
- Added support to scan AVI objects to identify possible naming duplications that can prevent a successful virtual service migration. Any naming duplicates if found, will be tracked in a separate spreadsheet which can be reviewed for action.
Issues fixed
- TULSI-005 : An issue preventing a successful cleanup of virtual services of type TLS-SNI / EVH is now fixed.
- TULSI-006 : Virtual service migration failures caused as part of WAF learning groups, custom datascripts and L4 policy sets are handled gracefully using skipped settings workflow. Entries in the skipped settings output will be a manual administrator task.
- TULSI-007 : Error, Warning and Info message customizations with color codes is completed.
- TULSI-008 : An issue preventing user prompt while an incorrect virtual service name is supplied is now fixed.
- TULSI-009 : An issue where remove_prefix and cleanup modes are returning success messages in a specific scenario is now fixed.
- TULSI-010 : An issue causing migration failures when duplicate object names are detected in the AVI tenant is now handled through a separate workflow.
- TULSI-011 : An issue causing migration failures for Parent-Child virtual services as part of API changes in AVI 30.x version is now fixed.
Known Issues
- TULSI-012 : Status output directories of migrate, remove_prefix and cleanup modes will be overwritten during each migration batch.
- Workaround : Manually backup the directories before a new migration batch is run.
Usage Instructions
- Make sure that the target cloud account to which the Virtual Services need to be migrated is configured. This includes the cloud connector configuration, VRF Contexts, networks & routing configuration and service engine confguration under the Service Engine Group.
- The necessary routes (default routes / static routes to the pool members) need to be available on the target VRF context before migrating the VS / Pools.
- Make sure that the target cloud account / VRF context doesn’t have a conflicting VSVIP object (VIP) compared to the objects being migrated from the source cloud account. If it has any, perform migration with IPAM profiles attached.
- A linux / Windows VM (with an IDE like VSCode) with Python3 and connectivity to VMware AVI controllers is required to perform the migration.
- Install Python3
- Install git
- Install the below python modules:
- requests -> python3 -m pip install requests
- urllib3 -> python3 -m pip install urllib3
- tabulate -> python3 -m pip install tabulate
- pandas -> python3 -m pip install pandas
- openpyxl -> python3 -m pip install openpyxl
- Clone the repository and navigate to VMware-AVI-Virtual-Service-Migrator/V1.4/ -> git clone https://github.com/harikrishnant/VMware-AVI-Virtual-Service-Migrator.git && cd VMware-AVI-Virtual-Service-Migrator/V1.4/
- The migration tool has four modes:
- Generate Planner Workbook mode -> This mode will generate a migration planner workbook with the details of all virtual services in the VMware AVI Controller Cluster. This workbook can be used for organizing the virtual services into migration batches with the target cloud, VRF, SE Group and VIP addressing options.
- Migration mode -> This mode will perform migration of virtual services to same or different VMware AVI Cloud account.
- Remove Prefix mode -> This mode will perform automated removal of prefixes appended to the migrated objects. This needs to be done post cutover of virtual services (ie, after the migrated virtual services are enabled and the old virtual services are deleted).
- Cleanup mode -> This mode will perform cleanup of migrated objects incase the tool encounters an error or if post migration validation fails. Use this mode with caution as it deletes all the migrated objects under the specific migration batch (run-ID)
- The migration workflow will create a tracking directory (VMware-AVI-Virtual-Service-Migrator/V1.4/Tracker-DONOTDELETE/) which has the tracking information for each job. DO NOT DELETE or access this directory, as this is required for cleanup and remove_prefix jobs.
- The migration tool creates the below output directories / spreadsheets based on the mode it is run. These spreadsheets need to be reviewed for any errors.
- Generate Planner Workbook mode -> A spreadsheet named “Planner_Workbook.xlsx” will be generated in the working directory (VMware-AVI-Virtual-Service-Migrator/V1.4/)
- Migration mode -> Output directory named “Migration_Status” (VMware-AVI-Virtual-Service-Migrator/V1.4/Migration_Status) that has two spreadsheets – Migration status spreadsheet (Migration-Status-.xlsx) and Skipped settings spreadsheet (Skipped-Settings-.xlsx). Both spreadsheets need to be reviewed once a migration batch is run.
- Remove Prefix mode -> Output directory named “Prefix_Removal_Status” (VMware-AVI-Virtual-Service-Migrator/V1.4/Prefix_Removal_Status) that has one spreadsheet – Prefix Removal status spreadsheet (Prefix_Removal_Status-.xlsx). This spreadsheet need to be reviewed once a prefix removal job is run.
- Cleanup mode -> Output directory named “Cleanup_Status” (VMware-AVI-Virtual-Service-Migrator/V1.4/Cleanup_Status) that has one spreadsheet – Cleanup status spreadsheet (Cleanup_Status-.xlsx). This spreadsheet need to be reviewed once a cleanup job is run.
- Logs for each job is saved in VMware-AVI-Virtual-Service-Migrator/V1.4/logs
Generate Planner Workbook Mode
- This is the first step in the migration process where we organize all the virtual services into migration batches. Virtual services that have similar migration requirements (like same target cloud account, VRF Context, SE Group and IPAM profile) will be a part of the same migration batch. Run the migrator tool in “generate_planner_workbook” mode to generate a spreadsheet having the details of all virtual services along with the corresponding cloud account, VRF Context, SE group, VIP, AVI tenant etc. This can be worked upon to organize the virtual services into migration batches along with a unique prefix ID (runID) for each migration batch.
Run ./virtual_service_migrator.py with the “generate_planner_workbook” subcommand -> python3 virtual_service_migrator.py generate_planner_workbook –help
This will launch VMware AVI Virtual Service Migrator help menu for the generate_planner_workbook mode. Follow instructions on the screen.
python3 virtual_service_migrator.py generate_planner_workbook -i <CONTROLLER_IP/FQDN> -u <USERNAME> -p <PASSWORD> -a <API_VERSION>
where
- CONTROLLER_IP/FQDN -> This is the VMware AVI Controller cluster IP/FQDN [MANDATORY]
- USERNAME -> This is the local “system-admin” user account to login to the VMware AVI Controller cluster. SAML authentication is currently not supported.[MANDATORY]
- PASSWORD -> This is the password of the above user account to login to the VMware AVI Controller cluster.[MANDATORY]
- API_VERSION -> This is the API version of the controller cluster. This is also the controller version (Eg:30.2.2) [MANDATORY]
Migration mode
- Run ./virtual_service_migrator.py with the “migrate” subcommand. -> python3 virtual_service_migrator.py migrate –help
This will launch VMware AVI Virtual Service Migrator help menu for the migrate mode. Follow instructions on the screen.
python3 virtual_service_migrator.py migrate -i <CONTROLLER_IP/FQDN> -u <USERNAME> -p <PASSWORD> -a <API_VERSION> -t <NSX_ALB_TENANT> -c <TARGET_CLOUD> -r <TARGET_VRF_CONTEXT> -s <TARGET_SERVICE_ENGINE_GROUP> -d <TARGET_APPLICATION_DNS_DOMAINS> -n <TARGET_IPAM_NETWORK_NAME> -S <TARGET_IPAM_SUBNET> -P <OBJECT_PREFIX/RUN-ID>
where
- CONTROLLER_IP/FQDN -> This is the VMware AVI Controller cluster IP/FQDN [MANDATORY]
- USERNAME -> This is the local “system-admin” user account to login to the VMware AVI Controller cluster. SAML authentication is currently not supported.[MANDATORY]
- PASSWORD -> This is the password of the above user account to login to the VMware AVI Controller cluster.[MANDATORY]
- API_VERSION -> This is the API version of the controller cluster. This is also the controller version (Eg:22.1.4) [MANDATORY]
- NSX_ALB_TENANT -> This is the VMware AVI Tenant where the migration needs to be performed. [MANDATORY]
- TARGET_CLOUD -> This is the target VMware AVI Cloud connector name [MANDATORY]
- TARGET_VRF_CONTEXT -> This is the target VRF Context (under the target cloud connector) [MANDATORY]
- TARGET_SERVICE_ENGINE_GROUP -> This is the target Service Engine Group (under the target cloud connector) [MANDATORY]
- TARGET_APPLICATION_DNS_DOMAINS -> This is a comma separated list of DNS subdomains to create the application DNS records. These subdomains should be a avaialble in the DNS profile attached to the target cloud connector. [OPTIONAL]
- TARGET_IPAM_NETWORK_NAME -> This is the name of the network used for VIP auto-allocation. This network should be available in the IPAM profile attached to the target cloud connector. [OPTIONAL]
- TARGET_IPAM_SUBNET -> This is the subnet available on the network for VIP auto-allocation. This subnet should have IP pools defined for VIP allocation.[OPTIONAL]
- OBJECT_PREFIX/RUN-ID -> This is the prefix that will be attached to the migrated objects. This prefix should be unique for each migration job as this will be used for job tracking and cleanup mode.[MANDATORY]
Remove prefix mode
- Run ./virtual_service_migrator.py with the “remove_prefix” subcommand. -> python3 virtual_service_migrator.py remove_prefix –help
This will launch VMware AVI Virtual Service Migrator help menu for the remove_prefix mode. Follow instructions on the screen.
python3 virtual_service_migrator.py remove_prefix -i <CONTROLLER_IP/FQDN> -u <USERNAME> -p <PASSWORD> -r <OBJECT_PREFIX/RUN-ID>
where
- CONTROLLER_IP/FQDN -> This is the VMware AVI Controller cluster IP/FQDN [MANDATORY]
- USERNAME -> This is the local “system-admin” user account to login to the VMware AVI Controller cluster. SAML authentication is currently not supported.[MANDATORY]
- PASSWORD -> This is the password of the above user account to login to the VMware AVI Controller cluster.[MANDATORY]
- OBJECT_PREFIX/RUN-ID -> This is the run-ID that was used for the previous migration job. [MANDATORY]
This will automate the removal of prefixes attached to the migrated objects. This needs to be done post cutover of virtual services (ie, after the migrated virtual services are enabled and the old virtual services are deleted).
Cleanup mode
- Run ./virtual_service_migrator.py with the “cleanup” subcommand. -> python3 virtual_service_migrator.py cleanup –help
This will launch VMware AVI Virtual Service Migrator help menu for the cleanup mode. Follow instructions on the screen.
python3 virtual_service_migrator.py cleanup -i <CONTROLLER_IP/FQDN> -u <USERNAME> -p <PASSWORD> -r <OBJECT_PREFIX/RUN-ID>
This will cleanup all the objects that were migrated as part of the specific migration batch (runID)
Note: Use this mode with caution as it deletes all the objects that were migrated as part of the specific migration batch. If cleanup job is done post cutover of virtual services, you will end up in a scenario where both the original and migrated objects are lost.
Project Repository
The entire project is hosted in Github, please checkout the instructions in the Readme document before using the migrator tool.
Project repo: https://github.com/harikrishnant/VMware-AVI-Virtual-Service-Migrator
ReadMe: https://github.com/harikrishnant/VMware-AVI-Virtual-Service-Migrator/blob/main/README.md
Release Notes: https://github.com/harikrishnant/VMware-AVI-Virtual-Service-Migrator/blob/main/RELEASENOTES.md
References:
Here are the links to blog articles on the previous releases, in case you wish to check out.
Migrate virtual services of type “Normal”:
https://vxplanet.com/2023/07/11/my-python-project-nsx-alb-virtual-service-migrator-release-update-v1-2-part-2/
Migrate virtual services of type “Enhanced Virtual Hosting” or “SNI”: https://vxplanet.com/2023/09/18/migrating-tls-sni-and-evh-hosting-across-cloud-accounts-in-nsx-alb/