When building a Windows Server 2016 TPv4 Hyper-V cluster this weekend I noticed that we now have a new version of the virtual machine configuration.
When we migrate (rolling cluster upgrade, move to new cluster or host, import on new cluster or host) virtual machines to Windows Server 2016 Hyper-V from Windows Server 2012 R2, the virtual machine’s configuration file isn’t automatically upgraded. In the past it was, which blocked moving back to a previous edition of Hyper-V. Now we can do this until we manually update the virtual machine configuration version. This block going back but it enables our new virtual machine features. Version 5.0 is the one that’s compatible with Windows Server 2012 (R2) Windows Server 2016. Version 6.2 was what we had in TPv3 and could only run on Windows Server 2016. Windows Server 2016 TPv4 Hyper-V brings virtual machine configuration version 7.
When you have virtual machines that come from Technical Preview v3 and you had updated the virtual machine configuration of your virtual machines or created brand new ones these would be at version 6.2. Since I do not consider it wise to keep testing these on a version of a previous preview I updated them all to version 7.
The code below grabs all VMs on all cluster nodes (even the none clustered VMs), shuts them down, updates the configuration version and starts them again. It’s just a quick example.
Now do NOT do this to virtual machines with configuration version 5 that you might want to move back / import to a Windows Server 2012 R2 Hyper-V host. But if you know you’ll be testing with the new features, have a blast, like me here on the TPv4 lab cluster.
I’m still looking for the features version 7.0 enables, probably nested virtualization is one of those features I’m guessing. Happy testing!
Microsoft Most Valuable Professional
There have been some recent changes in my technology community life. As an MVP I have been assigned to the Cloud and Datacenter Management award category. This reflects the fact that we all touch on a lot more technologies than the expertise we have received or award for. In my case Hyper-V means I also do networking, storage, high to continuous availability (clustering, network load balancing), data protection, IAAS as well as Identity Management (authentication/authorization) both on premises and on Azure.
In that spirit we attended the MVP Summit 2015, which was a great experience and confirmed what Scott Guthrie stated above, we are “most valuable professionals”.
Another award is decorating my home office. It’s the inaugural member edition of the Veeam Vanguard Award we received at VEEAMON 2015 in Las Vegas that we attended.
That conference was a blast by the way. Breakout sessions, white boarding sessions, presenting on Hyper-V related technologies and lots of networking with smart and engaged technologists. We also sat down with some CEOs of 2 companies and helped them determine an upgrade path for their hyper-V environments for the next 12 to 18 months. We even some real world troubleshooting in one of the attendees environment. I’d like to think we delivered value for all involved and we got to learn a lot ourselves.
I liked what they shared about Veeam Backup & Replication v9 that’s in development. And their announcement for Veeam Backup for Linux was well received. You can preregister for that here
When optimizing your RSS/VMQ settings for maximum performance you’ll normally (I hope) do this in PowerShell. Save that script with some comments on why you configure it that way and make it part of your Hyper-V host deployment scripts
Why? Automation is king but you’ll need it again for sure. Why? Well there is this “tendency” that NIC firmware/driver updates reset your RSS/VMQ optimizations back to their defaults.That’s a bit of a bummer if you have to redo all the work instead of having a script ready to go. I have seen many a deployment where the configuration was missing after firmware/driver upgrades so please, check!
Figure: Where has my optimized configuration gone after a driver/firmware upgrade?
The good news is this isn’t a show stopper issue as things will keep working, but without your optimizations and with VMQ, depending on your NIC team setup for the vSwitch issues might occur. When doing NIC teaming for your virtual switch it’s important to get it right. With switch dependent teaming (LACP/Static) the NICs in the team need to use overlapping processor sets (Min Queues). When doing switch independent teaming the NICs in the team need to use non-overlapping processor sets. So you need to configure each NIC in your team to use the different processors (Sum of Queues).
On top of that you might want to / should separate RSS/VMQ cores from each other. SMB Direct for CSV/LM will also help achieve this as there we leverage CPU offloading to the NIC.
While investigating a backup issue with some VMs I noticed an entry in the VEEAM Backup & Replication logs that the Hyper-V integration components were out of date.
This was the case on all the guests on that particular cluster actually. A quick look at the IC version on the host showed them to be at 6.3.9600.17831.
Comparing that to the ones in the guest made clear very quickly that those were at 6.3.9600.16384. So lower.
A web search for Hyper-V Integration components led us to KB3063283 “Update to improve the backup of Hyper-V Integration components in Hyper-V Server 2012 R2”on their Hyper-V hosts. They keep a tight ship but due to regulations they are normally 3 to 4 months behind in patches and updates. So in their case they only recently installed that update. KB3063283 Updates the Hyper-V Integration Components for Windows Server 2012 R2 to 6.3.9600.17831
So a little word of warning while you are keeping your Hyper-V environment up to date (you should), don’t forget to update the integration components of your virtual machines. A good backup product like Veeam Back & Replication will log this during backups. It might not make the backups fail per se but they have been updated for a good reason. This upgrade was even specifically for backup related issues so it’s wise to upgrade the virtual machines to this version a.s.a.p..