Automation–Service Management Automation Runbook Spotlight–Virtual Machine Startup by Priority (Part 1.5)

  • Article

Hello Readers/Viewers!

Before we get into this post’s content, I wanted to extend a BIG THANKS to those of you who have been keeping up with our System Center 2012 R2 Service Management Automation Introductory Blog Posts. To make things a little easier, and to keep track of all those posts in one area, we have made a simple link to use and share:

https://aka.ms/IntroToSMA

SMA

Background

Now, with that out of the way, let’s get into the reason for this post: Outlining both the need for and reference to a pre-requisite for my follow-up post to: Automation–Service Management Automation Runbook Spotlight–Virtual Machine Startup by Priority (Part 1)

In that first post, I provided SMA Runbook examples based on an older Orchestrator post which accomplished the same tasks. It is what I consider a “simple” example for Virtual Machine Startup by Priority. Part 2 of this blog mini-series will provide a more advanced example – and with increased complexity, comes the need for more pre-requisites. That is what this post is all about. Well, that and an explanation of the complexity…

In fact, usage of this new method is all in an effort to move away from using the Delay start up (seconds) values with Start-Sleep actions as a guess to when VMs are actually started. Part 2 of this blog mini-series leverages a much more elegant (and thus complex) solution, leveraging Priority Startup Groups and an actual check of Hyper-V Integration Service Status (much like how the new Hyper-V Recovery Manager functions during failover).

Note This is why this post should be considered, Part 1.5 (of 2).

So, what is this new complexity?

Simple – usage of stored data.

Much like Orchestrator, SMA doesn’t have a concept of “state” (other than what is in the logs and manipulated with SMA Variables). After all, SMA is an automation solution which stores, compiles, and executes PowerShell v3 Workflow. For Part 2 of this blog mini-series, I needed a way to access stored information, namely container (or Cloud) level Startup Priority Groups and VM level Startup Group information. Where Startup Priority Groups contains the overall distinct count of Startup Group values; and Startup Group values describe the actual priority for each VM in the Startup process.

In other words:

image

The idea of leveraging Startup Priority Groups for Virtual Machine Startup came as part of a recent, larger provisioning process that my team is currently developing. This provisioning process centered around an XML file for all Virtual Machine specific data storage and retrieval. See a trimmed down example of the XML for Virtual Machine Startup Priority here:

image

Note XML data retrieval will not be the method used for Part 2 of this blog mini-series, but I wanted to make sure the example was available in case any one was interested.

The data was accessed from the XML file for the VM Startup process – basically, the PowerShell Workflow in the SMA Runbook created a hash table with the VM Startup Priority and an array of corresponding VM Names. See the example PowerShell below for how this was accomplished using an XML file for data access:

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 InlineScript { $XmlFile = $Using:XmlFile $XML = #This was defined by an Invoke-Command to access an XML file used in the example $StartupPriorityGroups = $XML.Body.Metadata.StartupPriorityGroups if ($StartupPriorityGroups -gt 0) { $StartupGroupList = @{} for( $i = 1; $i -le $StartupPriorityGroups; $i++ ) { $VMList =@() foreach ($VMitem in $XML.Body.VM) { if ($i -eq $VMitem.StartupGroup) { $VMList += $VMitem.Name } } $StartupGroupList.Add($i,$VMList) } Return $StartupGroupList.GetEnumerator() | Sort-Object Name } else {Return $null} }

Note This is just a snippet from the overall solution, thus Variables referenced with $Using:VariableName do not have their original parameters defined as part of the above script. The logic to pay attention to (which is shared by the method I will illustrate in Part 2 of this blog mini-series) is in Lines 8-23 above.

Got it, what is the new method?

Again, simple – leveraging VMM Custom Properties.

This was an automation concept that I introduced for data storage and retrieval in my old Orchestrator post, Automation–Orchestrating Hyper-V Replica with System Center for Planned Failover. I still believe the best place for this kind of Cloud and VM specific data (if you can get away with it) is in VMM itself.

So, the same data referenced above (stored in the XML file) will now be stored and accessed in and from VMM, as VMM Custom Property data that you will have the opportunity to define and manage.

Good News, Everyone!

I have refactored the example Orchestrator Runbooks for that portion of the old solution into PowerShell v3 Workflow (which directly translates to SMA Runbooks).

With my examples, you will be able to do the following tasks via PowerShell v3 Workflow and/or SMA:

  • Create VMM Custom Property
  • Update VMM Custom Property Value
  • Get VMM Custom Property Value
  • Remove VMM Custom Property Value
  • Remove VMM Custom Property

Note I have PS1 file examples for each of these tasks which can be imported directly into SMA. I have published a second blog post dedicated to these “Utility” Runbooks with an associated TechNet Gallery Contribution for download.

So, here it is, the post that you have been waiting for (and you didn’t even know about it yet):

Automation–Service Management Automation–Utility Runbook Spotlight–VMM Custom Property Management

That’s it! I hope this “Part 1.5” post explained some things and why I am making a 4-post, 2-part mini-series. ;)

Oh, and if you want more examples for SMA and PowerShell v3 Workflow, be sure to check out this list (to be updated as more examples are provided):

And for more information, tips/tricks, and example solutions for SMA, be sure to watch for future blog posts in the Automation Track!

enJOY!