Windows Server TechCenter > Windows Server Forums > Windows Server 2008 R2 Hyper-V > Unstable System due to use of "Allow management operating system to share this network adapter"
Ask a questionAsk a question
 

AnswerUnstable System due to use of "Allow management operating system to share this network adapter"

  • Friday, August 21, 2009 6:19 PMVictor Lindsey Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I just installed Windows Server 2008 R2 w/ Hyper-V.  However, this high-end desktop's network connections are unstable if I enable the Allow management operating system to share this network adapter feature of the network ports.  It uses Marvell's 88E8052 and 88E8053 onboard 1Gb/sec NIC.  This arrangement is very stable and usable on the older Windows Server 2008 SP2 w/ Hyper-V system (installed on another partition).

    Things that I've tried are:
    • Setting NIC speeds to Auto-Negotiate
    • Setting NIC speeds to 1000 Mbps Full Duplex
    • Use default Microsoft network driver
    • Use latest driver from Marvell's website (11.10.10.3, 10-Aug-2009)
    • Enabling and Disabling the Physical NIC(s) (as seen in the parent partition)
    • Enabling and Disabling the Virtual NIC(s) (as seen in the parent partition)

    Enabling/Disabling sometimes cause the link to re-establish itself, but will subsequently disappear on its own. This behavior persists, even when there are no Child partitions running and using these NIC(s).

    Current stable configuration is using one NIC for exclusive "management" purposes (holds the parent partition's home IP address and presence within the domain); and the other NIC for all virtual child partition instances. This may be a recommended practice, but limits my testing, especially when I want to use iSCSI resource like I do with the older operating system.
    • Edited byVictor Lindsey Friday, August 21, 2009 6:21 PMcosmetic correction
    • Edited byVictor Lindsey Friday, August 21, 2009 6:25 PM- cosmetic correction
    •  

Answers

All Replies

  • Saturday, August 22, 2009 4:53 AMBill GrantMVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
      Why not install another NIC for remote access? It doesn't need to be an expensive or high performance one. I am using an old D-Link wireless NIC from the spare parts box. Works fine. (Note that you need to enable wireless networking feature to use a wireless NIC. It is disabled by default).
    Bill
  • Monday, August 24, 2009 4:19 PMVictor Lindsey Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Certainly, adding NICs will allow more flexible Hyper-V usage.  But it shouldn't be necessary for a testing machine.

    While your workaround, I'm sure, works, the situation remains a problem.  Basically, this supported feature, which works well for me under Hyper-V 1.0; now fails to work on Hyper-V 2.0.  Microsoft should consider fixing this.

    Vic
  • Tuesday, August 25, 2009 1:10 AMBill GrantMVPUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
      No doubt they will if they can reproduce it. I have never seen or heard of that problem. It may well be a NIC driver problem, which would only show up with your particular NIC and NIC driver version.

    Bill
  • Tuesday, August 25, 2009 7:55 AMVincent HuMSFT, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    Hi,

     

    I suspect that you encountered the TCP Offloading issue. Please check you have TCP Offloading and also any other offloading disabled on the NIC, these function may cause some network problem.

     

    For more information, you can refer to:

     

    Remote Desktop issue? When Virtual network created (PC only have one NIC adaptor)

    http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2virtualization/thread/5b02a02b-e206-4a05-b27b-7c54ee5f3e2e

     

     

    Best Regards,

    Vincent Hu

     

  • Tuesday, August 25, 2009 5:47 PMVictor Lindsey Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    You’re the man!

    These onboard NICs feature TCP Checksum offloading—a feature that Hyper-V 1.0 does not use.  I understand that Hyper-V 2.0 can use this feature, and it is desirable to do so for better performance.

    Per your suggestion, I reconfigured that NIC which I want to use the Allow management operating system to share this network adapter with this feature now disabled.  The Configure… button under the Properties of the adapter are now configured as:

    ·         IPv4 Checksum Offload as Disabled
    (the other choices are Rx Enabled, Tx & Rx Enabled, and Tx Enabled)

    ·         Large Send Offload (IPv4) as Disabled

    ·         TCP Checksum Offload (IPv4) as Disabled
    (the other choices are Rx Enabled, Tx & Rx Enabled, and Tx Enabled)

    ·         UDP Checksum Offload (IPv4) as Disabled
    (the other choices are Rx Enabled, Tx & Rx Enabled, and Tx Enabled)

    The connection is now stable.  I must say, however, that I’m greatly disappointed that this undocumented restriction exists.  And I surely would like it to be lifted through a fix.

    I’m leaving the other NIC with Allow management operating system to share this network adapter disabled, and all  Checksum Offloads Enabled; to take advantage of the potential for improved performance.

    • Edited byVictor Lindsey Tuesday, August 25, 2009 5:51 PM- minor correction
    •  
  • Sunday, December 06, 2009 2:18 PMArchi Tech Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    This solved the same problem that I had!  I worked solid on this for 3 days and this finally resolved it for me. 

    I am using the following server motherboard... Asus P7F-X that has a pair of on-board Marvell NICs... Marvell 88E8056 PCI-E GbE. 

    I echo Victor's sentiments that this should be lifted through a fix.  I had already run the Windows Update on the server and it didn't catch this.