1

We have a Windows Server 2019 Hyper-V host with a Windows 10 VM guest with SQL installed.

The guest has slow file copy operations and SQL select queries.

The host has 2x 10G LAN ports. One port is shared with the VM using Virtual Switch and another port is dedicated with host server.

Effectively, two ports are used by host with different subnet range.

We conducted network speed tests using iPerf, and the results indicate that outgoing transfer speeds are effectively zero in the following scenarios:

  1. From the VM to outside the VM
  2. From the Host to outside the Host

This behavior is consistent across both network adapters on the host machine.

However, there is no issue when:

  1. Copying data between drives within the VM

  2. Copying data from other PCs on the network to the VM or Host (Incoming traffic)

Event Logs & IntelDCB Warning

The Event Viewer, has frequent Application Event ID 791 logged for IntelDCB, with the message:

"Application feature on a device has changed to non-operational." (Fiber Channel over Ethernet).

We referred to the Intel Ethernet controller datasheet that notes Intel Data Center Bridging (IntelDCB) is responsible for ensuring that network packets are transmitted reliably and without loss.

However, we're uncertain about the exact corrective steps.

Online Research & Attempted Fixes

Our research suggests the issue could be related to:

  • Virtual switch misconfiguration
  • Antivirus or firewall interference
  • Corrupted NIC drivers
  • Network adapter Offload settings

Virtual Machine Queue (VMQ) settings: As per this forum post, it refers to VMQ solving the issue. We disabled and re-enabled VMQ, but the issue persists.

Additionally, CPU and memory usage on both the host and VM are within acceptable limits.

We are looking to understand:

What could be the root cause of zero outgoing packet transfers in this setup?

What troubleshooting or configuration changes might resolve it?

Troubleshooting Steps Tried:

  • Connected one network port dedicated to VM
  • Interchanged the adapters with VM
  • Changed network cables, ports in network switch etc.
  • Verified VMQ settings
  • Tested with different antivirus/firewall settings
  • Checked with latest NIC drivers
  • Reset & configuring the virtual switch
  • Enabled Receive Segment Coalescing (RSC) and later disabled

iPerf Results Summary

Test 1: Host → VM (Outgoing from host to VM) Connecting to host xxx, port xx
[ 4] local xxxx port xxx connected to xxx port xxx
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 693 MBytes 582 Mbits/sec sender
[ 4] 0.00-10.00 sec 693 MBytes 582 Mbits/sec receiver

Test 2: VM → Host (Outgoing from VM to host) Connecting to host xxx, port xx
[ 5] local xxxx port xxx connected to xxx port xxx
[ 5] 0.00-10.01 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-10.01 sec 3.90 GBytes 3.35 Gbits/sec receiver

Hardware Specifications

Host OS: Windows Server 2019

VM OS: Windows 10 with SQL Server Standard 2017

Antivirus Details: Sentinelone Singularity Control

Motherboard: ASRock ROME2D16-2T (Rack)

Processor: AMD EPYC 7373X – 16 Cores / 32 Threads, 3.05/3.80GHz, 768MB L3 Cache

Ethernet: Intel® X550-AT2 – 2× 10GbE RJ45 Ports

NICs: 2 physical network adapters

RAID Controller: LSI MegaRAID 9271-4i SGL SATA+SAS (LSI00328)

Disk Drives: WD Blue SN5000 NVMe SSD – 500GB, up to 5000 MB/s

Samsung PM893 Enterprise SATA SSD – 480GB, up to 550 MB/s

WD Red SA500 NAS SATA SSD – 2TB, up to 560 MB/s

We would appreciate any suggestions or insights from the community regarding potential causes or resolution steps. Thanks in advance.

— EDIT 12.6.2025 ----

I guess we could eliminate the network switch as a suspect based on today’s testing. Because even when we connect the affected host ( i.e host of this VM) to another host through a direct connection, without any network switches in between, we are still facing this issues. As far as the network switch is concerned, the random packet loss issue hasn’t occurred for any other devices on the same switch, either as a source or destination.

We shall check next by uninstalling the endpoint protection software, and using other OS as host PC for the VM instead of Server 2019.

8
  • 1
    Well, you have a rather low end disc setup - what you expect? Serious here. File copy hits the discs (as do many SQL operations) and live and die by IO. You seem to randomly hack around on the VM side - but ignore the part where the data must be stored on disc. Check latency of all relevant elements. Also note how 2019 is - ah - "problematic". As in: It was a nice thing when it came out, but they fixed and improved a LOT of stuff - also in the IO area - in later builds. Finally - ONE VM... why? As in: if anything runs on the host, it has priority. Commented Jun 11 at 10:30
  • 1
    @TomTom Thank you for the comment. Do you mean the disks used for the VM and SQL databases are not upto the mark ? We are currently using both the "WD Blue SN5000 NVMe SSD" as well as the "Samsung PM893 Enterprise SATA SSD" for SQL databases. Commented Jun 12 at 6:41
  • 1
    @TomTom also- We have checked and installed all latest KB updates and builds to the Server 2019 host, yet packet loss is present... Commented Jun 12 at 6:47
  • How do we check latency of the "all relevant elements" except the discs? Do you have any procedure, methods or tools which you could provide us... Commented Jun 12 at 6:58
  • Performance counter - the point is most people go by throughput etc., that are all useless metrics because they depend on the disc subsystem. There is one measuring how long a disc takes to process a request. That is the only one that matters - the moment this goes up, well, the disc is overloaded. Disch hardware counters are relevant here. On the Host - NOT the VM's. Commented Jun 12 at 13:03

1 Answer 1

1

Just wanted to come back and post saying the issue is solved now.  We reset the network driver. Thank you for the responses!

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.