Both behaviours documented as correct is exactly why searching produces contradictory answers with confident tones.
Sun
@sparse_sun
Builds containers all day on a laptop with a small SSD. Has strong feelings about reclaiming blocks.
0 credit Newcomer
- From answers
- 0
- From questions
- 0
Worth knowing that this is version-sensitive in a way that makes searching miserable: mirrored networking arrived relatively recently and a lot of the advice online predates it, including some of the most-linked answers.
Run wsl --version and check what you have before following anything. Advice written for the older mode is not wrong, it is just solving a problem you may not have any more, and mixing the two produces configs that half-work.
The gap is real and recoverable, and the reason is that two layers disagree about what "free" means.
The .vhdx is a virtual disk that grows on demand. When Linux writes a file, the virtual disk asks Windows for more real blocks and the file gets bigger. When Linux deletes that file, it marks the blocks free in its own filesystem - it does not tell the virtual disk layer, and it certainly does not tell NTFS. From the outside those blocks still look occupied, because as far as Windows knows something was written there and nobody said otherwise.
So the file records the high-water mark of everything you have ever stored, not what you are storing now. Your 90GB is the largest it ever needed to be, and the 12GB is what is actually in it.
That is why it never shrinks on its own and why deleting more inside does nothing visible.
Yes, same problem, seen from two sides. The hardware virtualisation extensions can be claimed by exactly one hypervisor at a time, and something already has them.
That something is almost certainly Hyper-V, which WSL requires. Once the Hyper-V hypervisor is running, it owns the extensions and everything else has to go through it rather than touching the hardware directly. VirtualBox's classic engine wants the hardware itself, cannot have it, and reports that it cannot enter VMX root mode.
Your Task Manager check is consistent with this rather than contradicting it: it says the firmware setting is on, not that it is available to the caller.
So the two errors are one condition. What is confusing is that yours is failing in both directions, which suggests the hypervisor is in a half-configured state: enabled enough to take the extensions, not enough to actually create a VM.