Add option to limit the size of a vhdx when creating a WSL distro

[oobayly]

Is your feature request related to a problem? Please describe.
It is currently impossible to limit the size of a vhdx when installing a WSL instance. Now that it default to a maximum size of 1TB, it is incredibly easy for an image to eat up all the HD space on the host. Luckily in my case the vdisk had already been moved away from the C:\

I'm actually incredulous that anyone thinks that 1TB is a reasonable default maximum size for a WSL image.

Describe the solution you'd like
A flag that sets the maximum possible size of the virtual disk. Even better, allow us to set a default maximum size for all WSL instances.

Describe alternatives you've considered
An insanely manual process.

• Stop the distro and make sure the vdisk isn't in use. (I actually had to reboot - welcome back to the 1990s)
• Create a new distro, and mount the vdisk using --bare
• Use resize2fs to shrink the drive
• Unmount the vdisk and unregister the new distro (I don't need another one eating another TB)
• Restart the original disto

The vhdx still has a maximum size of 1TB but at least the instance can't use that much.

Additional context
For some reason the Ubuntu image spammed the kern.log and syslogs so they ended up being 450GB each. Even after I deleted the logs, I couldn't compact (using either resize-vdisk or diskpart) the vhdx as it was stored in an encrypted folder.
My only option was to delete it and start from scratch which wasted a couple of hours of my time.

[benhillis]

Good suggestion - I will add this.

[zcobol]

@oobayly logrotate not working for you!?!

It's installed by default in Ubuntu, and will keep your log files tidy. Run sudo /var/lib/logrotate/status to see when your logs were pruned last time.

[oobayly]

@benhillis Thank you, it's much appreciated.

@zcobol I'll never know what the cause of it was because my priority was to get my system into a usable state again so I could get some work done...

Clearly the Ubuntu image shouldn't have let the log files explode to that size in less than a week. I've never had that happen in >25 years of running Linux/BSD servers & desktop Linux. I've also never had that happen on WSL on my home PC. I'd love to know what happened but it simply wasn't my priority at the time.

The point of this issue report is that a bug in an image shouldn't be able to take down the host OS by using all the drive space.

The image was originally created on a 1TB SSD with about 750 GB available, so WSL effectively said "Go ahead, use up to 133% of the available space"

[gluesmith2021]

Should that be of any help for future similar problems (except for the main issue here of limiting size at creation), you can move ext4.vhdx anywhere you see fit, if its current location (encrypted folder in this case) is a problem.

I mean, just move the file, no export/import, when the distro is not running. If you want to leave it there, set the distro to use it from its new location by changing the registry key (until maybe they implement a 'wsl --move') somewhere under HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss. Diskpart will then happily compact the vhdx.

Btw, distros I created in the last few years had a 256GB partition by default, but those I created this year, either with WSL 1.2.5 Release or 2.0.3 pre-release, indeed have 1 TB for no obvious reason.

[oobayly]

@gluesmith2021 Thanks. All the examples I saw talked about exporting, which wasn't an option for me due to the lack of space. I hadn't considered simply moving the vhdx.

Useful for other people to know.

[benhillis]

https://github.com/microsoft/WSL/releases/tag/2.0.5

[pcurrivan]

@benhillis thank you for working on this! How do I use it, though? I installed the 2.09 pre-release and tried putting the following in .wslconfig and got wsl: Unknown key 'wsl.vhdSize' in C:\Users\pcurr\.wslconfig:2

[wsl]
vhdSize = 32212254720