locked
Growing numbers of Microsoft Hyper-V Network Adapters cause problems RRS feed

  • Question

  • Hi All

    Every time I start a VM from the Stopped (Deallocated) state it seems to configure a new Microsoft Hyper-V Network Adapter. I recently had a problem where I couldn't access a file share on another server in the same domain / virtual network and it turned out to be due to having 148 orphaned Microsoft Hyper-V Network Adapters (see my blog post here). Uninstalling these fixed the problem - just by luck that I came across this as a possible fix.

    Is this behaviour by design and are Azure engineers aware of the possible problems it may cause?

    Cheers - Graham


    Blog: http://pleasereleaseme.net

    Wednesday, January 21, 2015 11:38 PM

Answers

All replies

  • Hi Graham,

    You are correct. I checked that on my Azure VM and I found that every time a VM is shut down and deallocated, a new network adapter will be used after it starts next time and the old network adapter is kept hidden. It is by design.

    In addition, it seems that uninstall these hidden network adapters may solve some issues caused by this. I will report it to the related team and thanks for pointing it out.

    Best regards,

    Susie


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, January 23, 2015 7:12 AM
  • So let me clearify a bit more on the network adapter issue.
    the way azure works is that during a reboot of a machine, if everything works fine and the vm host is health no new hyper-v adapters will be created. hyper-v adapters are created based on one of the following.

    * VM host detects that your vm is unhealthy and automatically migrates your vm to a new vm host, to safely make sure everything works some device drivers will be recreated, most commonly the hyper-v adapter
    * you shut down your vm wait a couple of minutes and start it back up. in this case there is no guarantee that the vm host you were on before will be the same vm host your vm gets mounted on, so a new adapter is created (you will know when this is happening based on the status running: provisioning)
    * capturing your vm and recreating it under same cloud service or new cloud service.
    * its also very common during a system maintenance that azure advertises ahead of time, in this case vm's on one box either get updated and your vm stays in the same vm host or your vm get shut down and moves to a new vm host and started up.

    hope this explains a lot more about the network situation.

    Monday, January 26, 2015 5:03 AM
  • Thanks for that, and for posting the explanation on my blog. So, feels like some kind of cleanup task is needed here as judging by my experience the growing numbers of orphaned adapters are going to cause problems for certain classes of user.

    Blog: http://pleasereleaseme.net   LinkedIn:

    Monday, January 26, 2015 8:23 AM
  • I now have another VM with 141 ghost network adapters that has lost the ability to connect to network shares. Can anyone advise how I can script the removal of these?

    Cheers - Graham


    Blog: http://pleasereleaseme.net   LinkedIn:

    Thursday, January 29, 2015 11:30 PM
  • I have discovered this blog post (https://systemcenterpoint.wordpress.com/2014/10/16/hidden-network-adapters-in-azure-vm-and-unable-to-access-network-resources/comment-page-1/).

    He shares a method for using devcon.exe which is part of Visual Studio to identify the IDs of each dead adapter and remove them.  I don't have Visual Studio so it does not solve my problem but it looks like it is helping others.

    This is proving to be a huge problem with my organization.

    Friday, July 31, 2015 6:05 PM
  • Hi, I'm the writer of that blog post, and can confirm that it will solve the problem. You don't need Visual Studio though, you can get it in Windows SDK.

    Jan Vidar Elven

    Wednesday, October 28, 2015 12:53 PM
  • hi

    We have had this same problem - twice - so the original issue hasn't been addressed.

    In June2017 our azure environment was crippled for three weeks, and despite a series of escalating support tickets in the end we gave up trying to identify the problem and rebuilt our VM's from scratch instead.

    The problem happened again this week - but luckily this time I found your post on pleasereleaseme.net and it turned out to be the solution - so thank you very much for posting it (only wish I had seen it 7 months ago).

    Interestingly - the new VMs we built to replace the problem ones from last June were also showing Microsoft Hyper-V Network Adapter #148 - and there were some VM's that we still had running from before that were showing Microsoft Hyper-V Network Adapter #309 (though without the full history starting from #1).

    MS support still don't seem to regard this as a bug though, when I told them I thought it was a bug they said i should post it on the Azure feedback forum as a "suggestion" - which is bizarre - surely they can't have "designed" Azure VM's to lose all connectivity after 148 restarts.

    regards
    -mitch

    p.s. I posted the "suggestion anyway" - see:
    https://feedback.azure.com/forums/34192--general-feedback/suggestions/36549913-fix-or-allow-automated-cleanup-for-orphaned-micros

    Friday, January 18, 2019 11:55 AM