System Center Virtual Machine Manager 2012 R2: Migrating Tenants and Clouds

Posted on December 2, 2013 by Damian Flynn in System Center with

We’re back with our series on System Center Virtual Machine Manager 2012 R2 (SCVMM 2012 R2)! In part one, I discussed upgrading to System Center Virtual Machine Manager 2012 R2. In part two, I gave an overview to migrating to SCVMM, and in part three, we went over migrating the hosts and library.

With all the resources for our new fabric now in place, its time to recreate all the meta-data which defines our environment. We will address SCVMM 2012 R2 and migrating tenants (roles), clouds, virtual machines, and library assets, along with all their respective associations.

Unlike the steps we have completed to date, we had the ability to primarily use loops to define the environment. However, now we will need to depend exclusively on the data that we’ll export from the original. We will now refer to as the source VMM environment as the foundation for our new environment, which we will reference as the target VMM environment.

Delegated Administrators

The first of the entities that I will create in my environment is actually quite simple. I only have a single delegated administrator, which is offered management of all my libraries and the hosts in the “Operations” group. To implement this, I use the following PowerShell

Self-Service User Roles

Our first export will be the existing user roles (or as otherwise known in VMM, tenancies) from the source environment. This export will contain the name of the role and its description. In addition, the parent user role along with all the AD accounts that are members of this role, the clouds available to the tenant, and the permissions that the tenant is allowed to execute.

Note: This export is primarily coded to export from 2012 and 2012 SP1. In the R2 version Microsoft has finally configured the tenant roles to have per-cloud permissions; therefore, if you plan to export for the R2 environment, you will need to adjust the script to capture permissions per cloud.

Source Export

All the export scripts will create a simple CSV file. The reason I have not chosen to use XML for this is to make the process a lot easier for you to edit the file if you choose to modify what is needed to be migrated between the source and target environments.

Our first script creates a CSV file called UserRoles.csv, which contains all the main metadata for our user roles. As you can expect, this script is to be executed on the source VMM environment; when complete, the generated CSV file transferred to the new VMM environment for reloading once any necessary edits are completed.

Target Import

Now, after we have produced our export file and switched our focus over to the new VMM environment, the following script will load up the CSV file and loop through its content. Each row of the file is then processed and executed with the New-SCUserRole command to create the role or tenant in the target environment.


Self-Service User Roles VM Networks

The next step in regenerating our target environment, is to export all the VM networks that are granted to each tenant role.

Source Export

Using a modified version of our first script, we will create a new CSV file called VMNetworks.csv which lists all of the networks assigned to a role

Target Import

On the target system, we repeat a similar looping process to read each line of the CSV, which will then select all the VM Networks we defined as we built out the target fabric, and assign these to the relevant tenants.

Export the Clouds

With the Roles in place with their associated networks, we will need focus on the Clouds, the process we will use should now be starting to feel familiar,

Source Export

Keeping the scripts simple, the next CSV we will generate is called Clouds.csv, and contains most of the important cloud metadata. Information that we will place in this file includes the name and description of the cloud, the primary user role, all the associated logical networks, and any other attached resource assigned to each of the clouds.

Target Import

On the target system, in a quite similar manner to the previous loads we completed, simply iterate through the content of our CSV file. Using some static information such as our port classifications, and storage classifications, we use both the Set-SCCloud and New-SCCloud commands in a job format to establish and define the target clouds. Also, to keep this moving, we allow VMM to run the procedure asynchronously.


Next Steps

At this point we are about three-quarters of the way through to completing our migration activities. You should be able to perceive the flexibility with which the migration path offers you as you get to pick and select which elements from the source VMM environment you wish to have reestablished in the destination VMM environment.

In the next batch of steps, we will enable the delegation of the new clouds to their respective tenants, reapply the quotas on our clouds, and of course finally update our virtual machines so that they are assigned back to their respective owners, tenants, and clouds.

Tagged with ,

Register for this Webinar

How Replication Supports Your Company’s RTOs & RPOs
Join us for this free webinar

Can you have your workloads running within the agreed RTOs? Join this webinar with expert speakers from Veeam to exceed business objectives with an RPTO<15 min for ALL of your application and data.

Thursday, December 14, 2017 at 11 a.m EST