Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, November 6, 2019 6:52 PM
Hi everyone
I am having troubles with making the Hyper-V VM hosting work properly on my Windows 10 Pro 1903 laptop. The problems actually appeared while the machine was using Windows 10 1809.
More precisely: can't access the VM console at all and vmconnect (the Virtual Machine Connection) can not connect to the virtual machine and fails with the message "cannot connect to the virtual machine".
I have a screenshot but can't post images yet.
I can start the machine if it is off from the vmconnect window. The virtual machines run absolutely fine - networking and all works just fine. So I can and I do use Remote Desktop to connect to the VM.
But as I am unable to control the VM from the console, I effectively can't install any new VMs directly on that PC. What I have to do is RDP onto my home server or my other PC, setup the VM there, enable remote access via ssh / RDP and copy the vhdx back to this laptop - and this is obviously a tremendous hassle.
After following up suggestions from the forum and using netstat, TCPView and wireshark I have squared this down to the problem that the VMMS service is not listening at all to port 2179.
VMConnect launches correctly, desperately tries to establish connection to VMMS, tries all the local IPs my machine has and after failing to do so, I finally get the message above.
The vmconnect doesn't go beyond SYN_SENT, obviously as nothing is listening to the 2179 port. On a working machine, vmms service properly listens to that port and everything works fine. I have screenshots for both but again can't post images.
So the problem is probably NOT in VMConnect but in some internal configuration of the VMMS instead.
Things I have tried after scouring this and many other sources:
- Restarting (doh!)
- Updating to 1903 from 1809
- Adding exceptions in Windows Security for vmconnect and vmms
- Changing the virtual network switch configuration in Hyper-V Manager
- Last desperate attempt was removing the Hyper-V altogether and reinstalling it. No change, unfortunately... except for a hassle of reconfiguring several of my test VMs to communicate with a correct internal switch
I have this problem for a few months, but as work has been hectic I have postponed this. Elsewhere on the forums many computers appeared to exhibit the same problem after upgrading 1803 -> 1809, so I had some hopes of the problem resolving itself when I finally let the computer upgrade to 1903. No luck though.
I don't know what else to do. Basically, I'd like to force the Hyper-V VMMS to sort itself and start (again) listening to the port 2179.
Of note:
- There are some pieces of software that could interfere with vmms. E.g. Wireshark's npcap driver, Docker and its messing with hyper-v NAT, VirtualBox's filters... but I have almost exact situation on my other laptop and on my Surface Pro. No problems there.
- The hardware in question is quite old but it is also quite beefy and quite reliable, it's an HP EliteBook 8570W. I have another, almost equal one, and that one works perfectly
- This is a work-issued laptop, so joined to the domain. Entirely possible that some group policy is at fault. I do have (local) administrative rights though and would like to figure this out - my colleagues need to use hyper-v virtual machines almost constantly
Thanks in advance for any help!
All replies (10)
Monday, November 11, 2019 8:47 AM âś…Answered | 1 vote
Hi ,
You might need to check the listen port in the following path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization
Best Regards,
Candy
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Thursday, November 7, 2019 5:19 AM
Hi ,
>>I have a screenshot but can't post images yet.
Your account just needs to be verified. You can expedite verification by replying to this thread with your request.
Sticky located at top of Forums Issues (not product support) forum.
https://social.msdn.microsoft.com/Forums/en-US/home?forum=reportabug
When you connect to the virtual machine and fails , please refresh the event log to see if there are something related for us to troubleshooting.
Best Regards,
Candy
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Thursday, November 7, 2019 8:09 PM
Hi Candy
Thanks for the reply - unfortunately nothing particular is visible in event log when the connection fails.
From what I see, the vmconnect part works fine so it is not surprising : it does try to connect on all IPv4 and IPv6 addresses my machine has, and once it fails it does not log anything remotely of interest.
I have tried to add the analytic logs (in compmgmt - Application and Service - Microsoft - Hyper-V VMMS and others) and ... unfortunately not much of interest there as well.
I have just tested the things on another machine - so I have 3 machines where everything works and one where it doesn't. Of course that one is the one I use at work and need the most :-)
I'll try to expedite the process of account verification to post the screenshots.
Friday, November 8, 2019 7:03 AM
Hi ,
What's the result when you run** netstat -ano | find "2179"** ?
Please check if the following steps could help you :
1.Select the virtual switch being used by your VMs.
2.Change the connection type and OK
3.Change it back again and OK
4.Restart Hyper-V Virtual Machine Management service (vmms)
Then check if vmconnect connects successfully.
Best Regards,
Candy
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Monday, November 11, 2019 8:01 AM
Hi ,
Just want to confirm the current situations.
Please feel free to let us know if you need further assistance.
Best Regards,
Candy
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Monday, November 11, 2019 8:19 AM
Hi,
just to confirm:
no output from netstat -ano | find "2179" - exactly as the output of Sysinternals TCPView, or Get-NetTCPConnection - not surprisingly as the vmms service is not listening.
In the initial post perhaps I haven't been clear enough but yes I've tried changing the type and even deleting the virtual switch altogether - no change unfortunately. VMMS still not listening.
I have even tried removing Hyper-V altogether and readding it - no change.. it is then that I decided to post here as I seem to be out of options.
Monday, November 11, 2019 8:20 AM
No change unfortunately, the situation is exactly the same...
Monday, November 11, 2019 9:22 AM
Great!
That was correct - it was set to 2179 - so I changed that (to 21791 but I'd guess any unused listening port would suffice).
Then restarted the vmms service (Stop-Service vmms; Start-Service vmms from an elevated PowerShell), and I noted now the vmms does listen to port 21791!
To confirm there were no conflicts I wanted to try again with the default port, so I rolled back the change in registry setting it back to the default value of 2179. Now restarted again the vmms service and now everything works fine!
TL;DR - if you face the same problem I did, try this:
- first changing the virtual switch type in Hyper-V Manager and changing it back then restarting the vmms service
- if that fails, go to the regkey shown above, change the port, restart vmms service and try again
Thanks a lot!
Monday, November 11, 2019 9:26 AM | 1 vote
Hi ,
I am pleased to know that the information is helpful to you.
Have a nice day!
Best Regards,
Candy
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Monday, December 2, 2019 4:48 PM
Thank you this solved my issue too, for some reason after upgrade to win-1909 service not startup correctly on port 2179, change default port fix that