Summary: Use Hyper-V cmdlets to identify missing network configurations in virtual machines.

 Hey, Scripting Guy! This week we are working on some business continuity and disaster recovery practices. One of the documents we are building involves how to rebuild a Hyper-V virtual machine in our Windows Server 2012 R2 environment. Can you tell me if there is a way to identify the configuration data for Hyper-V, specifically the network names in our virtual switches?

—BR

 Hello BR,

Honorary Scripting Guy, Sean Kearney here—filling in for our good friend Ed. He’s still digging around with some old scripts he found in the back room.

Note  This is the second post in a series. If you missed Part 1, see Recovering Virtual Machines in Hyper-V Server 2012 R2: Part 1.

Hyper-V Server 2012 and Hyper-V Server 2012 R2 include possibly the coolest cmdlet ever. It’s called Compare-VM. Compare-VM has a simple task. Look at a virtual machine’s configuration and see what’s missing from the Hyper-V box.

We used to sing a song like that as a kid when I was in school, “Which of these things is not like the other?” Well, that’s what Compare-VM does.

So let’s pretend that we spun up a brand new Hyper-V Server 2012 R2 box. We have copied the .xml files, VHDs, and all the configuration files from a previous Hyper-V virtual machine.

In Windows Server 2008 R2, if you did not export it in advance, you could get away with re-creating the virtual machine and re-attaching the VHD file. But if you didn’t have the network settings, the virtual machine would have to detect the network card, which meant the usual game of:

• Hope you have cached credentials.
• Cross your fingers that it wasn’t a domain controller.
• Wait…wait…wait…

But with Compare-VM, I can point to the file and obtain what’s missing on my Hyper-V box.

So let’s look at a sample virtual machine. I literally used a Robocopy to bring it to my brand new Hyper-V 2012 R2 Server box.

I’ve just run Compare-VM against an .xml file, and I get this output:

Notice the Incompatibilities property? Let’s access that property to see what it has to say for us. We see a message that reveals why the machine couldn’t connect:

If we expand the message, we’ll find a more revealing answer:

This means that the reason I can’t import this virtual machine and “make it work” on a new box is as simple as “the virtual network switch with the explicit name PublicNetwork does not exist.”

But rather than pulling down 150 individual virtual machines, individually accessing their configurations, and trying to pull the network names, we can simply script it.

We’re going to leverage the .csv file for this script. So ideally, we could have virtual machines that we recovered from a back-up or that we switched to a lab, and then pull out the missing network data:

$HyperVList=IMPORT-CSV C:\HyperVList.csv

$ImportErrors=Foreach ($Machine in $HyperVList)

{

            $VMError=(Compare-VM –path $Machine.XMLFile).InCompatibilities.Message

            [PSCUSTOMOBJECT]@{Machine=$Machine.Name;Error=$VMError}

}

$ImportErrors | Select-object Error –Unique

What this should give us is a nice simple list of missing network switches in our virtual machines. With this, we can re-create them by using Windows PowerShell.

But that’s a story for tomorrow…

I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Sean Kearney, Honorary Scripting Guy and Windows PowerShell MVP