Screen Shot 2013-10-21 at 14.01.16.png

Converting a VM to a Template:

Converting an existing VM to a template is a single one-liner PowerCLI command using the cmdlet Set-VM. The cmdlet uses the existing parameters (cluster, VM Folder, Datastore) as its it location.

Set-VM Win2012-R2 -ToTemplate -Confirm:$false

Converting a Template to a VM:

Converting a template to a VM is a single one-liner PowerCLI command using the cmdlet Set-Template. Again the cmdlet uses the existing parameters (cluster, VM Folder, Datastore) as its it location.

Set-Template -Template Win2012-R2 -ToVM

Converting Many Templates To VMs:

Here Get-Template is used to find any template starting with Win its name, and then uses a Foreach loop to convert each one into a VM.

Foreach ($vmtemplate in (Get-Template Win*))

{

Set-Template -Template $vmtemplate -ToVM

}

Converting Many VMs to Templates:

Here Get-VM is used to find any VM beginning with Win, and use Set-VM to convert the VMs into Templates

Foreach ($vmtemplate in (Get-VM Win*))

{

Set-VM $vmtemplate -ToTemplate -Confirm:$false

}

Creating a New VM from a Template:

New VMs from existing templates can be created with a very simple script that reference the various variables required to create the VM including such requirements as the VM name, Template, Datastore, ResourcePool (which can be the host, cluster or resource pool name), VM Folder location and what Guest Customization to use.

New-VM -Name corphqdb03 -Template win2012-R2 -Datastore platinum -ResourcePool GoldCluster01 -Location CorpHQ -OSCustomizationSpec “Windows 2012 R2 – CorpHQ” Start-VM corphqdb03

Creating Multiple VMs from a Template:

In this example a small linux distribution called Slitaz was used to reduce the time to complete the clone options. The script creates 10 VM number corphqdev01, corphqdev02 and so on. The -RunAsync speeds up the operation by not waiting for the clone to complete before the script loops around to carry out the next clone.

1..10 | Foreach {$Num = “{0:00}” -f $_

New-VM -Name corphqdev“$Num” -Template SliTaz -Datastore platinum -ResourcePool GoldCluster01 -Location Corphq -RunAsync

}

Once the VMs have been created they can be powered on using simple wildcard based one-liner with:

start-vm corphqdev*

Upgrade Virtual Hardware and VMware Tools of a Single Template:

IMPORTANT: Remember non-interactive updates automatic updates of VMware Tools is not fully supported for non-Windows OSs. Manual intervention might be required. In our experience attempting to automate the update VMware Tools with PowerCLI is harder than it first seems. You might prefer to use VMware Update Manager which handles the process with less heartache.

It’s tricky to automate the upgrade of virtual hardware and VMware Tools without the PowerCLI script becoming convoluted. For instance the script below could made infinitely more sophisticated by first check if the VM’s virtual hardware and VMware Tools is already up to date before starting the process. Additionally, some guest operating systems will take longer to shutdown than others, especially if Windows Update manager is enabled, and updates have been set to download and install on shutdown. The Set-VM cmdlet contains the option upgrade the Virtual Hardware Level (currently v10 in vSphere5.5), and Update-Tools can silently upgrade VMware Tools. Its supports a -noreboot flag which stops the guest OS initiating a reboot – this essentially send .MSI commands to the install of /s /v”/qn REBOOT=ReallySuppress?. This doesn’t guarantee that the Windows VM will not be rebooted at the end. The vSphere5.5 PowerCLI Reference guide to Update-Tools makes this statement:

…virtual machine might still reboot after updating VMware Tools, depending on the currently installed VMware Tools version, the VMware Tools version to which you want to upgrade, and the vCenter Center/ESX versions.

There are couple of anomalies when carrying out this process. Firstly, it’s best upgrade VMware Tools first, before upgrading the Virtual Hardware. VMware KB1010675 outlines circumstances where network settings can be lost/modified. This is because new hardware can be recognised during the upgrade of the hardware, which might not be recognise properly until VMware Tools is up to date. Secondly, You may also need to deal with VM Question such as the UUID value, dependent on how the VM/Template was registered on the system. Finally, the option to gracefully shutdown VMs after the install of VMware Tools may fail if the VMware Tools Service fails to start. In some cases a manual reboot of the guest OS is required to make the new VMware Tools Service start correctly.

The upgrade of VMware Tools can take sometime, and PowerCLI does not give much feedback on its progress. This can give the impression the script has hung, when it is in fact still busy working. This can be difficult if the script itself has hung or the VM is requiring interaction at the console to proceed.

$vmname = “Win2003”

Set-Template -Template $vmname -ToVM

Start-VM $vmname | Wait-Tools

Update-Tools -NoReboot $vmname

Shutdown-VMGuest $vmname -Confirm:$false

Sleep 300

Set-VM -VM $vmname -Version v10 -Confirm:$false

Set-VM $vmname -ToTemplate -Confirm:$false

Upgrade Virtual Hardware and VMware Tools of a Multiple Templates:

In this case the 1st ForEach loop converts all the Win* Templates into VMs.

Foreach ($vmtemplate in (Get-Template Win*))

{

Set-Template -Template $vmtemplate -ToVM

}

Once all the Win* templates are switched to being VMs, we can power each one on – and update their VMware Tools.

Foreach ($vmtemplate in (Get-VM Win*))

{

Start-VM $vmtemplate | Wait-Tools

Update-Tools -NoReboot $vmtemplate

Shutdown-VMGuest $vmtemplate -Confirm:$false

Sleep 300

Set-VM -VM $vmtemplate -Version v10 -Confirm:$false

Set-VM $vmtemplate -ToTemplate -Confirm:$false

}