Summary: Microsoft PowerShell MVP, Sean Kearney, talks about importing multiple virtual machines with Windows PowerShell in Windows Server 2012.

Microsoft Scripting Guy, Ed Wilson, is here. If you are a seasoned Hey, Scripting Guy! Blog reader, you know that the most frequent guest blogger is Sean Kearney. If you are new to the blog, I welcome you, and I encourage you to catch up with Sean’s previous blogs.

Sean is a Windows PowerShell MVP and an Honorary Scripting Guy. Sean has been selected to present sessions called Integrating with Microsoft System Center 2012 and Windows PowerShell at TechEd NA and TechEd Europe this year. In his free time, Sean has written several blog posts about Hyper-V and some other cool stuff, and for the next few weeks, Sean will be the designated guest blogger on Fridays. Take it away Sean…

Now let’s get back to my problem…some consistency for TechEd.

In my last blog, Export Multiple Virtual Machines with Windows PowerShell, I had a nice easy and consistent way of exporting virtual machines from Hyper-V. Now of course, I would like to reverse that process. Wouldn’t it be beautiful if I could simply point to a folder of virtual machines and say, “Import!”

Well, with Windows PowerShell, I can.

My first task was to see how the Import-VM cmdlet worked. So off to my favorite friend in the whole wide world (next to Doctor Scripto, that is)—Get-Help.

GET-HELP IMPORT-VM

And look at the output it brings me:

So I sat down to play with the Import-VM cmdlet to see what worked best for me. I know I can just “run with defaults” as in the following example:

GET-HELP IMPORT-VM -examples

However, I prefer to have control and be specific about all the details. So first I wanted to know the physical location of my Hyper-V defaults for the path of the virtual machine configuration and the virtual machine hard disks.

To obtain this information, you can run the Get-VMHost cmdlet:

$VMhost=GET-VMhost

When I had this stored away, I ran Get-Member to find which of the available properties might have the correct details.

$VMHOST | GET-MEMBER –membertype Property

Near the bottom, I could see two properties that matched my liking: VirtualHardDiskPath and VirtualMachinePath. I confirmed by piping them through Select-Object to see if they had the data I needed:

$VMHost | SELECT-OBJECT VirtualHardDiskPath, VirtualMachinePath

They had what I needed, so I stored them away for future use.

$VMDefaultPath=$VMHost.VirtualMachinePath

$VMDefaultDrive=$VMHost.VirtualHardDiskPath

The next challenge wasn’t so tricky…point at a folder structure of a virtual machine (or machines for that matter) and identify each .exp file from the original exports. Hello Get-ChildItem:

$VMLIST=GET-CHILDITEM G:\Export -recurse –include *.exp

…where G:\Export is my folder that contains a virtual machine export or exports from Hyper-V.

I then played with the Import-VM cmdlet to get the right combination to match a default import of a virtual machine to a defined hard disk and configuration path. Spending this extra time meant that I could easily adapt the script later to point to nonstandard paths if I so choose.

I could then step through a list of machines found in the following manner:

$VMlist | FOREACH { IMPORT-VM -path $_.Fullname -Copy -VhdDestinationPath $VMDefaultDrive -VirtualMachinePath $VMDefaultPath -SnapshotFilePath $VMDefaultPath -SmartPagingFilePath $VMDefaultPath -GenerateNewId }

With this in place, I can always have a consistent way of importing my virtual machines. When done, I simply attach these machines to the current network by using the Connect-VMSwitch cmdlet.

The coolest part is it worked just as well with Windows Server 2008 R2 exports, providing there were no Hyper-V snapshots.

Feel the Power within you.

~Sean
The Energized Tech

Thank you, Sean, for a great post. Join me tomorrow for more cool Windows PowerShell stuff.

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

Ed Wilson, Microsoft Scripting Guy