There is a new release for the Windows Subsystem for Linux (WSL) with new features and bug fixes! Check out the summary below, and read on to learn more about new experimental features, and some significant quality improvements.
Experimental features
We know that WSL is used for a wide array of workflows and we want to help you get the best performance and quality experience from these workflows. That’s why we are introducing new features listed below as experimental features, so you can try them and provide us feedback and we will make the features you love as default! Here’s the summary of what we’re adding:
- Added support for new opt-in experimental features
- autoMemoryReclaim – Makes the WSL VM shrink in memory as you use it by reclaiming cached memory
- Sparse VHD – Automatically shrinks the WSL virtual hard disk (VHD) as you use it
- Mirrored mode networking – A new networking mode for WSL that adds new features and improves network compatibility
- dnsTunneling – Changes how WSL resolves DNS requests to improve network compatibility
- firewall – Applies Windows firewall rules to WSL, and allows for advanced firewall controls for the WSL VM
- autoProxy – Makes WSL automatically use the proxy information from Windows to improve network compatibility
To use these, create a .wslconfig file in your Windows home directory (e.g: C:\Users\<yourusername>\.wslconfig) and ensure it has an [experimental] section with each setting below it, such as this:
“` [experimental] autoMemoryReclaim=gradual
The new feature settings are explained below, please see this docs page to learn more about advanced configurations for WSL.
Automatic memory reclaim
| Setting name | Value | Default | Notes |
|---|---|---|---|
autoMemoryReclaim |
string | disabled | Automatically releases cached memory after detecting idle CPU usage. Set to gradual for slow release, and dropcache for instant release of cached memory. |
When this is set to gradual, after being idle for 5 minutes, WSL will slowly start to release cached memory in Linux and make it available as free memory back to the Windows host. This means that your WSL VM will automatically shrink in memory size when you’re not using it!
This works by WSL detecting that you’re idle by seeing if CPU usage is continuously low for 5 minutes, and then we start reclaiming cached memory by using the cgroup memory.reclaim feature. We reclaim a fixed portion of your VM’s memory size, which is calculated so that if your VM was full of cached memory it would go to zero cached memory after 30 minutes (e.g: If you have 3000MB of memory, we reclaim 100MB every minute). The memory.reclaim cgroup feature allows us to intelligently reclaim a portion of memory over time, striking a balance between performance and memory usage. However, this feature does require disabling cgroups v1 in WSL, which can cause some issues. In early testing we noticed that this will break the docker daemon when running it as a service in WSL, and so if you’re using this feature we recommend you use Docker Desktop for your docker needs. We are working with the Docker team to address this in the future.
If you’d like to customize your idle detection thresholds and more, we’d recommend doing so by not enabling this feature and creating a bash script, see this GitHub gist for instructions.
You can also set this to dropcache which will instead drop caches entirely after detecting idle, and will not require any cgroup changes.
Automatic disk space clean up (Set sparse VHD)
| Setting name | Value | Default | Notes |
|---|---|---|---|
sparseVhd |
bool | false | When set to true, any newly created VHD will be set to sparse automatically. |
WSL virtual hard disks (VHDs) grow in size as you use them, and now with this feature enabled they will automatically shrink in size too! This new setting automatically sets any new VHD to be a sparse VHD, which can automatically reduce their size. Additionally, we’ve added the wsl --manage <distro> --set-sparse <true/false> command to allow you to set your existing distros to be sparse or not if you’d like.
New Networking Mode – Mirrored
| Setting name | Value | Default | Notes |
|---|---|---|---|
networkingMode |
string | NAT | If the value is mirrored then this turns on mirrored networking mode. Default or unrecognized strings result in NAT networking. |
Networking improvements are a consistent top ask for WSL, and this feature aims to improve the networking experience in WSL! This is a complete overhaul on the traditional NAT networking architecture of WSL, to an entirely new networking mode called “Mirrored”. The goal of this mode is to mirror the network interfaces that you have on Windows into Linux, to add new networking features and improve compatibility.
Here are the current benefits to enabling this mode:
- IPv6 support
- Connect to Windows servers from within Linux using the localhost address
127.0.0.1 - Connect to WSL directly from your local area network (LAN)
- Improved networking compatibility for VPNs
- Multicast support
There are some initial known issues, so as you explore this mode please file feedback on any bugs at the WSL GitHub repo!
Current known issues:
- Running VS Code Remote Dev containers can result in “Address already in use” errors when binding to a port.
Please note this feature is currently only available to Windows Insiders canary and Release Preview Channel with the latest Windows 11, version 22H2 update here. You can get access now by joining the Windows Insider Program and choosing to opt in your device into the Release Preview Channel.
DNS Tunneling
| Setting name | Value | Default | Notes |
|---|---|---|---|
dnsTunneling |
bool | false | Changes how DNS requests are proxied from WSL to Windows |
One contributing factor to when WSL can’t connect to the internet, is that the DNS call to the Windows host is being blocked. This is because the networking packet for DNS sent by the WSL VM to the Windows host was being blocked by the existing networking configuration. DNS tunneling fixes this by instead using a virtualization feature to communicate with Windows directly. This allows us to resolve the DNS name request without sending a networking packet, which will allow you to get better internet connectivity even if you have a VPN, specific firewall setup, or other networking configurations. This feature should improve network compatibility, making it less likely for you to have no network connection inside of WSL.
Please note this feature is currently only available to Windows Insiders canary and Release Preview Channel with the latest Windows 11, version 22H2 update here. You can get access now by joining the Windows Insider Program and choosing to opt in your device into the Release Preview Channel.
Hyper-V Firewall
| Setting name | Value | Default | Notes |
|---|---|---|---|
firewall |
bool | false | Setting this to true allows the Windows Firewall rules, as well as rules specific to Hyper-V traffic, to filter WSL network traffic. |
Hyper-V Firewall allows you to specify firewall settings and rules that will apply to WSL. Additionally, by default all of the existing firewall settings and rules that you have on Windows will be automatically applied to your WSL distros. After you’ve enabled this, you can test it by creating new firewall rules in Windows firewall settings and seeing that they instantly apply to WSL, or you can create a new rule that applies only to WSL directly by running this in PowerShell: New-NetFirewallHyperVRule
If you’d like to learn more about firewall rules and settings, please see the help message for that command by running: New-NetFirewallHyperVRule -?.
Please note this feature is currently only available to Windows Insiders canary and Release Preview Channel with the latest Windows 11, version 22H2 update here. You can get access now by joining the Windows Insider Program and choosing to opt in your device into the Release Preview Channel.
autoProxy
| Setting name | Value | Default | Notes |
|---|---|---|---|
autoProxy |
bool | false | Enforces WSL to use Windows’ HTTP proxy information |
This feature aims to increase your network compatibility when using an HTTP proxy. Currently, if you are using an HTTP proxy on Windows it will not directly apply to your WSL distros. Normally if you’d like to set up an HTTP proxy with WSL you’d need to set it up using the same way you would on a Linux machine, else you could experience connectivity issues. This feature aims to fix that, by automatically using the HTTP proxy information on Windows to set the HTTP proxy inside of Linux.
Please note this feature is only available on Windows 11 22H2.
Fixes and improvements
This release also has some significant bug fixes:
- GH 9231 Store WSL isn’t accessible from Session 0
- Please note to do this you will need to call
C:\Program Files\WSL\wsl.exedirectly, we are working on a change to fix the inboxwsl.exebehavior in a future Windows build
- Please note to do this you will need to call
- WSL GUI apps now have Windows snapping with the keyboard (Press WIN + an arrow key to snap to the side)
To see a full and complete list of all fixes, please see the official release notes.
Getting access, feedback and questions
To get access to this new version, just run this command in PowerShell: wsl --update; wsl --update --pre-release, or you can download it manually from the WSL GitHub repository.
Please file any issues at the WSL GitHub repository, or view the WSL docs to learn more. If you have further questions you can reach out to Craig or WSL team members on Twitter. We look forwards to hearing your feedback, thank you for supporting us and happy coding!
Please inform about when this will be generally available in Windows 2022 without Insider, canary and release preview channel.
We have to make plans for using WSL2 for some features in our product based on this update.
a great post
However, this feature does require disabling cgroups v1 in WSL, which can cause some issues. In early testing we noticed that this will break the docker daemon when running it as a service in WSL
Thank you very much for your great website
https://motorsavaran.com
nice work!
C:\Users\john>wsl
Access is denied.
🙁
Thanks for these exciting features!
I can confirm: the Mirrored mode works! This is a huge improvement over the Bridged mode + HyperV switch that I used before. Many thanks!
Just one issue remains then for me: USB support in WSL2, please... :-)
For USB support I used usbipd, but with the Mirrored mode, it now doesn't work:
<code>
UPDATE: I found a workaround. In WSL2 (Ubuntu), type:
<code>
Just adding that I have the same issue, so hopefully this gets escalated. After enabling network mirrored mode, usbipd yields the same error that you have shown above.
The command indeed does not work anymore, but it is merely a convenience - what it really does is to execute some command inside the wsl VM. So, to enable usbip, open your Ubuntu and type . It definitely works for me. In Ubuntu you can also list the shared USB devices:
<code>
I submitted a feature request to the creators of usbipd: https://github.com/dorssel/usbipd-win/issues/714
Also, if you have firewall issues, see https://github.com/microsoft/WSL/issues/10535
BTW: Thanks to the above, plus...
I see that You have polish name i surname, so sorry but can I write polish? I have question about problem with “mirrored”.
You can, if you have no other choice! :-)… but most non-Poles would be disappointed…
I would want create vpn connection between WSL2 and another computer in LAN. Do You help me? I installed OpenVPN server on Ubuntu in WSL2 but it is in network 10.8.0.0 and other computers 192.168.x.x. Do I must create port forward or routing or ??? OpenVPN server on WSL2 work right. I can connect from Windows host as client.
<code>
and shut wsl down and restart. You should see all your physical network cards (NICs) in Ubuntu () with the same IP addresses as you assigned in Windows.
2. In your firewall, enable incoming traffic from the other computers on your LAN (see https://github.com/microsoft/WSL/issues/10535)
3. Make sure the remote computers are on the same LAN! (if your NIC is on 10.x.x.x/8 then the remote computers should be on the same subnet, not 192.168.x.x/16).
Question 1: I’m using both wsl1 and wsl2. I wonder if it’s still better to use wsl1 when I’m using rsync with the windows file system?
Question 2: Is there any problems using wsl1 and wsl2 at the same time, now when they have the same ip adress?
/Johan
Any timeline for releasing these features in the Windows 10 (especially) and Windows 11 main builds/update packages? I can’t tell users to update Win10 to an Insider’s Build.
I’m very exited about the network mirroring feature. Do we have confirmation that this will be coming to Windows 10 as well? It appears to only be available on Windows 11 at the moment.
Looks like this breaks the docker due to cgroups upgrade (to v2?)
Docker daemon has this error “failed to start daemon: Devices cgroup isn’t mounted”
since WSL doesnt have grub, I cant find a workaround to use cgroups v1
As said in the article: "The memory.reclaim cgroup feature allows us to intelligently reclaim a portion of memory over time, striking a balance between performance and memory usage. However, this feature does require disabling cgroups v1 in WSL, which can cause some issues. In early testing we noticed that this will break the docker daemon when running it as a service in WSL, and so if you’re using this feature we recommend you use Docker...
yeah cant seem to get around this either