Docker build hangs only on one Hyper-V host

Question

Docker build hangs only on one Hyper-V host

Mahesh Apine 0

Details

I am troubleshooting a Docker build issue in a corporate environment. All hostnames, IP addresses, repository names, and other identifying information have been anonymized for security reasons.

Environment

Impacted Host: Dedicated Windows Hyper-V server
Working Host: Local Windows workstation running Hyper-V
Ubuntu Server 24.04 LTS Virtual Machine
Docker Engine 29.x
.NET 8 SDK
Nexus Repository Manager (HTTP)
Hyper-V External Virtual Switch

Problem

A Docker image build hangs during the dotnet restore stage, but only when the Ubuntu VM is hosted on the dedicated Hyper-V server.

The exact same Ubuntu VM, Docker Engine version, .NET SDK, Dockerfile, application source code, and Nexus repository work successfully when the VM is hosted on the local Hyper-V workstation.

The issue consistently follows the Hyper-V host, not the Ubuntu VM.

Dockerfile

RUN dotnet restore "WebApi.csproj" \

--source "http://<NEXUS>/repository/nuget.org-proxy/index.json" \

--source "file:///root/.Package/AesCrypto" \

--source "file:///root/.Package/License"

The same Ubuntu VM, Docker Engine, .NET SDK, Dockerfile, application source, and Nexus repository work successfully when the VM is hosted on another Hyper-V host.

What I’ve already verified

Same VM works on another Hyper-V host.
Created a fresh Ubuntu VM and reproduced the issue on the impacted host.
Same Docker version, Ubuntu version, .NET SDK, Dockerfile, and source code.
Same Nexus repository and NuGet sources.
Both Hyper-V hosts are on the same subnet and governed by the same network/firewall policy.
Physical Ubuntu and Ubuntu Desktop complete the same Docker build successfully.
Using the same VM/IP on another environment also completes successfully.

Network observations

TCP connection to Nexus is established successfully.
tcpdump shows continuous bidirectional traffic with thousands of exchanged packets.
dotnet restore remains stuck indefinitely only on the impacted Hyper-V host.
I am collecting Wireshark captures from both the working and impacted Hyper-V hosts for comparison.

Question

Since the issue consistently follows the Hyper-V host rather than the Ubuntu VM, what additional Windows/Hyper-V diagnostics would you recommend?

Has anyone encountered a Hyper-V host-specific issue where long-running HTTP traffic (such as dotnet restore) hangs only on one Hyper-V host while an identical VM works correctly on another?

I’m particularly interested in Hyper-V networking, virtual switch, NIC driver/firmware, VMQ, RSS, RSC, LSO, NDIS filter drivers, or any known Hyper-V host-specific issues. The same Ubuntu VM, Docker Engine, .NET SDK, Dockerfile, application source, and Nexus repository work successfully when the VM is hosted on another Hyper-V host.

What I’ve already verified

Same VM works on another Hyper-V host.
Created a fresh Ubuntu VM and reproduced the issue on the impacted host.
Same Docker version, Ubuntu version, .NET SDK, Dockerfile, and source code.
Same Nexus repository and NuGet sources.
Both Hyper-V hosts are on the same subnet and governed by the same network/firewall policy.
Physical Ubuntu and Ubuntu Desktop complete the same Docker build successfully.
Using the same VM/IP on another environment also completes successfully.

Network observations

TCP connection to Nexus is established successfully.
tcpdump shows continuous bidirectional traffic with thousands of exchanged packets.
dotnet restore remains stuck indefinitely only on the impacted Hyper-V host.
I am collecting Wireshark captures from both the working and impacted Hyper-V hosts for comparison.

Question

Since the issue consistently follows the Hyper-V host rather than the Ubuntu VM, what additional Windows/Hyper-V diagnostics would you recommend?

Has anyone encountered a Hyper-V host-specific issue where long-running HTTP traffic (such as dotnet restore) hangs only on one Hyper-V host while an identical VM works correctly on another?

I’m particularly interested in Hyper-V networking, virtual switch, NIC driver/firmware, VMQ, RSS, RSC, LSO, NDIS filter drivers, or any known Hyper-V host-specific issues.

0 comments

1 answer

Your answer

Answer 1

Hello @Mahesh Apine

Since the problem occurs on only one Hyper-V host while the same Docker build completes successfully on other hosts, this points to a host-specific issue rather than a problem with the Dockerfile or application itself.

A few things I'd recommend comparing between the working and non-working hosts:

Docker Engine and Docker Desktop/Engine versions (docker version and docker info)
Windows Server build and cumulative update level (winver or systeminfo)
Hyper-V integration services and virtualization configuration
Available CPU, memory, and disk space during the build
Storage performance and antivirus/EDR exclusions for Docker's data directory

It would also be useful to determine where the build hangs by running:

docker build --progress=plain --no-cache

If BuildKit is enabled, you could also test whether the behavior changes by temporarily disabling it:

set DOCKER_BUILDKIT=0

or by using the legacy builder for comparison.

Additionally, check whether the hang coincides with:

pulling a base image,
a RUN instruction,
file copy (COPY/ADD),
or network access from within the container.

If it consistently stalls at the same build step only on one Hyper-V host, I'd also review:

Windows Event Viewer (Hyper-V, HCS, and Docker-related logs)
docker events
Resource Monitor for disk I/O or storage latency
Any endpoint security software that may be scanning Docker layers or the build cache.

If you can share the output of docker version, docker info, the Windows build number, and the last line shown with --progress=plain, it should help narrow down whether this is a BuildKit, storage, networking, or Hyper-V issue.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Mahesh Apine 0 Reputation points

2026-08-04T05:11:08.14+00:00

Thank you for your suggestions.

I have already compared the Docker Engine version, Docker configuration, Ubuntu version, .NET SDK, Dockerfile, and application source code. I also tested with BuildKit disabled and the issue persists.

The build consistently hangs during the dotnet restore step only when the VM is hosted on one dedicated Hyper-V server. The same Ubuntu VM completes successfully on another Hyper-V host and on physical Ubuntu systems.

Both Hyper-V hosts are on the same subnet and governed by the same firewall/network policy.

An additional observation is that if unrestricted (open) internet access is provided to the impacted environment, the Docker build completes successfully. However, under the restricted corporate network policy, the issue occurs only on this specific Hyper-V host, while another Hyper-V host with the same network policy completes the build successfully.

TCP connections to the Nexus repository are successfully established, and tcpdump shows continuous bidirectional packet exchange while the build is stalled. I am also collecting Wireshark traces from both the working and impacted Hyper-V hosts for comparison.

I have not yet compared Hyper-V Event Viewer logs or docker events. Are there any specific Hyper-V or Windows networking events, NIC settings, or virtual switch diagnostics that you would recommend reviewing?