Use of Container Utility VM folder Docker

Hello Everone,

I am a newbie in Docker. I am using Docker for my local development environment. Although I have mapped my Docker to the secondary drive (F) in my case, so that it doesn’t occupy space in C drive, I observed my C drive was still getting occupied.

When I digged little deeper, I realized that Container Utility Folder at C:\ProgramData\Microsoft\Windows\Hyper-V Windows was occupying almost 30GB of space.

Can anyone please help me out in understanding what exactly this folder plays the role in docker. Is is safe to delete the contents of the folder to regain some space in C drive.

Thanks,
Anvay.

Are you sure it is 30GB and not 30MB? On my machine it contains two VHDX files. The first is 36MB, the second is 30MB. And there is a third file which a VMRS. I couldn’t find much information about this folder but you should not remove it. A VHDX file is a virtual disk file for a virtual machine. The VMRS contains the current state of the running virtual machine if I am not mistaken. One of the VHDX files is actually available from the Disk Management on my machine.You can try to mount them from the disk management in read-only mode but I could not attach the VHDX wich also had a VMRS with the same ID.

The attachable VHDX is the one which is already in the Disk Management and that is virtually 10GB. I could assign a driver letter to it and see it contains Windows system folders like EFI. I could not find out what the other VHDX is. It doesnt matter if I use Linux containers or Windows containers. I even switched to the Hyper-V backend from WSL and the size of this folder remains the same but the files are in use so you probably could not even delete them.

Yes, I am sure. In fact it is almost 35GB. So it is consuming a lot of space as you can imagine. Now only 45 GB space is available on my C drive.

I am attaching screenshot of the folder properties for the reference
Container Utility VM Properties

Can you list the content of the folder?

Sure Here are they, it’s a long list, I shall keep the snapshot :

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.