Configuring FirstBootDevice for Gen2 VM Templates

Since Microsoft announced “Generation 2” VMs in Hyper-V with Windows Server 2012 R2, many people have made this the default generation for all their new VM deployments.

And of course, when using VMM, you are creating VM templates based on Gen 2 base OS.

For more information about Gen2 VM and the support in Virtual Machine Manager, go ahead and read a blog post I wrote earlier, on what this really is, what it means and how to create them with VMM: http://kristiannese.blogspot.no/2013/11/how-to-create-gen2-vm-with-scvmm-2012-r2.html

During the past few months, we’ve seen several threads in the VMM forums at TechNet that several users have troubles with deployment of Gen2 VMs.

It was hard to detect the root cause, as many people had created their VMs outside of VMM, with either FCM, Hyper-V Manager or Hyper-V Manager cmdlets, or other deployment tools.

However, there was a trend and Microsoft published a kb recently.

When you use System Center 2012 R2 Virtual Machine Manager for template creation, you may discover that Generation 2 virtual machines (VMs) based on this template cannot start after creation. Virtual Machine Manager returns the following error:

Error (23352) VMM cannot find the device or this device is not valid for a boot device.

Read the entire kb: http://support.microsoft.com/kb/2955362

To resolve this issue, you must change the VM template, and this can easily be done through PowerShell:

Get-SCVMTemplate –name “yourGen2TemplateName” | Set-SCVMTemplate –FirstBootDevice “SCSI,0,0”

This will ensure that the VMs you deploy based on this template, will successfully start.

Many of my customers runs big datacenters and have a lot of templates that they use together with tenant portals, like Azure Pack or something they developed by themselves.

The list of templates can be huge, so we should carefully look at our templates so that we don’t configure this for our Gen1 templates, as this change would result in a bad experience for those (Gen1 requires IDE controller to start).

First, we use the VMM module to search for all of our Gen 2 templates that have anything but SCSI as their FirstBootDevice:

Get-SCVMTemplate | where-object {$_.FirstBootDevice -cnotcontains "SCSI,0,0" -and $_.Generation -eq "2"} 

If this results any VM templates, then you should follow up with piping that into: Set-SCVMTemplate –FirstBootDevice “SCSI,0,0”

Get-SCVMTemplate | where-object {$_.FirstBootDevice -cnotcontains "SCSI,0,0" -and $_.Generation -eq "2"} | Set-SCVMTemplate -FirstBootDevice "SCSI,0,0" 

Now, make sure your Gen2 VMs are configured correctly.

Site Recovery in Microsoft Azure

Announced during the keynote of TechEd, Microsoft will let you use their scalable datacenters across the world as a secondary site.

To put this simply, you will be able to use Microsoft Azure as a site for disaster recovery.

This is brilliant news, and has been requested by millions of users world wide since the release of Hyper-V Recovery Manager.

Hyper-V Recovery Manager was introduced as an “orchestrator” for your DR solution, based on Hyper-V in Windows Server (which includes Hyper-V Replica – the key feature here) and System Center – Virtual Machine Manager.

Here’s a recap of how it works.

You sign-up to Azure and download a provider that will connect your VMM management stamp to your subscription, and your Recovery Vault in Microsoft Azure.

This will also add some changes to VMM, reflected in the GUI.

After configuring a DR enabled Cloud (a cloud created in VMM), the metadata will be sent to Azure where the recovery manager serves as a control panel and orchestrator for your DR solution.

Hyper-V Recovery Manager (HRM) will configure your stand-alone hosts and clusters (through VMM) and enable Hyper-V Replica if stand-alone servers, and Hyper-V Replica Broker if clustered.

The takeaway is that you can manage all of your DR enabled virtual machines running in these clouds, as an entity. Also, you can create recovery plans for a subset (if not all) virtual machines and ensure that the failover will include every server, application and service that requires to run in case of a failover of an entire business application.

For a complete guide on the setup, please see a blog post I wrote earlier, available here!

Here’s a high-level overview of a quite common environment, where you have a tier 1 production site, and a tier 2 recovery site – both on-premise.

In addition, Microsoft Azure (at the top) can be a secondary site and Hyper-V Recovery Manager will orchestrate the recovery plans for your environment.

This is a big step in the right direction when it comes to our hybrid cloud story.

Not only use the service itself from Azure, but also extend – and use the capacity in Microsoft Azure to run your infrastructure.

I will follow up this blog post later with technical details around architecture, tips & tricks, and how to implement this to an already existing DR solution, based on Hyper-V, VMM and HRM.

Re-associate your managed computers with VMM

Very often, I meet customer who has started with a single VMM management server.

That is all fine, because normally, these VMM servers (and the other SC components) are running as virtual machines on a Hyper-V Cluster, and ideally, it is a dedicated management cluster for those kind of workloads.

This was all good and great with VMM until the 2012 R2 release.

Since more and more business critical functions has been moved over to Virtual Machine Manager, the more important it becomes in your cloud fabric.

To highlight some few:

·         VMM act as a network controller when using network virtualization

·         VMM is the backend for your cloud, using Service Provider Foundation and Windows Azure Pack

·         VMM feeds SCOM with business critical information from a performance and monitoring perspective

·         VMM is responsible for optimization of your Hyper-V hosts, through Dynamic Optimization and Power Optimization

There are many more things to highlight in this context, but I guess you get the point. VMM is the key management layer in your datacenter.

In a nutshell, this is the process to shift from a single VMM management server, to a Highly Available VMM management server.

1)      Take a backup of the VMM database. First thing first.

2)      Uninstall the VMM server (please remember to retain the database during the process)

3)      You have already a Windows Failover Cluster installed on your nodes where you want to run VMM (yes, this can be a virtual guest cluster).

4)      Install VMM on your cluster and create a highly available VMM service – follow the instructions from TechNet, and use the existing SQL database containing your VMM data. This database can also be moved to a SQL cluster, or a different instance.

5)      You now have a HA VMM server

But what’s next?

You should re-associate your managed computers with the HA VMM server. Your HA VMM server has most likely a new name (this is a computer object too) and your will see some communication problems between VMM and its managed servers

The solution can easily be found in the shell:

$Credential = get-credential

Get-VMMManagedComputer | where {$_.State -eq "NotResponding"} | Register-SCVMMManagedComputer -Credential $Credential

You should now have a healthy fabric again.

Creating checkpoints with VMM cmdlets

Recently, a customer asked me a question.

“How can we easily create snapshots on every virtual machine created after a specific date, that are currently running?”

I really like these questions, because it let me show how powerful System Center’s powershell cmdlets can be.

This is related to System Center Virtual Machine Manager, and if we dive into the module, I’ll show you what I found.

The interesting part here is that the customer would this to happen if the virtual machines are created after a specific date, and is in a running state, meaning that someone is most likely using – and paying for those virtual machines (especially interesting if they are using Windows Azure Pack).

If we run the following cmdlet, we can see the different properties related to “Get-SCVirtualMachine”

As you can see, we have a property called “AddedTime” together with “Status”.

Instead of putting steroids into this simple task, by creating a script, I am much more interesting in solving these simple tasks with the shell itself. In the end of the day, that is what Powershell is all about. Solve complex tasks and time-consuming tasks (if doing it manually) with a one-liner!

So here’s the cmdlet that will create checkpoints on every running virtual machine, created after a specific date.

Get-SCVirtualMachine | Where-Object {$_.AddedTime -gt "04-30-2014" -and $_.status -eq "Running"} | New-SCVMCheckpoint -Description "Checkpoint of VM created after a given date" -ErrorAction Ignore – RunAsynchronously

That’s all for now, but I’ll share other cool stuff you can perform in your cloud fabric with VMM cmdlets later.