Another big investment by Microsoft in Windows Server 8 Hyper-V was how we interact with the product. With lots more functionality, and some of it being very advanced and not required by everyone, they had to decide how to present it in the GUI. And with huge cluster scale out (up to 64 hosts per cluster) and target markets such as hosting and large enterprise, automation was of great importance.
The GUI – Hyper-V Manager console (HMC)
On the face of it, the GUI has not changed much. There is no ribbon bar and things can be found where they previously were in the Windows Server 2008 Hyper-V and Windows Server 2008 R2 Hyper-V HMCs.
Often we fire up the HMC to just look for information. Tabs have been added in the lower centre pane of HMC to show us information, e.g. summary, memory, networking, and Hyper-V Replica (aka Replica).
Nested Nodes
When you open the settings of a VM to change it’s configuration you will notice that the CPU and Networking nodes on the left are nested. There are sub-nodes with more settings. This is done for some reasons including:
- It cleans up the GUI Even with newly added scroll bars, there’s only so much you can squeeze into a single screen without making things messy and unusable.
- It hides away advanced features that should only be used by engineers who know that they do and know that they need them, e.g. the NUMA override settings.
Clustering Interaction
A classic problem for the forums was when a person would edit the settings of a VM in the HCM and live migrate the VM from one host to another in a host cluster. Their new settings were lost because the cluster database was not updated. You had to either use Failover Cluster Manager (FCM) to edit the VM settings (auto-update of settings) or remember to manually update the VM resource in FCM after editing it the VM in HCM.
Now, HCM will detect that a VM is clustered and prevent you from editing the settings. You must use the FCM instead, and quite right too!
VMConnect
Have you ever been ticked off when you use VMConnect to get a console connection to a VM and then you fail it over to another node in a Hyper-V Cluster? Actually, ticked off isn’t the right word the first time you see this: you crap yourself when VMConnect loses the console connection to the VM and confusingly tells you that the VM must have been deleted! That’s changing in Windows Server 8. Yes, VMConnect will disconnect – briefly. The source host for the VM will redirect the VMConnect session to the VM on the destination host. No more tingling in the left arm or tightening of the heart when working on a VM at midnight. Hyper-V engineers and their doctors thank you, Microsoft!
PowerShell 3.0 Cmdlets
The big change is that Hyper-V will have built-in PowerShell (POSH) cmdlets for the very first time in Windows Server 8. Even from a POSH-disabled person like me, the cmdlets looked easy to use and very powerful to me in the hands on lab that I did. For you POSH purists, I’ve been told that the Hyper-V POSH cmdlet specs were written so things would be done the POSH way.
With some hep I had created a script that read in some specs from a CSV file, created a bunch of differential disks, created lots of VMs, and connected them to those disks. One test lab up and running in a few minutes, that could be recreated in a moment’s notice. I’m sure with more practice, I could have made the script much more elegant than I had in the limited time window.
It’s this sort of thing that the POSH cmdlets are intended to enable. Big hosting companies can automate deployment from their “control panels”. Enterprises can automate bulk configuration changes. We people who demo can deploy a new lab in seconds. And with POSH 3.0 Workflows you can build complex scripts that work reliably and in an orchestrated manner across many machines and applications.
Just like Exchange, not every admin function is in the GUI. Some things will have to be done in POSH. I guess I will have to learn it after all these years of saying “I will have to learn PowerShell”.