System Center Virtual Machine Manager 2012 R2: Cloud Delegations, VMs, and Templates

The light at the end of the tunnel is now getting very bright. Our tenants are registered and the clouds have formed nicely, in this final post in our multi-part series on the migration efforts to get us to System Center Virtual Machine Manager 2012 R2 (SCVMM 2012 R2), we will delegate our new clouds to the tenants. Once the clouds have been shared we will re-establish the quota on these, then finally we need we will assign all the VMs back to their respective clouds and tenants.

Wrapping up, we will then address the VM templates, migrating these to the target environment (which in reality was a lot more difficult than I had initially expected), and finally delegating permissions to the templates enabling our tenants to once more deploy infrastructure, hosted on our fresh new SCVMM 2012 R2 environment.

(Editor’s note: Need to catch up? In part one, we upgraded to System Center Virtual Machine Manager 2012 R2. In part two, I provided an overview of migrating to SCVMM. In part three, we looked at how to migrate the hosts and library.)

Delegate Clouds to Tenants

In an earlier step we exported a list of user roles from the source environment, we will leverage this export to get the clouds which are delegated to each tenant, as that information was contained in the export.

Target Import

On the target, the following script will reference the earlier generated UserRoles.csv file, and then loop trough adding all the clouds which are assigned to each user role.

Cloud Quota

Keeping our focus on the clouds, we will now proceed to export the quota details that were assigned to the clouds in the source environment. Place this detail into another CSV file, which you can edit if needed and then move forward by reapplying the details to the target environment.

Source Export

As this point the scripts are starting to look quite similar. This time we will grab the quotas for each, and using the loop, and post these into the CSV file for us.

Target Import

On the target side we need to be a little smarter, as there are two different quotas by default on each role – per-user and shared – so the import script needs to figure out with an IF statement which of these we are updating. After that we will either set the quota as unlimited or defined (but not both), so we will use more IF statements to get this correct.

Virtual Machines

Milestone time now: We are finally ready to start giving the virtual machines back to their respective owners. As with the earlier steps, we need to export all the metadata from the source environment, place all this into a CSV file, and then take all this rich information and use it on our target environment to assign the updates to our machines in our target environment. As with all of our scripts so far, this exercise will should begin to feel quite comfortable, so we just need to make the necessary adjustments to gather the relevant information.

Exporting Source

This time we will create a CSV file called VMs.cvs, which will contain some of the basic details, such as operating system, quota points, user roles, clouds, owners, and so on. What I don’t export is stuff like custom data, etc., but as you can figure out, it is not to difficult to extend these functions to get as much or as little as you like!

Target Import

Back on the target environment, we will go ahead and work the CSV file as we determine the name of the VM which needs to be assigned. Then, using the information in the export, we simply use the Set-SCVirtualMachine command to apply the configuration setting.

Virtual Machine Templates

With the launch of SCVMM 2012, Microsoft enabled the ability to export library resources to XML files with the use of a simple console wizard. This wizard is available when you change to the Library view and select the VM Templates node in the navigation tree.

Exporting VM Templates

Once in this view, you can select all the templates presented, then from the Actions group on the ribbon select Export.

A new wizard will be presented, listing all the templates we just selected for exporting. We can choose the option Export any sensitive template settings to keep things like product keys and passwords in the exported data. I don’t recommend enabling the option to Encrypt the XML files, as we are going to need to do some work on these to migrate them to the target environment.

Simply specific the path to where you wish to have all the XML files exported (one per template) and click OK for VMM to being its procedure.

Importing VM Templates

Importing these templates can also be accomplished via the console on the destination server, but you are restricted to one at a time, which is no fun if you have 400 templates to address. Every template will also require that you attempt to map the virtual hard disk that is referenced in the template to an equivalent hard disk, which is now registered in your new library. Similar work will be needed also from some VM/logical networks.

As this procedure is so slow, and as the library we are referencing in our migration target is actually the same library that the source was using, we can save some time since the resource names should be unchanged.

The following script (created by my colleague Oscar Mazanares – thank you!) will enumerate all the XML files. Check to see what mappings are required and address these by using essentially the same resources from our new environment before finally completing the import process and moving any successfully processed XML files to a new folder. It does not cover 100 percent of the scenarios, but it addresses all of our requirements, including VHDs, vFloppies, and networks.

Lets begin by enumerating all the exported templates which have been placed in the folder that we will reference as $Source.

We need to create a holder, which we will use to ensure that we treat the template in the correct format.

$xml = New-Object XML
As we need to locate the virtual hard disks, floppies, and ISO files, which are referenced in the XML, the next three functions will be used as helpers to scan the library locations and send back a reference to the files when located so that we can mark-up the XML with the correct information as we prepare to import into VMM.

As an example of the flexibility we have available, we will create a reference to a VM network, and each time we find a specific network in the source XML template, we can easily replace it with the new reference, ensuring that during the migration we can easily modify the templates to match our target environment.

Next, use the VMM command to determine what resources are referenced in the template. Using this we will be able to check and fix any mappings necessary.

See if the template source was connected to a network called VLAN3000. If so, replace it with the reference to our newer VLAN202. Otherwise, as the networks are the same, we will leave the auto-mapping alone.

Using the reference from the mapping, we will use the helper function to locate the disk on our new libraries and update the mapping. This works since we did not rename any disk or other resources in the migration.

VM Template Delegations

We are about to implement the last stage of our migration (please don’t get too emotional). That is to take all the resources we just imported and assign them back to the tenants to which they are to be utilized. This last procedure is going to be an easy one, as it’s using the same approach we have used in a number of the steps previously, including exporting all the metadata to a CSV file, looping trough all this good detail, and reapplying the permissions to the templates on the target environment

Source Export

We do need a new CSV file for this one, which i have called VMTemplateDelegations.csv. This as you can now guess has the name of the template, the role which is it owned by, and the tenants whom are allowed to use the template. The loop is quite simple, and again it can be extended to export more details if needed, but this should address the needs of our migration keeping things lean and clean.

Target Import

For the final time on our target server we are pulling out the ever reliable loop one last time. At this point we need no additional narrative – just a short comment to confirm that we are reusing the Grant-SCResource command to make sure that the relevant tenant grabs access to the templates we imported just a short while ago.

Well, that was 18 steps of pain or fun, depending on how you look at this. However, one thing is for sure: You now have an environment that should be clean and agile, offering you the control you need to pick and choose what makes the cut and what hits the trash.

I hope you have found this series useful. If I can offer any more support, hit up the comments. But whatever you do, remember to plan well and sleep even better.

Related Topics:

  • System Center

    Don't have a login but want to join the conversation? Sign up for a Petri Account