Hyper-V for the ESX Engineer

Aaron Delp over at BladeVault.info recently published a good article on Hyper-V for the ESX Engineer.

Read it below.

I just attended a great session on Microsoft Hyper-V.  Before I go into my notes, let me give you my background to better frame this post.  I used to be an MCSE (NT4!) but I really haven’t touched Microsoft products in a number of years.  My focus has been on hardware architecture and eventually this has led me into the virtual architecture as it has gained acceptance into the market place.  If some of my highlights seem a little different than most posts out there, it is because I am making the ESX to Hyper-V mapping in my head.  I know ESX, I don’t know Windows Server 2008 (or 2003 for that matter).

With that out of the way, here are my points of interest in no particular order.

• Hyper-V is paravirtualized – paravirtualized means the virtual machine is “aware” (Microsoft uses the term enlightened) that it is virtualized.  If the machine isn’t enlightened, it will run in emulation mode.  Emulation mode requires a lot of context switching between user mode and kernel mode.  This will understandably slow down performance.
• The Hyper-V “Service Console” is referred to as the Management Partition.  This is a Windows VM with privileges into the kernel that other VMs do not have.  This (at least on the surface) is similar to ESX’s Service Console.
• It is recommended to run Hyper-V on Windows Core (stripped down version with no GUI).  The core version will consume less resources, require less patches, etc.
• Server 2008 has “roles” that determine the functions on the server.  Hyper-V is recommended to be the only role on the server for production
• Hyper-V does not share memory pages
• Hyper-V has quick migration instead of VMotion.  Instead of a live migration, the machine is suspend and resumed on another host.  The amount of memory will have a direct impact on the amount of time required because the memory contents will written to the disk and then read from the disk on the new host.
• Hyper-V relies on Microsoft Clustering Services right now to provide multiple host functionality for SAN connected virtual machines.  This means that Enterprise Edition is the minimum required OS level for the host to perform Quick Migrations
• It is recommended that each LUN contain only one VM.  Space needed will be disk space required + virtual RAM assigned to the machine (for quick migrations) + room for snapshots of the virtual machine
• Live Backups of a VM are supported through VSS if the guest OS is VSS aware
• Virtual Hard Disk files are .vhd files instead .vmdk files for ESX
• Raw Device Mapping (RDM) in ESX is called Pass Through Disks in Hyper-V

At the end of the session we briefly covered the Microsoft Enterprise Management Product (think Virtual Center).  It is part of Microsoft System Center and is called SCVMM (System Center Virtual Machine Manager).  Here are some points for this product.

• Since Distributed Resource Scheduling doesn’t exist today for Hyper-V, they support the idea of Intelligent Placement of a VM onto the farm.  This data is configurable but the SCVMM basically tracks performance of the hosts over a recent time period in an attempt to recommend the best placement of the new virtual machine on a host.
• The entire product is driven by Windows Power Shell and is completely customizable, exportable, etc.
• Upcoming version of the product will support ESX and well as Hyper-V.  In order to support ESX, an existing Virtual Center will be required for SCVMM to interface.  (Think single pane of glass for management).  I have my doubts on this one but I’m curious.
• Self Service Portal – End Users will be able to provision their own machines.  Again, I’d have to see this one.

bron: http://www.bladevault.info

Release: Microsoft Hyper-V 1.0

After over three years of development (the product was originally announced at WinHEC 2005 conference) Microsoft finally releases today its first bare-metal virtualization platform: Hyper-V.
During this very long process the product was delayed, changed name, and lost some planned key features.

Unlike Virtual Server and Virtual PC, Hyper-V is a type-1 virtual machine monitor (aka hypervisor) which features an architecture very similar to the one used by Xen and its commercial derivates.
This allows a direct comparison with platforms like Citrix XenServer, Virtual Iron, the upcoming Sun xVM Server and obviously with VMware ESX.

Unlike the latter, Hyper-V adopts a microkernel developed from scratch (so it’s not the Windows kernel) which is less than 1MB in size and delegates most of the tasks to a so called Parent Partition.
Depending on the configuration you adopted, the parent partition automatically loads a full copy of Windows Server 2008 or the new Windows Server 2008 Core.

Being a first generation product, Hyper-V cannot really compete with the above in features, but it clearly offers a performance boost (up to +107% in case of disk I/O activity) and some much deserved improvements over Virtual Server 2005 R2:

• Support for 32bit and 64bit virtual machines
• Support for up to 4 virtual CPU per VM (the actual number depends on the guest OS)
• Support for up to 64GB RAM per VM
• Support for the Windows 2008/2003/2000, Windows XP/Vista and Novell SUSE Enterprise Linux guest operating systems
• Quick Migration (the capability to suspend, migrate and resume a VM from one host to another)
• Automatic patching through Windows Update and WSUS

Like for Virtual Server 2005, Microsoft supports most of its applications inside virtual machines, but one of the products still unsupported (on any hypervisor) is Exchange 2007.
Now Microsoft reveals that the Exchange team will release a support statement within 60 days from today, finally giving the OK for the much awaited mail servers consolidation projects.

The company also supports 3rd party applications through an optional certification program. At the launch date three companies are already qualified to run their products on Hyper-V: Diskeeper, IBM (with DB2) and Symantec.

With Hyper-V Microsoft will also compete on the embedded hypervisor front against VMware (with ESXi) and Citrix (with XenServer Express): OEMs like HP, Dell, IBM, Fujitsu, Hitachi, NEC and Unisys are already preparing to ship their hardware with the integrated hypervisor.
As already announced the price of Hyper-V in these configurations will be $28.

The new hypervisor doesn’t change the licensing scheme already introduced for Virtual Server: Windows Server 2008 Standard Edition license includes one virtual machine, the Enterprise Edition includes up to four VMs, and the Datacenter Edition allows unlimited VMs.

Microsoft Hyper-V is fully integrated with Windows Server 2008 64bit so any download of the OS includes it. Download a trial here.
For those customers already using the beta or the release candidate of Hyper-V, the product will be updated through the Windows Update service beginning July 8.

To demonstrate how much the company bets on this new product, Microsoft is internally adopting Hyper-V since a while and already migrated inside its virtual machines all the web front-ends that serve TechNet and MSDN websites.

Now the customers wait for the upcoming System Center Virtual Machine Manager 2008, currently in beta, to centrally manage Hyper-V (along with Virtual Server and VMware ESX), and MAP 3.1, in beta as well, to perform accurate capacity planning.

Hyper-V RTM’ed !

Hyper-V has RTM’ed ! That is way earlier than the initial 180 days after Windows Server 2008 release. Expect more information and official press release later today.

Source: Bink.nu

Exchange Server 2007 and Hyper-V

While at TechEd IT Pro North America 2008, I also had the opportunity to attend Brent Alinger’s session on Exchange Server 2007 and Hyper-V.  Brent is a Senior Test Lead on the Exchange Team at Microsoft, and he’s leading our testing efforts around Hyper-V.

Brent described a number of terms, such as the Hyper-V root (which is the parent or the host machine), Hyper-V guest (which is the child or virtual machine), virtual hard disks (VHD), passthrough disks, fixed and dynamic disks, and virtual machine state files.  Some of the more noteworthy bits of info from the session are:

• Within 60 days of Hyper-V’s RTM, the Exchange team will publish a detailed support statement for Hyper-V, and a TechNet article with best practices. I’m part of the Exchange Virtualization Working Group and will be helping to deliver some of this content.
• Customers should not deploy Exchange on Hyper-V until our support guidance is available.
• Early results show that performance of Exchange 2007 on Hyper-V is quite good, and that it scales very well from 1-4 processors per VM.

In terms of best practices and requirements, Brent shared the following:

• We’re only supporting guests running Exchange Server 2007 SP1 on Windows Server 2008.
• We’re only supporting fixed disks, and not dynamic disks.
• Storage should be on spindles that are separate from the Guest operating system VHD physical storage.
• Storage must be SCSI passthrough or iSCSI (with a preference of SCSI passthrough for queues, databases and log files).
• All Exchange server roles, except for the Unified Messaging server role, will be supported.
• For backup, hardware VSS should be used.
• There’s a limit on VHD size of 2040 GB.

Brent also mentioned that Hyper-V is a good fit when Exchange servers in branch offices cannot be consolidated to a central datacenter (for example, because of bandwidth or connectivity issues).

In terms of workload, not every workload is a candidate for virtualization.  For example, server roles such as Client Access and Hub Transport can be good candidates, but a more heavy hitter like the Mailbox role (which often uses all available resources on a physical server) might not be the best candidate for virtualizing.

It was a great session, and you can expect to hear a lot more about Exchange 2007 and Hyper-V over the coming months.

Source: Scott Schnoll

SCVMM 2008 beta (Update for Hyper-V RC1)

If you go to https://connect.microsoft.com the update that allows SCVMM to work with Hyper-V RC1 is now available

Update for SCVMM 2008 Beta - (You can access this from the downloads page).

Install this update to enable Virtual Machine Manager 2008 Beta (VMM) to function with Release Candidate 1 (RC1) to the Hyper-V role. After you install this update, you may have to restart your computer. Once you have installed this update, it cannot be removed.

Before You Install the Update

The VMM server and all of the hosts in your environment must be running Hyper-V RC1. After you install the update, you will not be able to add hosts running Hyper-V RC0 to your VMM environment. For information about the Hyper-V RC1 download, see Update for Windows Server 2008 x64 Edition (KB950049).

Exporting and Importing virtual machines

Exporting virtual machine

Unlike VS 2005, when you want to move a virtual machine from one host to another, you cannot simply copy the configuration file (.VMC) and the VHD file and “make it “appear on the destination host with Hyper-V. To perform the same operation, you need to export the VM from the source host system, copy all the export files to the destination host and then import it into Hyper-V.

When exporting a VM, you can either export only configuration files (that contains all settings for this VM) or include all save state files (.vsv files), snapshot files (.AVHD files) and VM binary (.VHD file).

After you specify a root folder to store export files, the export operation will create a folder structure for you under the root folder as follow: ( assuming that the root folder is called C:\Export)

C:\Export

|———- <VM_Name>

| —————-  Virtual Machines

| —————- Virtual Hard Disks

The Virtual Machines sub-folder contains an export file (.EXP) that Hyper-V creates for export and eventually VSV files and AVHD files if you specify the option to export save state files for export. The EXP file will be read by the import operation to re-create settings for virtual machine at destination.

The Virtual Hard Disks sub-folder is the location where VHD file will reside.

To script the export operation with Hyper-V WMI, you simply call the method of the Msvm_VirtualSystemManagementService Class and specify a reference to the VM to be exported, a flag that indicates whether you want to export system state files or not and an export folder. The call returns either 0 or 4096. All other values indicate an error in the parameters passed to the call.
If it returns 0, it means that the method is executed synchronously, If it returns 4096, the method is executed asynchronously and the Job output parameter can be used to track progress of the operation.

Here is an example:

## Get reference to a VM to be exported
PS C:\> $Core = get-wmiobject -namespace root\virtualization -class Msvm_ComputerSystem -filter ” ElementName = ‘IIS-CORE’ “

## Connect to the Virtual machine Management Service
PS C:\> $VM_Service = get-wmiobject –namespace root\virtualization –class Msvm_VirtualSystemManagementService

## call the Export method
PS C:\> $status = $VM_Service.ExportVirtualSystem($Core.__PATH, $True, “C:\Export”)
PS C:\> If ($Status.ReturnValue -eq 0) { write-host “Operation Sucessful”; exit}
PS C:\> if ( $status.ReturnValue -eq 4096) { $JobStatus = $Status.Job.JobState; while ($JobStatus -ne 0) { sleep(1) } }

Importing virtual machines

The next step is to copy the folder structure under C:\Export to the destination host. It is not recommended to import a VM directly from the export folder and the import operation does not support network drive or network share folder so you can’t simply point the import operation to a network share like \\Server\C$\Export.

Here is an example of scripting the import operation:

## Connect to the Virtual machine Management Service
PS C:\> $VM_Service = get-wmiobject –namespace root\virtualization –class Msvm_VirtualSystemManagementService

## call the Import method
PS C:\> $FlagGenerateNewID = $True # To ensure that the new imported VM will always get a new ID (GUID)
PS C:\> $status = $VM_Service.ImportVirtualSystem(“C:\VMs\IIS-CORE”, $FlagGenerateNewID)
PS C:\> If ($Status.ReturnValue -eq 0) { write-host “Operation Sucessful”; exit}
PS C:\> if ( $status.ReturnValue -eq 4096) { $JobStatus = $Status.Job.JobState; while ($JobStatus -ne 0) { sleep(1) } }

Bulk Export and Import

If you have a set of virtual machines to be exported from one machine and then to be imported on a different host, you can automate the operation as follow:

On the Source Server

$VM_Service = get-wmiobject -computer $SourceServer –namespace root\virtualization –class Msvm_VirtualSystemManagementService

$ListofVMs = get-wmiobject -computer $SourceServer -namespace root\virtualization -class Msvm_ComputerSystem -filter ” ElementName <>Name”

foreach ($VM in $ListofVMs)
{

$status = $VM_Service.ExportVirtualSystem($VM.__PATH, $True, “C:\Export”)
If ($Status.ReturnValue -eq 0) { write-host “Operation Sucessful”; exit}
if ( $status.ReturnValue -eq 4096) { $JobStatus = $Status.Job.JobState; while ($JobStatus -ne 0) { sleep(1) } }

}

robocopy /z /s C:\Export \\$DestServer\C$\VMs

On the Destination Server

$VM_Service = get-wmiobject -computer $DestServer –namespace root\virtualization –class Msvm_VirtualSystemManagementService

$ListOfFolders =  dir “C:\VMs” | where { $_.PSIsContainer} | select FullName
foreach ($f in $ListOfFolders)
{
$Folder = $f.FullName
$Status  = $VM_Service.ImportVirtualSystem($Folder,$True)
If ($Status.ReturnValue -eq 0) { write-host “Operation Sucessful”; exit}
if ( $status.ReturnValue -eq 4096) { $JobStatus = $Status.Job.JobState; while ($JobStatus -ne 0) { sleep(1) } }

}

Hyper-V WMI – Configuring Automatic Startup/Shutdown/Recovery Action’s For Virtual Machines

Hyper-V virtual machines have configuration options that control what happens when the parent/host server shuts down, start’s up, or if a virtual machine’s worker process terminates unexpectedly.  The first two conditions (parent/host shutdown, startup) are pretty self explanatory but what would cause a worker process to terminate?  There are a couple reasons, one would be if someone terminates the process, another would be if the process detects an security attack coming from the virtual machine, others reasons could be if there was bad hardware or a programming error (i.e bug) in either Hyper-V or another component in the system…

The default Automatic Startup Action is to start the virtual machine if it was running when the server was shutdown.  Another option is to always startup the virtual machine irrespective of the state of the virtual machine when the server was shutdown. The last option is none – this translates to leave the virtual machine off or saved when the server starts up.

The default Automatic Shutdown Action is to save any running virtual machines.  There are two other options, first is to turn off any running virtual machines and second is to shutdown any running virtual machines using the shutdown integration component.  The shutdown is forced – so any open/running programs will be terminated.  If the shutdown request fails the vm will be turned off – this can happen for many reasons primarily because the IC’s aren’t installed or if the guest is in safe mode/booting up.

The default Automatic Recovery Action is to restart the virtual machine, the other options are to revert to the last snapshot if one exists or none – which again equates to leaving the virtual machine off.

There is one additional option that I wanted to discuss briefly is Automatic Startup Action Delay, this is the amount of time to wait after the server reboot before taking the automatic startup action.  The default is zero – meaning take the action immediately.  This option could be very helpful for some servers – if you have lower and higher priority virtual machines you might want to delay the startup of your low priority virtual machines.

So here’s some code:

$VirtualSystemManagemntService = get-wmiobject -class “Msvm_VirtualSystemManagementService” -namespace “root\virtualization”

foreach ($Vm in Get-WmiObject -Namespace root\virtualization -Query “Select * from Msvm_ComputerSystem Where Description=’Microsoft Virtual Machine’”)
{
$SettingData = Get-WmiObject -Namespace root\virtualization -Query “Associators of {$Vm} Where ResultClass=Msvm_VirtualSystemGlobalSettingData AssocClass=Msvm_ElementSettingData”
$SettingData.AutomaticStartupAction = 0 #None=0, Restart if Previously Running=1, Always Startup=2
$SettingData.AutomaticShutdownAction = 0 #Turn Off=0, Save State=1, ShutDown=2
$SettingData.AutomaticRecoveryAction = 0 #None=0, Restart=1, Revert to Snapshot=2
$SettingData.AutomaticStartupActionDelay = [System.Management.ManagementDateTimeconverter]::ToDmtfTimeInterval((New-TimeSpan -Minutes 10))

$VirtualSystemManagemntService.ModifyVirtualSystem($Vm, $SettingData.PSBase.GetText(1))

Power and Hyper-V are now part of the Windows Server 2008 Tuning Guide!

The guide has been updated with sections on Power and Hyper-V guidelines and best practices.  Check out the updated Tuning Guide and tell us what you think by following the feedback link at the top of the Tuning Guide.  We look forward to hearing from you!

Create Hyper-V Virtual Switches/Networks

In this post I am going to show how to create a new virtual switch attached to an external network. I’ll start with a complete script and then take it apart and explain what each part is doing.

$VirtualSwitchService = get-wmiobject -class “Msvm_VirtualSwitchManagementService” -namespace “root\virtualization”
$ReturnObject = $VirtualSwitchService.CreateSwitch([guid]::NewGuid().ToString(), “New External Switch”, “1024″,”")

#Create New Virtual Switch
$CreatedSwitch = [WMI]$ReturnObject.CreatedVirtualSwitch

#Create Internal Switch Port
$ReturnObject = $VirtualSwitchService.CreateSwitchPort($CreatedSwitch, [guid]::NewGuid().ToString(), “InternalSwitchPort”, “”)
$InternalSwitchPort = [WMI]$ReturnObject.CreatedSwitchPort

#Create External Switch Port
$ReturnObject = $VirtualSwitchService.CreateSwitchPort($CreatedSwitch, [guid]::NewGuid().ToString(), “ExternalSwitchPort”, “”)
$ExternalSwitchPort = [WMI]$ReturnObject.CreatedSwitchPort

$ExternalNic = get-wmiobject -namespace “root\virtualization” -Query “Select * From Msvm_ExternalEthernetPort WHERE IsBound=False”

#Call SetupSwitch
$Job = $VirtualSwitchService.SetupSwitch($ExternalSwitchPort, $InternalSwitchPort, $ExternalNic, [guid]::NewGuid().ToString(), “InternalEthernetPort”)
while (([WMI]$Job.Job.JobState -eq 2) -or ([WMI]$Job.Job.JobState -eq 3) -or ([WMI]$Job.Job.JobState -eq 4)) {Start-Sleep -m 100}
[WMI]$Job.Job

Before explaining the elements of the script, I think it’s important to explain a little about Hyper-V’s networking model. Hyper-V’s networking model attempts to be a similar to a real network, there are virtual switches, virtual switch ports and network adapters. When you create a new external virtual network you are actually creating a virtual switch, an internal and external switch port and a virtual network adapter on the host.

So let’s look at the script above section by section.

Section 1 – Creating The Switch

$VirtualSwitchService = get-wmiobject -class “Msvm_VirtualSwitchManagementService” -namespace “root\virtualization”
$ReturnObject = $VirtualSwitchService.CreateSwitch([guid]::NewGuid().ToString(), “DemoExternal”, “1024″,”")

Create New Virtual Switch
$CreatedSwitch = [WMI]$ReturnObject.CreatedVirtualSwitch

This section get’s the Msvm_VirtualSwtichManagmentService, this is similar to other management service classes like msvm_imagemanagmentsevice. The second line creates the switch, the first parameter to this function is the switch name, typically a guid is a good unique name, the second parameter is the friendly name (what you will see in the UI), the third parameter is the number of learnable addresses in the switch, the last parameter the AzMan scope name (I’ll talk more about those in a later post). The third line retrieves the WMI object for the created switch.

Section 2 – Creating Switch Ports

#Create Internal Switch Port
$ReturnObject = $VirtualSwitchService.CreateSwitchPort($CreatedSwitch, [guid]::NewGuid().ToString(), “InternalSwitchPort”, “”)
$InternalSwitchPort = [WMI]$ReturnObject.CreatedSwitchPort

#Create External Switch Port
$ReturnObject = $VirtualSwitchService.CreateSwitchPort($CreatedSwitch, [guid]::NewGuid().ToString(), “ExternalSwitchPort”, “”)
$ExternalSwitchPort = [WMI]$ReturnObject.CreatedSwitchPort

This section creates the internal and external switch ports, think of these as the ports on a physical switch that you would attach to your PC or Modem. In both cases we are calling the CreateSwitchPort method. The first parameter is switch we created in the previous section, the second parameter is the switch port name again we using a guid, the third the friendly name this name does not have to be unique and can be anything you want, and the final parameter again is the AzMan scope. We again retrieve the created switch port’s as WMI objects.

Section 3 – Retrieving External Ethernet Connection

$ExternalNic = get-wmiobject -namespace “root\virtualization” -Query “Select * From Msvm_ExternalEthernetPort WHERE IsBound=False”

This section retrieves the external Ethernet port think of this as the port on the modem or the actual network adapter on the physical machine. This query should return only one adapter, in the query above I select all adapters on the machine that are not already bound to a switch (hence the IsBound=False) so if I had two network adapters that not bound this query would need to be more specific. You’ll need to figure out what your criteria will be try running “get-wmiobject -namespace “root\virtualization” -Query “Select * From Msvm_ExternalEthernetPort” this will return all of the information available to query against.

Section 4 – Bringing It All Together

$Job = $VirtualSwitchService.SetupSwitch($ExternalSwitchPort, $InternalSwitchPort, $ExternalNic, [guid]::NewGuid().ToString(), “InternalEthernetPort”)

while (([WMI]$Job.Job.JobState -eq 2) -or ([WMI]$Job.Job.JobState -eq 3) -or ([WMI]$Job.Job.JobState -eq 4)) {Start-Sleep -m 100}
[WMI]$Job.Job

This final section bring’s it all together. The SetupSwitch method takes the WMI objects for the switch, switch ports, external Ethernet port as well as a name and friendly name and binds all the switch port’s together. Up to this point if you looked in the Hyper-V Network Manger you would see your switch but it would be a private switch; after this it will be an external switch. The last two lines just wait for the returned WMI object to complete and then prints out the object.

That’s it! You now have an external network.

Source: Taylor Brown

Hyper-V WMI – Cloning Virtual Machines Using Import/Export

Here’s a quick tour of the script…

This script takes 4 parameters:

• MasterVM – this is the name of the VM that will be cloned
• Path – this is the base path where the clones will reside
• NewName – this is what the cloned VM’s will be named
• HyperVHost – this is the name of the host that the script will execute against

The function ProcessWMIJob takes the return of a WMI method call and then processes the job waiting for the job to complete  and throwing an exception if the job failed.

The main part of the script retrieves the Msvm_VirtualSystemManagmentService class and the MasterVM’s Msvm_ComputerSystem.  It then loops 10 times, first changing the name of the VM and then exporting the VM and finally re-importing the VM.  After it completes the 10 interactions it restores the name of original name of the MasterVM.

param
(
[string]$MasterVM = $(Throw “MasterVM required”),
[string]$Path = $(Throw “Path required”),
[string]$NewName = “VMCopy”,
[string]$HyperVHost = “localhost”
)

function ProcessWMIJob
{
param
(
[System.Management.ManagementBaseObject]$Result
)

if ($Result.ReturnValue -eq 4096)
{
$Job = [WMI]$Result.Job

while ($Job.JobState -eq 4)
{
Write-Progress -Id 2 -ParentId 1 $Job.Caption -Status “Executing” -PercentComplete $Job.PercentComplete
Start-Sleep 1
$Job.PSBase.Get()
}
if ($Job.JobState -ne 7)
{
Write-Error $Job.ErrorDescription
Throw $Job.ErrorDescription
}
}
elseif ($Result.ReturnValue -ne 0)
{
Throw $Result.ReturnValue
}
Write-Progress $Job.Caption -Status “Completed” -PercentComplete 100 -Id 2 -ParentId 1
}

#Main Script Body
$VMManagementService = Get-WmiObject -Namespace root\virtualization -Class Msvm_VirtualSystemManagementService -ComputerName $HyperVHost
$SourceVm = Get-WmiObject -Namespace root\virtualization -Query “Select * From Msvm_ComputerSystem Where ElementName=’$MasterVM’” -ComputerName $HyperVHost
$a = 0

while ($a -lt 10) {
write-progress -Id 1 “Cloning Vm’s” -Status “Executing” -percentcomplete (($a / 10)*100)
$tempVMName = “$NewName – $a”
$VMSettingData = Get-WmiObject -Namespace root\virtualization -Query “Associators of {$SourceVm} Where ResultClass=Msvm_VirtualSystemSettingData AssocClass=Msvm_SettingsDefineState” -ComputerName $HyperVHost
$VMSettingData.ElementName = $tempVMName

$Result = $VMManagementService.ModifyVirtualSystem($SourceVm, $VMSettingData.PSBase.GetText(1))
ProcessWMIJob $Result

$Result = $VMManagementService.ExportVirtualSystem($SourceVm, $TRUE, “$Path”)
ProcessWMIJob $Result

$Result = $VMManagementService.ImportVirtualSystem(“$Path\$tempVMName”, $TRUE)
ProcessWMIJob $Result

$a ++
}

write-progress -Id 1 -Completed $TRUE -Activity “Cloning Vm’s”
$VMSettingData = Get-WmiObject -Namespace root\virtualization -Query “Associators of {$SourceVm} Where ResultClass=Msvm_VirtualSystemSettingData AssocClass=Msvm_SettingsDefineState” -ComputerName $HyperVHost
$VMSettingData.ElementName = $MasterVM

$Result = $VMManagementService.ModifyVirtualSystem($SourceVm, $VMSettingData.PSBase.GetText(1))
ProcessWMIJob $Result

Source: Taylor Brown