Windows-Containers icon indicating copy to clipboard operation
Windows-Containers copied to clipboard

Can't just use "all available" hardware resources

Open Outtay opened this issue 1 year ago • 12 comments

Describe the bug According to the Docker documentation: https://docs.docker.com/config/containers/resource_constraints/ there should be by default no resource constraints. However, if I do not specify how much RAM and how many CPUs to use, it always just uses 1 core and 2 logical processors and 5GB of RAM. Even if I specifically say --cpus 0 when creating the container, which should use all available cores, it still restricts it to the default. Right now I have no idea how to tell the container to use all available resources without specifying all resources. If this is a bug in Docker for Windows and I need to report it there, please tell me.

To Reproduce Steps to reproduce the behavior:

  • Make a docker image from mcr.microsoft.com/windows/servercore:ltsc2022
  • docker build -t myimage -m 4GB .
  • docker run --name Windows -it myimage
  • In the container execute wmic cpu get NumberOfCores,NumberOfLogicalProcessors
  • If you have more than one core, it will still only show one

Expected behavior The container should use all available resources

Configuration:

  • Edition: Windows 11
  • Base Image being used: Windows Server Core
  • Container engine: docker
  • Container Engine version: 24

Additional context Add any other context about the problem here.

Outtay avatar Oct 19 '23 08:10 Outtay

🔖 ADO #47827961

ntrappe-msft avatar Nov 23 '23 00:11 ntrappe-msft

Hi @Outtay,

There are two kind of Windows Containers:

  1. Process Isolated Containers
  2. Hyper-V Isolated Containers.

For Hyper-V isolated containers, we can have WCOW and LCOW. WCOW means Windows Container on Windows, LCOW means Linux Container on Windows, docker client installation called WSL.

  1. For process isolated containers, we can't assign the CPU and memory to a container like we can do for a Hyper-V isolated container, but we can limit how much CPU and memory a container can consume. For example,

docker run -it -m 4096M ---cpu-percent=20 --name mytest windows cmd.exe

This command will create a container that can only consume up to 4GB physical memories and 20 percent of the total available CPU. As the CPU core concerns, it still can see all the cores inside the container, but it can only consume up to 20% of the CPU resources.

image
  1. For Hyper-V isolated containers, it will assigned the CPU and memory resources at the container startup time, just like a Hyper-V VM scenario. For example:

docker run -it -m 4096M --cpu-count=8 --name mytest --isolation=hyperv windows cmd.exe

With this command, the docker will create a container with 4GB and 8 cores assigned to the container, event the container host has 12 cores. BTW, the default Hyper-V container CPU core is 2 and memory is 1GB.

Please let me know if you have any questions.

Howard-Haiyang-Hao avatar Jan 04 '24 00:01 Howard-Haiyang-Hao

Hi @Howard-Haiyang-Hao,

thanks for the response.

Under Linux and according to the general Docker documentation there shouldn't be any resource constraints by default. I also couldn't find any documentation stating that Windows works differently in that regard, as in the case of using Hyper-V Isolated Containers and specifying no resources, not all resources can be used by the container. However, I was under the impression that I had the same problem when using Process Isolated containers. That seemed to have been an error on my part. When I tested it right now all resources were available when specifying none.

My specific use case is setting up different physical hardware for running pipelines and building and testing an application in a docker container. Since they should not be doing anything else I want them to use all available resources. However, they're all different machines and therefore have different parameters, which means that specifying the correct parameters is a minor source of error. An unnecessary one, as I should not need to specify it.

Since using process isolation works as I would expect it, I can try using that and hoping that it works. However, with Hyper-V isolation mode this should in my opinion be changed to work consistent with other modes or would need to be documented as an exception (if it isn't already. I couldn't find that though). As a workaround it would have also been nice, if there was an option that just results in everything being used (like entering 0 or INT_MAX for cpu-count or 100 for cpu-percent would then result in the maximum amount of cores being assigned and used)

Outtay avatar Jan 04 '24 15:01 Outtay

This issue has been open for 30 days with no updates. @Howard-Haiyang-Hao, please provide an update or close this issue.

This issue has been open for 30 days with no updates. @Howard-Haiyang-Hao, please provide an update or close this issue.

I've created a PR (https://github.com/moby/moby/pull/43269) to allow CPUs to be configured for docker build two years ago to solve this issue, but it is being ignored.

slonopotamus avatar Mar 05 '24 21:03 slonopotamus

This issue has been open for 30 days with no updates. @Howard-Haiyang-Hao, please provide an update or close this issue.

This issue has been open for 30 days with no updates. @Howard-Haiyang-Hao, please provide an update or close this issue.

This issue has been open for 30 days with no updates. @Howard-Haiyang-Hao, please provide an update or close this issue.

docker run -it -m 4096M --cpu-count=8 --name mytest --isolation=hyperv windows cmd.exe

This works for docher run, but its very annoying that its not supported for docker build

Cube707 avatar Jun 07 '24 05:06 Cube707

This issue has been open for 30 days with no updates. @Howard-Haiyang-Hao, please provide an update or close this issue.

This issue has been open for 30 days with no updates. @Howard-Haiyang-Hao, please provide an update or close this issue.

This issue has been open for 30 days with no updates. @Howard-Haiyang-Hao, please provide an update or close this issue.

This issue is going stale. Closing for now. Please re-open if you have additional questions.

ntrappe-msft avatar Sep 09 '24 17:09 ntrappe-msft

This issue is going stale. Closing for now. Please re-open if you have additional questions.

@ntrappe-msft How does it make sense to close it, if this is not resolved or a solution provided. It should be kept open until resolved?!

Cube707 avatar Sep 09 '24 19:09 Cube707

@Howard-Haiyang-Hao should we keep this open? Do we have any updates to share?

ntrappe avatar Sep 09 '24 19:09 ntrappe