search

microsoft / hcsshim

Windows - Host Compute Service Shim
MIT License
578 stars 259 forks source link

hcsshim: timeout waiting for notification extra info #152

Open pradley opened 6 years ago

pradley commented 6 years ago

When trying to run my Rabbit image from my compose file I get this error below.

ERROR: for bin_Rabbit_1 Cannot start service Rabbit: container 4c49c5ce1c9be3f3deca474403b7a9df44ac09151bae5126c60768cf01767428 encountered an error during CreateContainer: hcsshim: timeout waiting for notification extra info: {"SystemType":"Container","Name":"4c49c5ce1c9be3f3deca474403b7a9df44ac09151bae5126c60768cf01767428","Owner":"docker","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\ProgramData\Docker\windowsfilter\4c49c5ce1c9be3f3deca474403b7a9df44ac09151bae5126c60768cf01767428","Layers":[{"ID":"dee86350-459f-580c-ae1e-fcc1bee0baa2","Path":"C:\ProgramData\Docker\windowsfilter\c056770fbd90992091b4d16fe9c2b608d739689b9b8d6f8b24edc6ecd36cfb3c"},{"ID":"cf555c82-e82c-5103-9328-02e79a453583","Path":"C:\ProgramData\Docker\windowsfilter\a1a2460d2ca841aac7e92a84fba5af4fa61274d960eff41ac1d5384bfff30efd"},{"ID":"d21d7c62-9717-5f8c-b40b-2e20f2c99b04","Path":"C:\ProgramData\Docker\windowsfilter\80fbafed497f150bbbdec469621cdb01494ac302443ee66be797ec167a88607c"},{"ID":"34db3c60-39de-51dc-bfbf-e9c907c6e86b","Path":"C:\ProgramData\Docker\windowsfilter\a10b48318221d634f2df7d4f6bbd8c4c24170cf92c8b54eaf15d21c6d12efe45"},{"ID":"5fb20f07-e3dc-5034-86a3-f1103c3377c3","Path":"C:\ProgramData\Docker\windowsfilter\4cfafd1cab11aa92b130ef6c3ed9a0f41d89ae500255424901c50408edbeb45b"},{"ID":"dbe867e1-5401-5747-9edc-02780de37593","Path":"C:\ProgramData\Docker\windowsfilter\802c32841d34c97eb63462666065b9fec57a4ea2aa9373bffe1425790078f4d1"},{"ID":"12b89f02-8d16-598e-86b0-f7c17f82612e","Path":"C:\ProgramData\Docker\windowsfilter\53801ceea5ae8088b78b6af799956087740807560aece1f504f1bb3c40efdee6"},{"ID":"28fb85e9-113c-5072-9ca5-d7de54103a5c","Path":"C:\ProgramData\Docker\windowsfilter\f6b75b2ad9713292ba588c5cd81a1efa8aadbebd6f23811cdd13327f0504d1fe"},{"ID":"2dea95ad-c46c-5ab3-a9eb-cac8df2c1451","Path":"C:\ProgramData\Docker\windowsfilter\33dcdab745abced6c32b832722b708284da1cc5ab049fe418af8c5ae42659670"},{"ID":"0df81b3f-652b-596c-8223-acaab6087dad","Path":"C:\ProgramData\Docker\windowsfilter\2c2d427c6268e0520729be4107b6c3839fd63ffdd05236a5cc9cbdc6b3ce7190"},{"ID":"de2d5623-089a-5d2c-944e-9246b670b4e6","Path":"C:\ProgramData\Docker\windowsfilter\16f6cc2dd45bfbd1be8b3255612f7740731744ee6f6dbb3f049eefd535df962f"},{"ID":"fd01999c-0b74-515c-ad9b-71b4236015eb","Path":"C:\ProgramData\Docker\windowsfilter\8b8f0948e6aa5ad08b3042a03c0bbd5ffd971d9f7e26d052d5afde4abb1837ad"},{"ID":"fc9ade98-724f-5fbb-8363-1ba433028c3d","Path":"C:\ProgramData\Docker\windowsfilter\abe09c74ed9ef55cde9a138b9b1cba2a3d987a43d2a3d492018a9e8b2d2bd94e"},{"ID":"60162656-a118-5f4a-a081-7114cce85437","Path":"C:\ProgramData\Docker\windowsfilter\1d6314999ada0560529b2fbbb14d4f35341cd2911959c0fe9be85d736ff3ca29"},{"ID":"fa0bbe42-6d85-531a-bfcb-1822906ff2c3","Path":"C:\ProgramData\Docker\windowsfilter\beb26da51fdda5d9d72ba60069d9b65fe35052013fac5f765775fc6e9224bf6b"},{"ID":"1d9b3c2c-68e4-5e56-82a9-3073faa6b72a","Path":"C:\ProgramData\Docker\windowsfilter\f420d7b6053c27051b688473386b8b621cf2a6f3ecca9f2600dfda0f2de20a92"}],"MemoryMaximumInMB":3072,"HostName":"4c49c5ce1c9b","HvPartition":true,"EndpointList":["221d7a6a-4b70-4f8f-bccd-afa1b6deb906"],"HvRuntime":{"ImagePath":"C:\ProgramData\Docker\windowsfilter\beb26da51fdda5d9d72ba60069d9b65fe35052013fac5f765775fc6e9224bf6b\UtilityVM"},"AllowUnqualifiedDNSQuery":true}

If I run the rabbit image using the docker run command the image will work fine. Only through compose it gives this error! I understand that its timing out waiting for a notification. I just dont know how exactly to go about fixing this or what to look at.

lowenna commented 5 years ago

@ducttapecoder-vt

Can you provide output of docker version and docker info? And detailed repro steps/files needed to repro? And an indication if you're hitting this using Hyper-V containers or process isolated? 100% repro or intermittent? We might need ETL traces from Windows to root cause based on above.

cowlinator commented 5 years ago 
Client: Docker Engine - Community
 Version:           18.09.2
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        6247962
 Built:             Sun Feb 10 04:12:31 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.2
  API version:      1.39 (minimum version 1.24)
  Go version:       go1.10.6
  Git commit:       6247962
  Built:            Sun Feb 10 04:28:48 2019
  OS/Arch:          windows/amd64
  Experimental:     false
 Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 1
Server Version: 18.09.2
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: ics l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 17134 (17134.1.amd64fre.rs4_release.180410-1804)
Operating System: Windows 10 Enterprise Version 1803 (OS Build 17134.590)
OSType: windows
Architecture: x86_64
CPUs: 12
Total Memory: 15.92GiB
Name: US509A4C4495E8
ID: 4JZP:RUDL:BNMW:GW7Z:EONZ:ASRI:GAGK:EW6Q:BEQ2:QBDE:FHLU:AQUT
Docker Root Dir: C:\ProgramData\Docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: -1
 Goroutines: 26
 System Time: 2019-03-05T17:20:41.8230139-08:00
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine

Unfortunately, the images I am working with are proprietary and I cannot share them. But, they are based on servercore:1709_KB4480978 (10.0.16299.904).

This is on Windows 10, so I believe that means it must be hyper-v.

I can't 100% repro immediately after docker system prune -a, but after running the same image a number of times in a row, it will fail, and then continues to fail consistently after that.

lowenna commented 5 years ago

@cowlinator Ah, this is 1803. See my previous comment. I'm really looking for a repro where this repros on Windows version 1809/RS5/Windows Server 2019.

ducttapecoder-vt commented 5 years ago

As mentioned previously I'm running the mssql-server-windows-developer dockerfile on Win 10 1809 with hyper-v.

Had a little more detail at https://github.com/Microsoft/mssql-docker/issues/420

Repro steps: 1) High RAM usage (committed is higher than total physical, e.g. 8.7GB committed, 8GB physical). Lots of hard faults indicated in resource manager. 2) Slow HDD may be part of the equation to increase delays with vm swap 3) docker build -m 4GB -t mssql-repro-test .

It's not 100% consistent but I definitely got it on several different machines many times. Once I started reducing my RAM usage and fiddling with the -m parameter I finally got the image to build consistently. 2GB seemed like a sweet spot. 1GB wasn't enough for the container to install CU13 when I tried to modify it. 4GB seemed to just make the RAM issue worse.

Sometimes I got a generic timeout, other times it called out hcsshim. Every time I got a "created" container that doesn't respond to 'stop', 'kill', or 'rm'. Had to restart docker desktop before I could 'rm' it.

Client: Docker Engine - Community
 Version:           18.09.2
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        6247962
 Built:             Sun Feb 10 04:12:31 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.2
  API version:      1.39 (minimum version 1.24)
  Go version:       go1.10.6
  Git commit:       6247962
  Built:            Sun Feb 10 04:28:48 2019
  OS/Arch:          windows/amd64
  Experimental:     false
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 28
Server Version: 18.09.2
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: ics l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
Operating System: Windows 10 Pro Version 1809 (OS Build 17763.316)
OSType: windows
Architecture: x86_64
CPUs: 4
Total Memory: 7.955GiB
Name: REDACTED
ID: OTZO:EQUA:G54M:CFBN:O5V6:DYPK:3POL:HTUQ:C2RH:55AS:MVMC:JJY2
Docker Root Dir: C:\ProgramData\Docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: -1
 Goroutines: 26
 System Time: 2019-03-06T11:42:56.2623186-05:00
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
loganhz commented 5 years ago

I can reproduce failed to shutdown container, and subsequent terminate also failed [error=container xxx encountered an error during WaitTimeout: hcsshim: timeout waiting for notification module=libcontainerd container=xxx namespace=moby] in Windows Server 2019 with UBR 437 and 503 every time.

UBR 316 and 379 works well. We didn't see this issue with the same setup.

More detail info can be found via https://github.com/rancher/rancher/issues/20440

Update:

UBR 529 fixed it! It works for us.

May 21, 2019—KB4497934 (OS Build OS 17763.529) https://support.microsoft.com/en-us/help/4497934

evanpitt commented 5 years ago

I am having the same issue, I have tried every suggestion in the forum and I am still unable to build the docker containers.

Has there been a definitive resolution for this?

seanschneeweiss commented 5 years ago

I'm having this issue only on the newest Patch mcr.microsoft.com/windows/servercore:1607-KB4512517 Docker image. The image before that, mcr.microsoft.com/windows/servercore:1607-KB4507460 is working.

docker run -it mcr.microsoft.com/windows/servercore:1607-KB4512517 cmd
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: hcsshim::CreateComputeSystem 1f978a1262f1c08848abb15602dfa829e739b5b365e23b39274b1866a164ff64: hcsshim: timeout waiting for notification
(extra info: {"SystemType":"Container","Name":"1f978a1262f1c08848abb15602dfa829e739b5b365e23b39274b1866a164ff64","Owner":"docker","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\ProgramData\\Docker\\windowsfilter\\1f978a1262f1c08848abb15602dfa829e739b5b365e23b39274b1866a164ff64","Layers":[{"ID":"a9ab901e-0019-5e3d-a674-4047745fe107","Path":"C:\\ProgramData\\Docker\\windowsfilter\\3128f32ed0a0b7ced2503b3c32b8ff5bde17571a6787415d8e0475c234cb3968"},{"ID":"085dbfb9-4864-5b7d-9c85-30a0cb291186","Path":"C:\\ProgramData\\Docker\\windowsfilter\\bd6c5e246547defee9be0f35dba4f6cb79e198acc1ede93230ac380cf7212865"}],"HostName":"1f978a1262f1","HvPartition":true,"EndpointList":["E0BE75BE-65D6-4088-8761-E8440F384A46"],"HvRuntime":{"ImagePath":"C:\\ProgramData\\Docker\\windowsfilter\\3128f32ed0a0b7ced2503b3c32b8ff5bde17571a6787415d8e0475c234cb3968\\UtilityVM"},"AllowUnqualifiedDNSQuery":true}).

docker info

Client:
 Debug Mode: false

Server:
 Containers: 5
  Running: 0
  Paused: 0
  Stopped: 5
 Images: 59
 Server Version: 19.03.1
 Storage Driver: windowsfilter
  Windows:
 Logging Driver: json-file
 Plugins:
  Volume: local
  Network: ics l2bridge l2tunnel nat null overlay transparent
  Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
 Swarm: inactive
 Default Isolation: hyperv
 Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
 Operating System: Windows 10 Pro Version 1809 (OS Build 17763.678)
 OSType: windows
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.88GiB
 Name: computername
 ID: anonym:OPWF
 Docker Root Dir: C:\ProgramData\Docker
 Debug Mode: true
  File Descriptors: -1
  Goroutines: 28
  System Time: 2019-08-29T13:10:14.0679381+02:00
  EventsListeners: 1
 HTTP Proxy: http://someproxy.com:80
 HTTPS Proxy: http://someproxy.com:80
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

docker version

Client: Docker Engine - Community
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        74b1e89
 Built:             Thu Jul 25 21:17:08 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.1
  API version:      1.40 (minimum version 1.24)
  Go version:       go1.12.5
  Git commit:       74b1e89
  Built:            Thu Jul 25 21:25:07 2019
  OS/Arch:          windows/amd64
  Experimental:     false
prograholic commented 5 years ago

Hi, we have same issue. I tried to analyze the hang, unfortunately, most of the analysis is guesswork. Perhaps something can be found useful from it.

docker version

Client:
 Version:           18.09.3
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        142dfcedca
 Built:             02/28/2019 06:33:17
 OS/Arch:           windows/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.09.3
  API version:      1.39 (minimum version 1.24)
  Go version:       go1.10.8
  Git commit:       142dfcedca
  Built:            02/28/2019 06:31:15
  OS/Arch:          windows/amd64
  Experimental:     false

Also i`ve collected extra info using slightly modified script from https://docs.microsoft.com/en-us/virtualization/windowscontainers/troubleshooting

Checking for common problems
Container Host OS Product Name: Windows Server 2019 Standard
Container Host OS Build Label: 17763.1.amd64fre.rs5_release.180914-1434
Showing output from: docker info
Containers: 24
 Running: 1
 Paused: 0
 Stopped: 23
Images: 4
Server Version: 18.09.3
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: ics l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: process
Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
Operating System: Windows Server 2019 Standard Version 1809 (OS Build 17763.720)
OSType: windows
Architecture: x86_64
CPUs: 30
Total Memory: 48GiB
Name: *************
ID: NKUD:RO2K:6G34:ZMJB:HJAQ:PQWX:LINX:GB6H:A4EY:37FU:DLZG:KOU7
Docker Root Dir: C:\ProgramData\Docker
Debug Mode (client): false
Debug Mode (server): false
HTTP Proxy: *********************
No Proxy: 127.0.0.1
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Showing output from: docker version
Client:
 Version:           18.09.3
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        142dfcedca
 Built:             02/28/2019 06:33:17
 OS/Arch:           windows/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.09.3
  API version:      1.39 (minimum version 1.24)
  Go version:       go1.10.8
  Git commit:       142dfcedca
  Built:            02/28/2019 06:31:15
  OS/Arch:          windows/amd64
  Experimental:     false

Showing output from: docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
d9cd97f2f5bc        nat                 nat                 local
2937c9348a8a        none                null                local

Getting Warnings & errors in the Windows event logs from the last 24 hours

   ProviderName: docker

TimeCreated                     Id LevelDisplayName Message
-----------                     -- ---------------- -------
...
03.09.2019 14:44:53              1 Warning          driver error disconnecting container D97D86A5_container : The virtual machine or container was forcefully exited.
03.09.2019 14:44:53             11 Warning          failed to shutdown container [namespace=moby container=ec4dd407ba164e780fce8ea830d7f0bdd104b3bb92d61d618c39f3f7c5c2b78b process=init module=libcontainerd error=container ec4dd407ba164e780fce8ea830d7f0bdd104b3bb92d61...
03.09.2019 14:44:53             11 Error            failed to shutdown container, and subsequent terminate also failed [module=libcontainerd namespace=moby error=container ec4dd407ba164e780fce8ea830d7f0bdd104b3bb92d61d618c39f3f7c5c2b78b encountered an error during Wa...
03.09.2019 14:39:10              1 Warning          CreateCompleteSystem 4b18b01dfb3dd2fbfde34fdcaa59bd3234ac576d94eae965dac5f741cc377c5d: {"SystemType":"Container","Name":"4b18b01dfb3dd2fbfde34fdcaa59bd3234ac576d94eae965dac5f741cc377c5d","Owner":"docker","VolumePath...

I`ve noticed first warning:

03.09.2019 14:39:10 1 Warning CreateCompleteSystem 4b18b01dfb3dd2fbfde34fdcaa59bd3234ac576d94eae965dac5f741cc377c5d ... Did not complete within 4m0s. This may indicate a platform issue. If it appears to be making no forward progress, obtain the stacks and see is there is a syscall stuck in the platform API for a significant length of time.

After that i`ve got full memory dump of dockerd service and i saw following stack:

00 : ntdll!NtAlpcSendWaitReceivePort+0x14
01 : rpcrt4!LRPC_BASE_CCALL::SendReceive+0x12f
02 : rpcrt4!NdrpClientCall3+0x786
03 : rpcrt4!NdrClientCall3+0xf1
04 : vmcompute!ComputeService::Client::InvokeRpcFunction...
05 : vmcompute!ComputeService::Client::InvokeRpcFunctionWithRetry...
06 : vmcompute!HcsRpcServer::CreateSystem+0xa8
07 : vmcompute!HcsClient::ClientComputeSystem::Create+0x107
08 : vmcompute!HcsClient::CreateComputeSystem+0x137
09 : vmcompute!HcsCreateComputeSystem+0x100
0a : dockerd!cgo_topofstack+0xfbe
0b : 0x000000c0`44bcda70
0c : 0x000000c0`44449800

This thread waits for some ALPC request. I`ve noticed name of function vmcompute!HcsCreateComputeSystem and i supposed that there may be RPC to vmcompute process.

Here is most interesting part of stack of vmcompute process:

00  ntdll!NtAlpcSendWaitReceivePort+0x14
...
11  vmcompute!ComputeService::Net::HnsAttachEndpoint+0x246
12  vmcompute!ComputeService::Management::Details::AttachNetworkEndpoints+0xed
13  vmcompute!ComputeService::Management::WindowsContainerOrchestrator::Construct+0x366
14  vmcompute!ComputeService::Management::ComputeSystemManager::CreateComputeSystem+0x5d5
15  vmcompute!HcsRpc_CreateSystem+0x34a
...

I saw that there was a call to another process, i think that this was HNS (Host Network Service) - see name of function: vmcompute!ComputeService::Net::HnsAttachEndpoint

I found interesting stack in HNS process:

00 ntdll!NtDeviceIoControlFile+0x14
01 KERNELBASE!DeviceIoControl+0x67
02 kernel32!DeviceIoControlImplementation+0x80
03 vmsif!LibIoctlPrivSendIoctl+0x142
04 vmsif!LibIoctlDeviceIoControl+0x1e6
05 vmsif!VmsIfNicDisconnect+0xc3
06 NetMgmtIF!NetMgmtDisconnectSwitchPort+0x73d
07 hostnetsvc!SwitchHelper::DisconnectNicPort+0xe1
08 hostnetsvc!SwitchHelper::DisconnectNicPort+0x5f
09 hostnetsvc!HNS::Service::Resource::HostPortResource::HardDisconnect+0xff
0a hostnetsvc!HNS::Service::Network::Endpoint::Disconnect+0x16a
0b hostnetsvc!HNS::Service::Network::Endpoint::Attach+0x31e
0c hostnetsvc!HNS::Service::Network::BaseNetwork::AttachEndpoint+0xd0
0d hostnetsvc!HNS::Service::Core::NetworkEntityManager::AttachEndpoint+0xff
0e hostnetsvc!HNS::Service::Request::EndpointRequest::AttachDetach+0x12d
0f hostnetsvc!HNS::Service::Request::EndpointRequest::Post+0x1dc
10 hostnetsvc!HNS::Service::Request::RequestManager::Process+0x15e
11 hostnetsvc!HNS::Service::Request::RequestManager::HandleRequest+0x116
12 hostnetsvc!HNS::Service::Server::ComHNSApi::Request+0x261

As you can see HNS tries to create new network device (according to function name). During this construction HNS sends IOCTL to some device (ntdll!NtDeviceIoControlFile). Unfortunately i do not have full memory kernel dump so my analysis is incomplete.

May be my analysis will help someone for further investigation of this issue (CC: @jhowardmsft )

MatthewSteeples commented 4 years ago

Started receiving this error trying to run Windows images only (Linux ones run fine) after upgrading to 20H2 (19042.450). Have tried restarting and the problem still persists. Happy to provide traces if they're still useful, as I'm only experimenting with Docker currently so a) have nothing important/sensitive in there and b) don't mind if it stays broken for a few days

scottresnik commented 3 years ago

I am having this issue as well. @MatthewSteeples comment about 20H2 let me to try rolling back to 1909. However, that did not solve the problem. What I discovered through some trial an error was that the issue only manifests itself when running Windows 10 as a virtual machine and attempting to use Windows containers. Linux containers work fine, but I can only run Windows containers on a physical Windows 10 machine.

thejohnfreeman commented 3 years ago

Many reproductions in this thread. I'm the latest (see my mention linked above at https://github.com/microsoft/Windows-Containers/issues/153). The last comment from anyone associated with Microsoft was from @lowenna, who no longer works there (and maybe not anywhere, judging by "mostly retired"). This thread was created in 2017, and the last Microsoft comment was March 5, 2019, over two years ago. Most of the threads I run into regarding Windows containers have no Microsoft participation. I can't get anyone's attention on Twitter or Stack Overflow. Are Windows containers not a priority for Microsoft? Am I wasting my time trying to figure this stuff out? What does it take to start a conversation with a Microsoft engineer?

thejohnfreeman commented 3 years ago

I have figured out a solution to my particular problem, which was trying to run a Windows container from a Windows virtual machine. @scottresnik, it might help you too. Good luck to everyone else.

lowenna commented 3 years ago

who no longer works there (and maybe not anywhere, judging by "mostly retired")

You're right, I don't :smile:

wenyingd commented 3 years ago

I hit the same issue on my setup when I run Windows containers, and I run the Windows VM on ESXi Server. My Windows VM is configured with version as the following:

WindowsBuildLabEx                                       : 17763.1.amd64fre.rs5_
                                                          release.180914-1434
WindowsCurrentVersion                                   : 6.3
WindowsEditionId                                        : ServerStandard
WindowsInstallationType                                 : Server
WindowsInstallDateFromRegistry                          : 1/2/2020 11:04:05 AM
WindowsProductId                                        : 00429-70000-00000-AA1
                                                          52
WindowsProductName                                      : Windows Server 2019
                                                          Standard
WindowsRegisteredOrganization                           :
WindowsRegisteredOwner                                  : Windows User
WindowsSystemRoot                                       : C:\Windows
WindowsVersion                                          : 1809

The Windows hns service is stuck when attaching the HNSEndpoint to the containers, and I dump the stack of hns service as image

khughes147 commented 2 years ago

@thejohnfreeman @scottresnik did either of you find a solution to running the windows containers from a Windows VM on a windows host? @scottresnik the solution you posted throws an incompatible OS error regardless of what version I pull