Hyper-V, Windows Server 2008 R2

Slow RDP Performance on a Server 2008 R2 Hyper-V Host

Hi,

I recently encountered a problem on my Server 2008 R2 machine which is running Server 2008 R2 with Hyper-V installed. After creating a Virtual Network, when i connected via RDP to the server the performance was unbearable and was very unusable. After a little playing about i managed to find the problem. I disabled IPv4 Checksum Offload on the Virtual Network Adapter and bingo, performance was back to normal again 🙂

image

52 Comments

  1. I just had to say thank you. I had the problem for months and everywhere it said was vista or tcp fix. Your solution worked perfectly thank you again

  2. I just had to say thank you. I had the problem for months and everywhere it said was vista or tcp fix. Your solution worked perfectly thank you again

  3. I had another situation: Remote Desktop to the host worked fine, but was unusable when connecting to guests OSes.
    Disabling IPv4 Checksum offload — in the guest OS — fixed it.

  4. I had another situation: Remote Desktop to the host worked fine, but was unusable when connecting to guests OSes.
    Disabling IPv4 Checksum offload — in the guest OS — fixed it.

  5. This is technically not a Hyper-V problem but a NIC driver problem that goes back to the NIC manufacturer – and the problem has been around since the days of NT4 as well as the first 3Com NICs that supported offloading.
    This gets discussed in the Hyper-V forums quite a bit, as the only place to set the driver behavior is in the NIC settings at the Hyper-V level – the VMs just get whatever NIC driver features are turned on at the physical NIC.

  6. This is technically not a Hyper-V problem but a NIC driver problem that goes back to the NIC manufacturer – and the problem has been around since the days of NT4 as well as the first 3Com NICs that supported offloading.
    This gets discussed in the Hyper-V forums quite a bit, as the only place to set the driver behavior is in the NIC settings at the Hyper-V level – the VMs just get whatever NIC driver features are turned on at the physical NIC.

  7. This solved my problem, but I had to do some detective work due to multiple NICs and Hyper-V Virtual Networking:
    Tip: open Network Connections and be sure to use ‘Details’ view.
    Configuration:
    2 on-board Intel NICs > Teamed NIC > Virtual LAN
    add-in Realtek RTL8169/8110 NIC > Virtual WAN

    If you look carefully at the “Name” column and “Device Name” columns, and then in Hyper-V Virtual Network Manager you should be able to figure out the chain of adapter usage (physical and virtual).

    Note that when I have multiple NICs, I rename the objects in the “Network Connection” window so I can easily differentiate between the LAN and WAN NICs.

    For me, the LAN side worked fine, but I had problems with the WAN connection (2 different servers, identical problem). Through trial and error, I needed to change the “Virtual WAN” adapter – this would be the adapter that actually has the WAN IPv4 address (as Neil describes: the virtual adpater). From some other threads, I disabled anything to do with Offload, then re-enabled all except the IPv4 Checksum Offload property – problem *finally* solved!

    This applies to the host server, but I suspect if I had a VM using the Realtek I would have to make a similar change in the VM.

  8. This solved my problem, but I had to do some detective work due to multiple NICs and Hyper-V Virtual Networking:
    Tip: open Network Connections and be sure to use ‘Details’ view.
    Configuration:
    2 on-board Intel NICs > Teamed NIC > Virtual LAN
    add-in Realtek RTL8169/8110 NIC > Virtual WAN

    If you look carefully at the “Name” column and “Device Name” columns, and then in Hyper-V Virtual Network Manager you should be able to figure out the chain of adapter usage (physical and virtual).

    Note that when I have multiple NICs, I rename the objects in the “Network Connection” window so I can easily differentiate between the LAN and WAN NICs.

    For me, the LAN side worked fine, but I had problems with the WAN connection (2 different servers, identical problem). Through trial and error, I needed to change the “Virtual WAN” adapter – this would be the adapter that actually has the WAN IPv4 address (as Neil describes: the virtual adpater). From some other threads, I disabled anything to do with Offload, then re-enabled all except the IPv4 Checksum Offload property – problem *finally* solved!

    This applies to the host server, but I suspect if I had a VM using the Realtek I would have to make a similar change in the VM.

  9. Seemed to work when I first set this, but then pretty quickly reverted to the super sloooowness. I have checked that this setting is stil set to Disable and it is 🙁

  10. Seemed to work when I first set this, but then pretty quickly reverted to the super sloooowness. I have checked that this setting is stil set to Disable and it is 🙁

  11. Disabling all checksum offload settings in my HARDWARE NIC Realtek driver also fixed this problem for me AND got me (strange enough) a much higher network performance !!

    Instead of 5.3Mb/s it’s now 7.1MB/s AND no BSOD anymore !! 🙂

    (I am running Windows 7 x64 SP1 Ultimate)

  12. Disabling all checksum offload settings in my HARDWARE NIC Realtek driver also fixed this problem for me AND got me (strange enough) a much higher network performance !!

    Instead of 5.3Mb/s it’s now 7.1MB/s AND no BSOD anymore !! 🙂

    (I am running Windows 7 x64 SP1 Ultimate)

  13. DO NOT DO THIS if you manage your hyper-v serves with SCVMM. Comms with SCVMM are disrupted completely, and the servers disappear from DNS. If you re-add the servers A record in DNS then the setting magicallty gets reversed (which takes around 5 minutes)!!!

  14. DO NOT DO THIS if you manage your hyper-v serves with SCVMM. Comms with SCVMM are disrupted completely, and the servers disappear from DNS. If you re-add the servers A record in DNS then the setting magicallty gets reversed (which takes around 5 minutes)!!!

  15. Update: the above comms issues are seen if you remove the offload setting on the VIRTUAL adapter. If you do it on the PHYSICAL adapter there is no such disruption (apart from the usual 20 second disconnect whilst the adapter reconfigures itself).

  16. Update: the above comms issues are seen if you remove the offload setting on the VIRTUAL adapter. If you do it on the PHYSICAL adapter there is no such disruption (apart from the usual 20 second disconnect whilst the adapter reconfigures itself).

  17. Thank you, thank you, thank you.. etc etc (lots of thank you’s)

    This problem has nearly killed me physically in the past few days.

    Disabling IPv4 Checksum Offload worked like a charm.

  18. Thank you, thank you, thank you.. etc etc (lots of thank you’s)

    This problem has nearly killed me physically in the past few days.

    Disabling IPv4 Checksum Offload worked like a charm.

Leave a Reply

Your email address will not be published. Required fields are marked *