The other day it was necessary for me to confirm Windows OS build in Hyper-V guest VM without logging in into it. I simply received VM from the client but no credentials which I could use, but it was necessary to quickly confirm guest OS build. I was certain that there is a way to query such data from Hyper-V host without logging into guest and with no credentials. After some googling I was not able to find some simple command or one liner to pull this data (opening PS session into VM was not an option as it requires credentials), but I’ve found good function which does exactly what I need on Yusuf Öztürk blog, here it is:
Once you have this function, you can use it like this:
Recently I imported some old VM into my Windows 10 Hyper-V and noticed that unlike VMs I created with latest version of Hyper-V it has an extra option named “Upgrade Configuration Versions..”:
To me option name is a bit confusing (which sometimes happens in MSFT products out of best intentions in attempts to simplify their wizards and wording). I was confused by this option name as it makes me think about configurations versioning and management rather about what it really means. To put it simply it is equivalent of what you can see in VMware Workstation as “Upgrade Virtual Hardware”/”VM hardware compatibility” (isn’t it more appropriate name? but I guess there is also differentiation needs which software vendors may have 🙂 ).
What you should know about this is in the past (prior to Windows 10) your VMs have been upgraded automatically to new configuration version, but now you have more control over this and have upgrade it manually via GUI (see screenshot above) or using Update-VMVersion cmdlet.
“Upgrade Configuration Version…” option presented in VM properties only when your VM is in offline state. Operation is almost instant and unfortunately it doesn’t give you that VMware Workstation wizard which explains available versions and why you may want to upgrade/added features. But essentially Hyper-V no longer upgrades VMs by default to allow you to move them back to older versions in case it will be necessary and upgrade is needed to enable new features for VM (see table below):
Virtual machines created on Windows 10 use version 6.2 configurations, and the highest value for now is 8.0 (Served 2016/Windows 10 Anniversary update). You can use this table to get an idea of configuration versions in different base OS versions:
To check configuration versions of VMs on your Hyper-V host:
Get-VM * | Format-Table Name, Version
To get configuration version supported by your host use (add –Default parameter to see default one):
I’ve recently switched from VMware Workstation to Windows 10 Client Hyper-V and I really pleased with capabilities I get so far. But after awhile I noticed extreme sluggishness of web browsing on my host machine which I had not linked initially with Hyper-V. Issue has not crop up immediately after I installed and started using it, but seemingly after I added Internal Virtual Switch. So I spend day and a half blaming slowness on my ISP before trying to investigate and fix the problem.
In case if you not recognize whether you have the same problem or not here is somebody’s YouTube video demonstrating it along with fix valid for Window 8/8.1 (note that adapter names may vary from case to case). Windows 10 fix can be found below.
Essentially when you create External Hyper-V switch it sorts of hijacks your physical NIC unbinds IPv4 from it and passes its IPv4 config onto External vEthernet adapter in some obscure way. But slowness crops up due to the wrong connections priority which was easy to adjust in Win 8 as described in this TechNet blog post – you just navigate to Network Connections (ncpa.cpl) > Press Alt on keyboard to access Advanced Settings as depicted below and from there just reorder your connections making sure that External vEthernet adapter is listed first.
Problem is that in Windows 10 you no longer have this GUI because as one person put it “There are no longer any components that utilize the binding order. The only known component that used the binding order was DNS ordering. By default, Windows uses the Route Metric + Interface Metric to determine which route has the highest priority by choosing the route with the lowest value.” This is explanation which I got here.
Long story short what you likely have to do to bring your browsing speed back to normal is issue Get-NetIPInterface cmdlet to get list of your interfaces along with their Index and Interface Metric values. It should return you something like this:
Now you want to make sure that your vEthernet gets highest priority by issuing the following cmdlet: