Tenant Migration with vRealize Suite Lifecycle Manager 8.3

vRealize Lifecycle Manager 8.3 allows customers on existing vRealize Automation 7.5 and 7.6 deployments to migrate tenants and tenant data to vRealize Automation 8.2 Patch 1 or higher. This compliments the migration process available with vRealize Automation Migration Assistant. Used together, customers can now easily migrate their tenants (i.e. directories, custom groups, etc) as well as the content (Business Groups, Blueprints, Deployments, etc) in a few steps. In this blog post I will describe a simple scenario of migrating an existing vRealize Automation 7.6 multi-tenant instance to 8.2.

An Example Scenario

Tenants and tenant data are migrated from the embedded vIDM in vRealize Automation 7.5 and 7.6 to the Global Environment of vIDM 3.3.4 and later. Specifically, the following data is migrated:

• Tenants
• Directories
• Custom groups
• Roles and rule set
• User attributes
• Access policies
• Network ranges
• Third-party IDP configurations

Tenants can either be migrated or merged with the target environment and both methods can be used together in a complementary way. I will explain the differences between these methods and the use cases for each.

Consider the case where there are three tenants Alpha, Beta and Gamma. I have installed a brand new vRealize Automation 8.2 Patch 1 instance and have done no initial configuration (no Cloud Accounts, Directories, etc). While you can migrate to a populated vRealize Automation 8.2 instance, I am only showing a green field approach for simplicity.

The desired outcome of the migration is to create migrate Alpha and Beta tenant to a new vRealize Automation 8 org, while Gamma will be merged with Alpha. In this blog, I am only doing this from a single vRealize Automation 7.6 instance but these tenants could also originate from different instance.

Note the directories used by each tenant and the new tenant organizations in vRealize Automation 8.2:

Before you begin, there are some pre-requisites:

• vRealize Automation 8.2 must be at Patch 1
• Import the vRealize Automation 7.5/7.6 environment into vRealize Suite Lifecycle Manager
• VMware Identity Manager in the Global Environment of vRealize Suite Lifecycle Manager must be at version 3.3.4
• Sync inventory on all vRealize Automation environments involved in the migrations (target and source) before beginning
• Consult KB article 81219 for instructions on providing remote access to the source vRealize Automation Postgres database from the target vIDM hosts
• Enable Multi-Tenancy if required (as it is in this example case)

Let us step through the migration.

Tenant Migration

This migrates data from the 7.6 source instance and is a one-time operation, so plan ahead with regard to the directories you wish to migrate. Only one tenant can be migrated at a time.

The process begins from the Identity and Tenant Management service. Under Tenant Management you will find a tab for Tenant Migrations. Click the MIGRATE TENANT button to begin:

A helpful flowchart appears to explain the process and outcomes.

Now it is time to select the environments and tenants. After selecting the source environment, vRSLCM will populate the Tenant Mapping for that source. Notice here I have not completed any migrations. Alpha tenant will be our first “legacy vRA” tenant to move.

Next, you will need to select the method you wish to use, migration or merge. Again, helpful diagrams explain the differences between these two methods.

After selecting a method (in my case Alpha will use Tenant Migration), you will be presented with a list of pre-requisites that must be completed manually, and they are explained in the documentation and in the user interface workflow.

The tenant migration process migrates third-party identity provider configurations. After the tenant migration, you must copy the VMware Identity Manager service provider metadata manually to the external third-party identity provider.

You will also provide details for the new local user which will be the org admin. This user must not already exist in the source tenant, so you will need to use a unique username. The note says it’s “suggested”, but it’s required (pre-check will fail).

I already have an admin [email protected] – so I cannot use the same name and I used aalpha1 instead. More on this later.

Since this is a one-time operation, you should select all source directories you wish to migrate. Otherwise, you will need to migrate any additional directories manually, which is entirely the thing you are trying NOT to do. By the way, I experimented with various configurations and methods in my lab. I found that if I deleted and redeployed the vRealize Automation 8 environment I could restart a migration to try something different. This might save some time when testing this out (that is unless you test in production, in which case you have my sincere best wishes for a new career outside of IT).

In this example, I’m migrating the local directory as well as the VMware AD. You will need to provide the bind password for this migration. It’s not stored, and is only used for the migration. Validate and you can move on.

One thing I really appreciate about vRealize Lifecycle Manager is the prechecks. They are really thought out and complete, provide great insight on how to fix failed checks and generally keep me from doing stupid things.

The precheck will find any potential issues with the migration and you will need to address those before you can start the migration. Notice the failure regarding the vRealize Automation database access. You will find KB 81219 helpful in addressing this. By the way, when you follow that KB, be sure to use “/32” in the trust statement. I thought that this was supposed to be the netmask (“/24” in my case) and while the connection test worked, the pre-check failed (as you can see below). This is because the precheck doesn’t actually test the connection, but rather inspects the pg_hba.conf file on the source host for the trust statement (i.e. “host all all 10.176.203.6/32 trust”).

Also note what happens when you don’t specify a unique local username for the tenant admin in the Tenant Details step – so, yes, it’s a requirement.

Notice the first failure below regarding SSL. The tenants must meet certificate requirements and in my case I solved it by updating the wildcard certificate on the target vRealize Automation environment with a SAN certificate shown in the next image below. Your organization may have different requirements and policies for SSL, so I will not go into the “how to” of certificates, CSRs and so forth.

Once your precheck passes all checks you are ready to go.

After the migration, you will find that you have two new tenant admins. In the source environment, there were two tenant admins in the source (John and Anne). Recall that we also created another account for Anne with the username “aalpha1” and you can decide which to keep. There is also an account during the request to manage the migration. This can be deleted as well.

Any local users migrated will need to have a valid email address (which is why you see my email address used so much in these examples). This is so vRealize Suite Lifecycle Manager can send a nice welcome message with instructions on setting their password in the Global Environment vIDM. An example is shown below.

This completes a tenant migration. You can now use the vRealize Automation Migration Assistant to move the infrastructure content.

Tenant Merge

Continuing with our use case, we would like to consolidate the Gamma tenant with Alpha in the new environment. Merging is a much simpler operation as it does not migrate any directory information.

After selecting the “Merge” option in the previous step (not shown), I am now asked which tenants to merge. A couple of important bits of info on this screen, which are self-explanatory. But let me emphasize here that the merge does not bring over any directory information. The assumption is that the users and groups are already available in the target tenant. Since Gamma uses the same directory as Alpha, this is not a problem for this situation.

That is it, click through to start the merge. After the merge is completed, you will need to edit the Source Instance in vRealize Automation Migration Assistant and toggle the new tenant for migration. Perform and update and you can then migrate the merged tenant’s infrastructure and deployments.

I believe you will find that vRealize Suite Lifecycle Manager 8.3 makes the move from vRealize Automation 7.5 and 7.6 to 8.2 much easier. For information on continuing the migration to vRA 8.x please read this blog on How to Migrate from vRA 7.5/7.6 to 8.2 Today.