Get-VM | Export-VM -Path "F:VirtualMachines"

That command exports all of the Hyper-V virtual machines from my old laptop and copy them to the external hard drive. After plugging in the external hard drive to the new laptop, I copied the entire folder to the D: drive. Once the copy process was completed, I imported all of the virtual machines into Hyper-V.

PS D:VirtualMachines> Get-ChildItem -recurse *.xml | Import-VM

Pretty slick especially when you’re dealing with several Hyper-V 3.0 virtual machines that you need to copy from one machine to another. And, as always, the simplicity of a one-liner command is what I use to convince IT administrators to start playing around with Windows PowerShell. Exporting and importing my Hyper-V virtual machines only took less than 20 minutes.

I wrote a PowerShell command to query the current state of the VMs running on Hyper-V

Get-WMIObject -class "MSVM_ComputerSystem"-namespace "rootvirtualization"-computername "."

This will actually display a bunch of information about the VMs running on Hyper-V but what we’re really concerned about is the name of the VM and it’s currently running state. These two properties are associated with the ElementName and EnabledState attributes of the MSVM_ComputerSystem class. All we need to do with the command above is to pipe the results to a Select-Object cmdlet, specifying only these two properties, as follows

Get-WMIObject -class "MSVM_ComputerSystem"-namespace "rootvirtualization"-computername "." | Select-Object ElementName, EnabledState

While the EnabledState property will give you a bunch of numbers, I’m only concerned with those values equal to 2, which means that the VM is running. But, then, you might not remember what the value 2 means. So might as well write an entire script that checks for the value of the EnabledState property. I’ve used the GWMI alias to call the Get-WMIObject cmdlet

$VMs = gwmi -class "MSVM_ComputerSystem"-namespace "rootvirtualization"-computername "."
foreach ($VM IN $VMs)
{
switch ($VM.EnabledState)
{
2{$state="Running" }
3{$state="Stopped" }
32768{$state="Paused" }
32769{$state="Suspended" }
32770 {$state="Starting" }
32771{$state="Taking Snapshot" }
32773{$state="Saving" }
32774{$state="Stopping" }
}
write-host $VM.ElementName `,` $state
}

On a side note, make sure you are running as Administrator when working with this script as you will only see the VMs that your currently logged in profile has permission to access. Running as Administrator will show you all of the VMs configured on your Hyper-V server

But my dilemma didn’t stop there. I obviously don’t want to access the internet via the Windows Server 2008 platform. That’s what my Windows XP virtual machine is for. So what I did was to add an Internal virtual network using Hyper-V’s Virtual Network Manager. This will create another network adapter on the host operating system – in this case, Windows Server 2008. I’ve renamed this WiFi-Guest-Bridge. Next, I’ve added a network adapter on the Hyper-V guest and mapped it to this virtual network. Once, I’ve done both of these, I’ve bridged the wireless network adapter and the WiFi-Guest-Bridge network adapter, thereby, providing wireless connectivity to my Hyper-V guest.

Keith Combs provided a step-by-step procedure (with screenshots) on how to configure wireless networking with Hyper-V guests in his blog

It is very important to name your network adapters accordingly as Windows does a real good job of using a generic naming convention (i.e. Local Area Network x) which adds confusion especially if you are dealing with a ton of virtual networks from within a single Hyper-V (or other virtualization) platform