Unable to Use Compose with Windows Containers

Description

When running nerdctl compose up, by default a --hostname parameter is passed to nerdctl run which is invalid on Windows OS.

https://github.com/containerd/nerdctl/blob/v2.0.2/pkg/containerutil/container_network_manager_windows.go#L50-L64

https://github.com/containerd/nerdctl/blob/v2.0.2/pkg/composer/serviceparser/serviceparser.go#L608-L614

Steps to reproduce the issue

Use a similar docker-compose.yaml file:

services:
  github:
    image: mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2019
    isolation: hyperv
    platform: windows/amd64
    restart: unless-stopped
    scale: 1
    # Hostname gets set and causes problem

nerdctl compose up

Describe the results you received and expected

We would expect the container to be started successfully.

> nerdctl compose up
time="2025-01-10T18:35:02Z" level=warning msg="Ignoring: service github: [Isolation]"
time="2025-01-10T18:35:02Z" level=info msg="Ensuring image mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2019"
time="2025-01-10T18:35:02Z" level=info msg="Creating container runners-github-1"
time="2025-01-10T18:35:02Z" level=info msg="Running [C:\\Program Files\\nerdctl\\nerdctl.exe run --cidfile=C:\\Users\\user\\AppData\\Local\\Temp\\2\\compose-2714756652\\cid -l=com.docker.compose.project=runners -l=com.docker.compose.service=github -d --name=runners-github-1 --pull=never --net=runners_default --hostname=github --platform=windows/amd64 --restart=unless-stopped mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2019]"
time="2025-01-10T18:35:03Z" level=fatal msg="failed to verify networking settings: the following networking arguments are not supported on Windows: [--hostname]"
time="2025-01-10T18:35:03Z" level=fatal msg="error while creating container runners-github-1: error while creating container runners-github-1: exit status 1"

What version of nerdctl are you using?

nerdctl version
time="2025-01-10T18:36:06Z" level=warning msg="unable to determine runc version: exec: \"runc\": executable file not found in %PATH%"
Client:
 Version:       v2.0.2
 OS/Arch:       windows/amd64
 Git commit:    1220ce7ec2701d485a9b1beeea63dae3da134fb5
 buildctl:
  Version:      v0.18.2
  GitCommit:    e4da654b1251f91e914fab18eba33743aefd7080

Server:
 containerd:
  Version:      v2.0.1
  GitCommit:    88aa2f531d6c2922003cc7929e51daf1c14caa0a
 runc:
  Version:

Are you using a variant of nerdctl? (e.g., Rancher Desktop)

None

Host information

Windows Server 2019

Microsoft Windows [Version 10.0.17763.6659]

@AkihiroSuda

Wondering if we should just null m.netOpts.Hostname and issue a warning instead of hard failing on it.

@AkihiroSuda wdyt?

@apostasie

@apostasie Tested this on Docker with the provided Compose file using WS22. I also tested with the hostname in the compose file and it worked.

#docker-compoase.yaml
services:
  github:
    image: mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2022
    isolation: hyperv
    platform: windows/amd64
    restart: unless-stopped
    scale: 1
    hostname: testCtr

> docker inspect 5418727e348d  --format "{{ .Config.Hostname }}"
testCtr

Digging around the compose-spec/compose-go and docker/compose, there doesn't appear to be any explicit handling that marks hostname as an invalid field for Windows.

Additional testing is required in nerdctl to determine the implications of explicitly setting the hostname value or allowing it to default to the service name, on Windows. This will help identify any potential restrictions from Compose or the underlying container runtime.

@apostasie Tested this on Docker with the provided Compose file using WS22. I also tested with the hostname in the compose file and it worked.

#docker-compoase.yaml
services:
github:
image: mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2022
isolation: hyperv
platform: windows/amd64
restart: unless-stopped
scale: 1
hostname: testCtr

docker inspect 5418727e348d --format "{{ .Config.Hostname }}"
testCtr
Digging around the compose-spec/compose-go and docker/compose, there doesn't appear to be any explicit handling that marks hostname as an invalid field for Windows.

Additional testing is required in nerdctl to determine the implications of explicitly setting the hostname value or allowing it to default to the service name, on Windows. This will help identify any potential restrictions from Compose or the underlying container runtime.

Could it be a CNI plugins limitation on windows?

Perhaps. But there have been some developments in the CNI-plugins since the code was written. Will test this using both microsoft/windows-container-networking and containernetworking/plugins. Not sure if nerdctl supports containernetworking/plugins yet for Windows.

@apostasie

@apostasie Removed the --hostname from the nonZeroArgs. The error in #3808 is resolved, but then the hostname is not set correctly. Need to do further investigation on where the hostname value is set.

Draft PR: https://github.com/containerd/nerdctl/pull/3963/files

#docker-compose.yaml

services:
  github:
    image: mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2022
    isolation: hyperv
    platform: windows/amd64
    restart: unless-stopped
    scale: 1
    hostname: github-container  # Set a hostname
    command: ["ping", "-t", "localhost"]

Docker

```bash
> docker exec -it 24a4490b4af9 hostname

github-container
```

nerdctl

```bash
> nerdctl exec -it 2c539828bb76 hostname

3f372f051f8a
```

Might want to try and see what happens on Windows when you do pass --hostname (to figure out where this restriction is coming from).

--hostname is not a valid flag for both nerdctl compose up and docker compose up

--hostname is not a valid flag for both nerdctl compose up and docker compose up

Yep, so I guess the million dollar question is how do they set the hostname then...

Actually, is docker run --hostname allowed (not compose)?

@apostasie

@apostasie - it shouldn't be a valid option but I can't test that at the moment. It is blocked in nerdctl run as well.

My original point of this issue was not to get hostname working, it was to stop compose from auto-appending a hostname for Windows containers when not specified.

Of course if the alternative was to get hostname working instead, that sounds better to me.

Tagging containerd/discussions/9499

After further investigation, we found that containerd does not persist the hostname or update the computer name for Windows containers when using both Docker + containerd and nerdctl + containerd.

Will continue investigating this issue within containerd.

My original point of this issue was not to get hostname working, it was to stop compose from auto-appending a hostname for Windows containers when not specified.

This is also my goal, since I don't care about the hostname in my context, is there a workaround I can put in my compose file to achieve this?

Obviously if we could get hostname working that'd be great, but currently it seems like I cannot use nerdctl compose run at all due to this issue, so I was wondering if we could just disable hostname support in the interim (and then leave the issue open, albeit renamed).

(I can use nerdctl compose build already, albeit without pull or cache_to support.)

There does not seem to be any updates on this issue. Is there a potential workaround that can be used? It seems like this issue really only affects WS2019 servers. I've encountered similar behaviour in testing.

following networking arguments are not supported on Windows: [--hostname]

It's been a while since the last update on this issue, and numerous versions have been released since,
My current stack on Windows Server 2022:

nerdctl 2.4.1
containerd 2.4.1
WinCni 0.3.3
BuildKit 0.33.1

Here is my failing use case, compose.yaml:

services:
  garnet:
    command: ["--logger-level", "Debug", "--lua"]
    deploy:
      replicas: 1
    image: ghcr.io/microsoft/garnet-nanoserver-ltsc2022
    ports:
    - "6379:6379/tcp"

Verification:

❯ nerdctl compose config
name: garnet
services:
    garnet:
        command:
            - --logger-level
            - Debug
            - --lua
        deploy:
            replicas: 1
        image: ghcr.io/microsoft/garnet-nanoserver-ltsc2022
        networks:
            default: null
        ports:
            - mode: ingress
              target: 6379
              published: "6379"
              protocol: tcp
networks:
    default:
        name: garnet_default

Run attempt:

❯ nerdctl compose up
INFO[0000] Creating network garnet_default
INFO[0000] Ensuring image ghcr.io/microsoft/garnet-nanoserver-ltsc2022
INFO[0000] Creating container garnet-garnet-1
INFO[0000] Running [C:\Program Files\nerdctl\nerdctl.exe run --cidfile=C:\Users\MATEUS~1.LOS\AppData\Local\Temp\4\compose-483976349\cid -l=com.docker.compose.project=garnet -l=com.docker.compose.service=garnet -l=com.docker.compose.config-hash=be2b971e2ba87b6e699abbe3d6dbfffb3817ee30c17d4b2be0dcc7d8d3782502 -d --name=garnet-garnet-1 --pull=never --net=garnet_default --hostname=garnet -p=6379:6379/tcp --restart=no ghcr.io/microsoft/garnet-nanoserver-ltsc2022 --logger-level Debug --lua]
FATA[0000] failed to verify networking settings: the following networking arguments are not supported on Windows: [--hostname]
FATA[0001] error while creating container garnet-garnet-1: error while creating container garnet-garnet-1: exit status 1

Navigation Menu

Repository navigation

Unable to Use Compose with Windows Containers #3808

Description

Steps to reproduce the issue

Describe the results you received and expected

What version of nerdctl are you using?

Are you using a variant of nerdctl? (e.g., Rancher Desktop)

Host information

following networking arguments are not supported on Windows: [--hostname]

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unable to Use Compose with Windows Containers #3808

Description

Description

Steps to reproduce the issue

Describe the results you received and expected

What version of nerdctl are you using?

Are you using a variant of nerdctl? (e.g., Rancher Desktop)

Host information

Activity

apostasie commented on Jan 24, 2025

TinaMor commented on Feb 24, 2025

apostasie commented on Feb 24, 2025

TinaMor commented on Feb 24, 2025

TinaMor commented on Mar 3, 2025

apostasie commented on Mar 3, 2025

TinaMor commented on Mar 3, 2025

apostasie commented on Mar 3, 2025

apostasie commented on Mar 3, 2025

nerddtvg commented on Mar 4, 2025

TinaMor commented on Mar 17, 2025

TinaMor commented on Mar 18, 2025

ShadowLNC commented on Mar 3, 2026

bsnuggs1 commented on May 7, 2026

mloskot commented on Oct 20, 2026

following networking arguments are not supported on Windows: [--hostname]

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions