In October last year, Microsoft released Windows Server Technical Preview 1 bits along with System Center Technical Preview and Windows 10 Technical Preview.
Windows 10 is slated to be released on July 29th onwards, the upgrade for Windows 10 will be made available through Windows update, so make sure to reserve your free upgrade by completing the registration and you have sufficient bandwidth to download the update.
As we can see that 2015 is an exciting year, however the final release of Windows Server 2016 and System Center is not until 2016! When? don’t ask me, I don’t know…
In today’s blog post we will look at what’s new in PowerShell for Hyper-V in Windows Server 2016 Technical Preview 2 versus Technical Preview 1.
The Hyper-V PowerShell module includes several significant features that extend its use, improve its usability, and allow you to control, automate and manage your Hyper-V environment entirely.
The Hyper-V PowerShell module in Windows Server 2016 TP1 ships with 186 PowerShell cmdlets.
If we look into PowerShell on Windows Server 2016 TP2 and count the Hyper-V cmdlets that are available at our disposal.
As you can see we have 204 cmdlets in Hyper-V 2016 TP2 versus 186 in Hyper-V 2016 TP1, so we have 18 new cmdlets so far
One important note to mention is that starting with Windows Server 2016 TP2 and Windows 10, Microsoft will ship two Hyper-V PowerShell modules in-box Version 1.1 and Version 2.0 to help you manage cross-versions Hyper-V hosts 2012, 2012 R2, and 2016.
What are these new cmdlets? Let’s compare Hyper-V 2016 TP1 and TP2 modules side by side and explore the difference.
I will use the Compare-Object cmdlet, but before doing this you need to capture the XML file with all Hyper-V PowerShell cmdlets from WS2016 TP1 and TP2 hosts.
TP1 Host: Get-Command -Module Hyper-V | Export-Clixml C:\HyperV-TP1-Compare.xml
TP2 Host: Get-Command -Module Hyper-V | Export-Clixml C:\HyperV-TP2-Compare.xml
The result above will be a table telling you what is different. Every PowerShell cmdlet that’s in the reference set (HyperV-TP1-Comapre.xml), but not in the difference set (HyperV-TP2-Compare.xml), will have a <= indicator (which indicates that the cmdlet is present only on the left side). However If a cmdlet is on the difference Hyper-V TP2 host but not on the reference TP1 host, it will have a => indicator which is our case here with 18 new cmdlets and 6 updated cmdlets on the right side. Finally, PowerShell cmdlets that match across both sets won’t be included in the difference output.
All the previous PowerShell cmdlets that are available in Windows Server 2012 R2 and 2016 TP1 Hyper-V are available as well in Windows Server Technical Preview 2 in addition to the following:
Add-VMGroupMember Add-VMSwitchTeamMember Add-VMTPM Disable-VMConsoleSupport Enable-VMConsoleSupport Get-VHDSet Get-VHDSnapshot Get-VMGroup Get-VMHostCluster Get-VMSwitchTeam Get-VMTPM New-VMGroup Optimize-VHDSet Remove-VHDSnapshot Remove-VMGroup Remove-VMGroupMember Remove-VMSwitchTeamMember Rename-VMGroup Set-VMHostCluster Set-VMSwitchTeam Set-VMTPM Start-VMTrace Stop-VMTrace Update-VMVersion
Let’s dive in and discover what these new cmdlets bring to Hyper-V 2016 in TP2.
Add-VMTPM, Get-VMTPM, Set-VMTPM
Trust is the biggest blocker to cloud computing adaption. Microsoft in Windows Server 2016 they are doing a lot of work in the Hyper-V core platform to start providing these guarantees. Even if you trust or don’t trust your IT administrator, no one can access your data!
A virtual TPM (Trusted Platform Module) can be injected into a VM. Then you can enable BitLocker in the VM and protect your data from anyone outside of the VM. So you can now have a virtual machine running on someone’s else Hyper-V server or on someone’s else infrastructure and you can know that you are the only one who has access to that data.
As for the deployment side, this can be done through Active Directory Attestation or through TPM Attestation, the TPM Attestation requires TPM Version 2.0 chip to be installed on the physical host.
For demo purposes only, you can add Virtual TPM for a Virtual Machine using the following steps (this is not secure):
1. Enable Hyper-V 2016 TP2
2. Install-WindowsFeature –Name Isolated-UserMode
3. Restart Hyper-V Host
4. Create a Gen2 VM
5. Install the Guest OS, then make sure to enable Remote Desktop, and finally turn off the VM.
6. Configure Virtual TPM by run the following cmdlets:
7. Start the VM, vTPM should show up in the Guest OS under device manager
Note, the VM console access is not available for shielded VM, therefore you need to access the VM through RDP.
Microsoft published a step-by-step installation and validation guide for Windows Server Windows 2016 TP2 (build #10074) and System Center VMM for Guarded Fabric Hosts and Shielded VMs. You can download the full guide from here.
The VM Console Support is for human interface devices which is a part of the USB specification for external peripherals, limited functionality at the moment, but it looks like that we will be able to connect and inject direct HID devices into the guest OS.
There is a new type of VHD file that Microsoft introduced in Windows Server 2016 TP2 called VHD Set (VHDS) and it’s necessary for some of the new shared VHDX functionality that we have. The Shared VHDX file still exists, so if you have existing guest clusters using the VHDX file you can continue to use those VHDX files for guest clusters. However, you will not be able to do the online resize and the host-based backup. The good news is that Microsoft will provide tools to do a very quick and easy upgrade from a VHDX, to a VHDS file so you can take advantage of that.
The Get-VHDSnapshot and Remove-VHDSnapshot are used to manage the new Shared VHD Set File (VHDS). Limited functionality at the moment.
New-VMGroup, Get-VMGroup, Rename-VMGroup, Remove-VMGroup, Add-VMGroupMember, Remove-VMGroupMember
The VM Group cmdlets are to group multiple virtual machines into one group, for example, a three-tier application which is consists of a back-end database, mid-tier application, and front-tier web server, or if you want to manage a group of Virtual Machines altogether.
First, you need to create a new Group and choose the Group Type (VMCollectionType or ManagementCollectionType)
Next, you can start adding Virtual Machines into the group using Add-VMGroupMember / Remove-VMGroupMember. Limited functionality at the moment.
Microsoft is providing a single view of an entire Hyper-V cluster through WMI. You can manage an entire Hyper-V cluster like it were just one big Hyper-V Server.
So for example with Get-VM, if you actually point it to a single Hyper-V host you get all the virtual machines on that particular host, however, if you point it at your Hyper-V cluster, what’s going to do, it’s going to return all the virtual machines on that cluster, so you can take the output and pipe it into all various PowerShell commands, makes it a lot easier to start operating on a cluster of Hyper-V using PowerShell.
Get-VMHostCLuster –ClusterName <ClusterName> -Credential $Cred
Set-VMHostCluster -ClusterName <ClusterName> -SharedStoragePath \SOFS\SHARE1
The VMTrace is targeted to trace Virtual Machines based on different informational levels such as (Error, Info, Warning, Verbose, Off).
Add-VMSwitchTeamMember, Set-VMSwitchTeam, Get-VMSwitchTeam, Remove-VMSwitchTeamMember
In Windows Server 2012 / R2, when we create a Teaming vSwitch, we will create first an LBFO team (New-NetLbfoTeam), and that creates a new teamed adapter in the system, and finally, we connect that adapter into the Hyper-V vSwitch. However in Windows Server 2016 TP2, Microsoft introduced a new teaming mode called SwitchEmbeddedTeaming, this will allow us to simply connect all the physical adapters directly into the Hyper-V virtual switch, and then the virtual switch internally will handle the spread of traffic between these adapters from the inside of the switch, so the virtual switch will handle that traffic coming in and going out more efficiently.
First, you need to create a New vSwitch and enable Switch Embedded Teaming is the following:
Note: Please note that this is not working in the current (build #10074).
The process to upgrade a virtual machine version requires to shut down the VM, and do a manual upgrade. This is a one-way process so you can either do this through PowerShell or through the Hyper-V Manager console. To upgrade the VM Configuration File through PowerShell, you need to run the following cmdlet from an elevated Windows PowerShell:
If you want to automate the upgrade VM version process, then make sure to check this post.
I will update this blog post as soon as Technical Preview 3 will come out!
Note: This is the current release of Technical Preview #10744 build, so we’ll have to wait and see the changes in the next bits…
Until next time… Enjoy your weekend!