Use of Container Utility VM folder Docker

Docker Desktop
,
6

Okay, I have done some research.

It looks these images contain the kernels for containers when the “isolation” setting is “hyperv”. All of them are virtually 10GB but occupy much less space on the filesystem. According to my observation there is always at least one vmrs file. I am not sure what that belongs to but I can’t delete it becuse it is always used.

When I run my first Windows container with the hyperv isolation method, the first vhdx is created to store some required files for the Windows container which can have a different kernel than the host OS. It also creates an other vhdx which seem to be the the container’s filesystem or some kind of temporary filesystem since it exist only while the container is running, Windows containers have stricter kernel requirements. This is what the hyperv isolation method for.

When I restart Windows and run a new container, it creates an other vhdx file plus one file for the container. It looks like every time I restart Windows, Hyper-V forgets the previously created VHDX.

I could delete each VHDX file but not the VMRS files. I had to restart Windows again to be able to remove those files except of course the one that is always there. The only prolem was thet Docker could not create my container until the next restart when the new vhdx file could be created.

I don’t know how you changed the data directory for Docker but this directory is not managed by Docker directly. I guess it ismanaged by Hyper-V. If you read the issues I linked above, you can see that TBBle wrote:

I suspect it’s not possible to change its location through configuration, as it’s hard-coded to %PROGRAMDATA%\Microsoft\Windows\Hyper-V\Container Utility VM inside vmcompute.exe.

and the “process” isolation method might not work for you.

I would say that if you don’t have any data inside the containers, delete all of the containers, delete the VHDX files in the “Container Utility VM” folder, restart Windows, delete the “VMRS” files, restart Windows again and try to rerun your containers.

Do it only if you take the risk. It worked for me but our environments are obviously different.