@tbtmuse yep we are aware and frankly can't wait already! If the performance is going to be good, this is going to be no less than an epic change.

Initial builds of WSL 2 will be available through the Windows insider program by the end of June 2019.

We'll have to explore the best approach to supporting and using WSL 2.

WSL 2 is not a revolutionary approach but rather an attempt to flip the issue (file system access and performance) on its head. It's pretty much the same as having a Linux environment in a VM that you connect to via SSH.

• User Experience Changes Between WSL 1 and WSL 2

Specifically:

Cross OS file speed will be slower in initial preview builds
You will notice slower file speeds compared to WSL 1 when accessing Windows files from a Linux application, or accessing Linux files from a Windows application. This is a result of the architectural changes in WSL 2, and is something that the WSL team is actively investigating on how we can improve this experience.

• WSL 2 installation instructions (available via Windows Insider Program on the "Fast" ring)
• WSL 2 with Visual Studio Code

Noting here that I was able to get this working by doing the following:

1. Ensure you're on at least Windows 10 2004 or Get on latest Windows fast ring
2. Install WSL 2 and choose Ubuntu 18.04 LTS (otherwise, you're on your own installing and setting up docker). If you want to use existing SSH keys (like from Windows), copy them in now. Make sure to mkdir ~/.ssh; touch ~/.ssh/config either way or Docksal will create it as a directory, which breaks things.
3. In WSL2, install docksal bash <(curl -fsSL https://get.docksal.io). If you run into issues installing docker, run sudo usermod -aG docker "${USER}", sudo service docker start, and restart the WSL2 Ubuntu app. Then try installing docksal again.
4. Run fin config set --global DOCKSAL_VHOST_PROXY_IP="0.0.0.0" and fin config set --global DOCKSAL_DNS_DOMAIN=docksal.site
5. Change into the linux project directory and start up the desired project (if it was previous on /mnt - please re-clone the project to your linux home directory or performance will suffer)
6. Follow the instructions (example at the bottom of this comment) at [WSL 2] NIC Bridge mode 🖧 (Has TCP Workaround🔨) microsoft/WSL#4150 to set the port and firewall rules properly (I used task scheduler + wslbridge.ps1).
7. Since fin hosts is not updated for WSL2 yet, add your project URLs to C:\Windows\System32\drivers\etc\hosts 127.0.0.1 myproject.docksal. You'll need to fin system reset to pick up all the changes and firewall updates.
8. For IDE use, I recommend mounting WSL as a network drive via Windows command prompt: net use "Z: \\wsl$\Ubuntu 18.04 LTS" /persistent:Yes. For VSCode, you can just use VSCode Remote (run code . inside the project root dir).
9. Make sure you reboot the PC, because it's Windows
10. To get XDEBUG or other inbound connection services working, set DOCKSAL_HOST_IP in .docksal/docksal-local.env to the IP address provided to WSL. (printf 'DOCKSAL_HOST_IP="%s"' $(ip route list default | grep -oP '(?<=default via\s)\d+(\.\d+){3}') >> ./.docksal/docksal-local.env) then run fin project restart.
11. If necessary, I suggest moving back to the Windows Slow Ring via Windows Insider Program unless you like running long updates twice a week

For Google Chrome / Selenium Driver Usage:

1. sudo update && sudo apt upgrade
2. sudo apt purge pulseaudio libpulse0 && sudo apt autoremove
3. sudo apt-get -y install xorg xvfb gtk2-engines-pixbuf dbus-x11 xfonts-base xfonts-100dpi xfonts-75dpi xfonts-cyrillic xfonts-scalable imagemagick x11-apps
4. wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
5. sudo dpkg -i google-chrome-unstable_current_amd64.deb
6. sudo apt install ./google-chrome-stable_current_amd64.deb
7. xvfb -ac :99 -screen 0 1280x1024x16 &
8. export DISPLAY=localhost:99; export NO_AT_BRIDGE=1
9. exec dbus-run-session -- bash
10. sudo service dbus start
11. Test: google-chrome --headless --disable-gpu --screenshot https://www.chromestatus.com/

Example port and firewall rules script; run as administrator using Task Scheduler:

1. Run... taskschd.msc
2. Create Task - Start a program Action, Trigger on user login: powershell.exe -ExecutionPolicy Bypass C:\Scripts\wslbridge.ps1

$remoteip = wsl.exe /bin/bash -c "ip addr show eth0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'"
$found = $remoteip -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';

if( !$found ){
  echo "The Script Exited, the ip address of WSL 2 cannot be found";
  exit;
}

#[Ports]

#All the ports you want to forward separated by comma
$ports=@(80,8080,443,10000,3000,5000);


#[Static ip]
#You can change the addr to your ip config to listen to a specific address
$addr='0.0.0.0';
$ports_a = $ports -join ",";


#Remove Firewall Exception Rules
iex "Remove-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' ";

#adding Exception Rules for inbound and outbound Rules
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Outbound -LocalPort $ports_a -Action Allow -Protocol TCP";
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Inbound -RemoteAddress $remoteip -Action Allow -Protocol TCP";

for( $i = 0; $i -lt $ports.length; $i++ ){
  $port = $ports[$i];
  iex "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr";
  iex "netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectport=$port connectaddress=$remoteip";
}

See below comment #1055 (comment) for benchmarks.

@cybtachyon thanks for the report. The last step is probably not necessary since there is fin hosts command for that.

Updated the steps - thanks!

Is it that difficult to support?

Difficult - likely not. Will it take time - certainly. Can you help by getting involved in a feature you are interested to see implemented - I'm glad you asked!

Here's how:

1. Validate the installation steps posted above are still valid.
2. Run some speed tests (e.g. time drush site-install) to compare filesystem performance between Docksal running with WSL1 and WSL2.
3. PRs are always welcome
4. Patience is also appreciated (when is the release date for WSL2?)

when is the release date for WSL2?
May 12 or May 13 in a phased manner for Windows 10 2004.

https://devblogs.microsoft.com/commandline/wsl2-will-be-generally-available-in-windows-10-version-2004/

https://thewincentral.com/microsoft-readying-to-launch-windows-10-2004-releases-iso-rtm-build-19041-to-wsus/

Just tested Docksal on WSL2 on the latest SLOW ring of insider preview build (19041.207). Works well and it works even with native linux Docker. Other words: Docker for Windows potentially is not needed anymore!

WSL2 Installation

1. Setup WSL2 and enable WSL2 to all distros by default.

   In Powershell as Admin run:

   dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
   dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

2. Make WSL2 as default WSL version

   wsl --set-default-version 2

   Note: it will not modify and impact any already existing/downloaded linux distros. If you already have linux distro downloaded, you need to switch it to WSL2 manually using following command in powershell:

   wsl --set-version Ubuntu-18.04 2 # For setting WSL v2

   or

   wsl --set-version Ubuntu-18.04 1 # For returning WSL v1

3. Install Ubuntu-18.04 from Windows Store. You can ignore login with MS account, just close login popup window and download will start.

   Note: there is no Docker repo for Ubuntu 20.04 (focal) so far, so just use 18.04.

4. Run Ubuntu app and finish install process.

5. In Powershell run wsl --list --verbose for making sure you have WSL2 ubuntu (see for VERSION column):

   > wsl --list --verbose
   NAME            STATE           VERSION
   * Ubuntu-18.04    Running         2
   

6. Open Ubuntu app and install Docksal in a usual linux way. It will trigger docker-ce install script and Docker + Docksal will be installed:

   bash <(curl -fsSL https://get.docksal.io) && newgrp docker

7. Follow @cybtachyon's network configuration steps: Support WSL 2 on Windows #1055 (comment)

Drupal speed

Testing

I've just created a drupal project in the WSL user's home directory and ran drush si 5 times.

#!/usr/bin/env bash

# Stop on error
set -e

i=1
max=5
while [ $i -le $max ]
do
   echo "[$i/$max] Running site install..."
   time (fin exec drush si standard --db-url=mysql://root:root@db/default --yes --quiet)
   i=$(( $i + 1 ))
done

For testing WSL2 I've created a project directory in WSL's user home directory: ~/testproject and not used windows partitions at all for storing the project. Personally I'd recommend to use WSL's home directory and mount it to some disk as suggested above. But WSL1 forced to use /mnt/c/testproject because Docker for Windows does not work well with \\wsl$\* shares.

Results

WSL1:

• Dir: /mnt/c/projectname
• Used Docksal + Docker for Windows setup setup

WSL2:

• Dir: ~/projectname
• Used docker-ce inside WSL2 as it's fully compatible with kernel now, no Docker for Windows was installed at all.

File system speed testing

I've just run dd inside (IN) and outside (OUT) cli container.

#!/usr/bin/env bash

# Stop on error
set -e

i=1
max=5
while [ $i -le $max ]
do
   echo "[$i/$max] Running test OUTside container ..."
   dd if=/dev/zero of=./test bs=512M count=20 oflag=direct && rm ./test
   i=$(( $i + 1 ))
done

echo "- - - - - - - - - - - - - - - - - - - - - - - -"

i=1
max=5
while [ $i -le $max ]
do
   echo "[$i/$max] Running test INside container ..."
   fin exec dd if=/dev/zero of=./test bs=512M count=20 oflag=direct && rm ./test
   i=$(( $i + 1 ))
done

That's insane! 🤪

Also I found that WSL2/WSL1 can be detected by kernel version: uname -r will return:

• WSL1: 4.4.0-19041-Microsoft
• WSL2: 4.19.67-microsoft-standard

So it's possible to just grep microsoft-standard$ for detecting wsl2. I hope it will help.

@alexander-danilenko this is great analysis. Looking forward to trying out WSL2 for myself.

WSL2 is available on many Windows 10 systems now with the 2004 update (slow rollout).

I have gone over my instructions in #1055 (comment) , and added support for XDEBUG and other Inbound connection tooling.

1. To get XDEBUG or other inbound connection services working, set DOCKSAL_HOST_IP in .docksal/docksal-local.env to the IP address provided to WSL. (printf 'DOCKSAL_HOST_IP="%s"' $(ip route list default | grep -oP '(?<=default via\s)\d+(\.\d+){3}') >> ./.docksal/docksal-local.env) then run fin project restart.

There's a couple things I don't understand which makes it difficult for me to contribute a PR, such as how DOCKSAL_HOST_IP is determined on Windows, or the best way to add firewall rules on Windows for Docksal/WSL2 (especially since the IP changes every time). I'd appreciate any insight, or at least enough that we could hack together a PR for this issue.

@cybtachyon , on line 5 of your powershell command, shouldn't $matches[0] instead be $found[0]? I don't see a prior variable named $matches in the wslbridge.ps1.

(Also, hello, Bloom from the Particle project here! It's awesome knowing you're rocking WSL2!!)

on line 5 of your powershell command, shouldn't $matches[0] instead be $found[0]?

Heya! Good catch, that's a leftover variable from the first iteration of the script. The matching is more robust now. I removed it as it's not needed anymore. Thanks!

Noting here that on a pre-release version of Windows (Build 20180.1000), local IP's 0.0.0.0 and 127.0.0.1 were disabled by default while localhost still worked fine.

I needed to run netsh http add iplisten 0.0.0.0 netsh http add iplisten 127.0.0.1.

I can verify the above works after a system restart. Because Windows.

Also throwing this out there: Make sure to restart your docksal-vhost-proxy and docsal-dns containers after applying @cybtachyon's powershell script:

Is this working out of the box at this point? I'd love to be able to switch to WSL2 since I've had some weird intermittent issues with SMB shares.

I noticed the install docs for Windows don't specify WSL1 or 2, and the Microsoft page about it recommends WSL2, so it is de facto the default for new users at this point...

@ethanbb We would need a PR that adds automation to the steps listed above. One issue is there is not an easy way to add the needed firewall exceptions via docksal. I would consider that a blocking bug in WSL2, unless we find a way to script it in bash.

See #1055 (comment) for the most up-to-date steps required.

Any official update on this being fully supported? I'm getting a new machine soon and would love to go with WSL2 for the speed boost.

Work on WSL2 support in Docksal is underway.

Also want to confirm that the solution above works and the speed gain is amazing. My main reason for looking into WSL2 is because I was testing out Wingsuit DS for Drupal. With WSL, Webpack (using watch) was taking about 2 minutes to recompile after a file changes. After switching to WSL2, it takes less than a second! Looking forward to this integration in future release of Docksal.

@lmakarov Is there a branch up or a doc tracking what's being done / needs to be done? I'd like to contribute. Here's what I'm aware of as tasks:

• (5) Decide if we want to require Docker Desktop + WSL2 or just WSL2
• (1) Fix docksal install to make sure to mkdir ~/.ssh; touch ~/.ssh/config
• (1) Check for WSL2 and warn if not at least stable (Win 10 v 2004 +)
• (1) Validate that sudo usermod -aG docker "${USER}"; sudo service docker start happen in docksal.
• (1) For WSL2, ensure that DOCKSAL_VHOST_PROXY_IP="0.0.0.0" by default
• (1) For WSL2, set DOCKSAL_HOST_IP to the IP address provided to WSL. (printf 'DOCKSAL_HOST_IP="%s"' $(ip route list default | grep -oP '(?<=default via\s)\d+(\.\d+){3}')
• (1) Ensure xdebug is properly set to use DOCKSAL_HOST_IP with xdebug.client_host
• (1) Add a warning for WSL2 if the project is on /mnt that performance will suffer and recommend moving to ${HOME}
• (8) Automate firewall bridging WSL2 in Windows, whether task scheduler + wslbridge.ps1 or another solution in [WSL 2] NIC Bridge mode 🖧 (Has TCP Workaround🔨) microsoft/WSL#4150
• (5) Update fin hosts for WSL2 yet so that the project URLs are automatically added to /mnt/c/Windows/System32/drivers/etc/hosts
• (1) Add a WSL2 suggestion to docksal after creating a project to mount WSL2 as a network drive via Windows command prompt: net use "Z: \\wsl$\Ubuntu 18.04 LTS" /persistent:Yes or install VSCode and run code . inside the project root dir.
• (1) Add a WSL2 suggestion to make sure you reboot the PC, because it's Windows
• (1) Update https://docksal.io/installation text "Windows - VirtualBox or Docker Desktop"
• (1) Update https://docksal.io/installation#windows text "Docker Desktop"
• (1) Update https://docksal.io/installation#windows-docker-desktop instructions
• (1) Write up the changelog

Hi,
For the record Docksal works as expected inside WSL2, but exemple.docksal.site (192.168.64.100) is not exposed to Windows.
127.0.0.1 or 192.168.160.1 are correctly pointing to docker but display "Project missing This domain does not map to an existing project stack.".

So it seems that the only think missing here is a dns entry (or a hosts modification)

ok, I finally get working Docksal with wsl2 :

fin config set --global DOCKSAL_DNS_DOMAIN=docksal.site
fin config set --global DOCKSAL_VHOST_PROXY_IP=127.0.0.1
fin system reset vhost-proxy

edit hosts file :
127.0.0.1 <my_project>.docksal.site

[EDIT]
This solution doesn't fix the connectivity container to another container :
fin sysinfo will return
Host to 192.168.64.100: PASS
Container to 192.168.64.100: FAIL
Container to 192.168.64.1: FAIL

@obriat you are a GOD. This worked perfectly. Wow.

OK but my solution doesn't benefit from the *.docksal.site wildcard DNS, another solution is to fix your HyperV interface IP.

Open Powsershell with admin rights and type:
netsh int ip set address name= "vEthernet (Default Switch)" static 192.168.64.100

Edit this command if your HyperV interface has another name (netsh int ip show addresses)

I also open a discusion about this point here: #1565

I use Docksal on WSL2, it works good, but Xdebug doesn't stop on the breakpoints. PHPStorm even doesn't react on requests. Is there any specific instructions to make Xdebug work in WSL2?

I use Docksal on WSL2, it works good, but Xdebug doesn't stop on the breakpoints. PHPStorm even doesn't react on requests. Is there any specific instructions to make Xdebug work in WSL2?

Yes, see above.

I have gone over my instructions in #1055 (comment) , and added support for XDEBUG and other Inbound connection tooling.

1. To get XDEBUG or other inbound connection services working, set DOCKSAL_HOST_IP in .docksal/docksal-local.env to the IP address provided to WSL. (printf 'DOCKSAL_HOST_IP="%s"' $(ip route list default | grep -oP '(?<=default via\s)\d+(\.\d+){3}') >> ./.docksal/docksal-local.env) then run fin project restart.

Yes, see above.

In my case this didn't help me. I solved my problem by assigning IP of host.docker.internal to client_host and remote_host

I use Docksal on WSL2, it works good, but Xdebug doesn't stop on the breakpoints. PHPStorm even doesn't react on requests. Is there any specific instructions to make Xdebug work in WSL2?

I've had no luck with PHPStorm, but @cybtachyon's instructions oddly seem to work fine when using VSCode. After doing some digging, it looks like the Windows IP Helper service is blocking port 9000, which is preventing PHPStorm from listening on that port. I'd be curious to know if anyone else has experienced this same issue.

I've had no luck with PHPStorm, but @cybtachyon's instructions oddly seem to work fine when using VSCode.

Unrelated to any issue with PHPStorm, but if you use VSCode with the Remote - WSL extension, i.e. Code is running on the Linux VM, you don't need to change DOCKSAL_HOST_IP. Maybe obvious but I was uncertain when XDebug wasn't working. (My actual issue was not setting XDEBUG_ENABLED="1" 🤦‍♂️)

I use Docksal on WSL2, it works good, but Xdebug doesn't stop on the breakpoints. PHPStorm even doesn't react on requests. Is there any specific instructions to make Xdebug work in WSL2?

I'm using PHPStorm and Xdebug works fine with it. In addition to following instructions from cybtachyon #1055 (comment) I did this:

1. Open settings in PHPStorm and under PHP click on "servers"
2. Insert new server if you don't have any by clicking the + icon.
3. Give it whatever name you want and for the host, write down the domain of the site... i.e. d9.local (I have that in windows hots file as well 127.0.0.1 d9.local)
4. Check "Use path mappings..." checkbox and enter "/var/www" as the absolute path on the server for project files. Click appy>ok.
5. By default the debug port should be 9000. For some reason I have 9000,9003 in PHPStorm debug port.

Also have this in my docksal.env under [project_root]/.docksal directory
DOCKSAL_STACK=default
DOCROOT=web
VIRTUAL_HOST=d9.local
XDEBUG_ENABLED=1
MYSQL_PORT_MAPPING="33063:3306"

I'm using PHPStorm and Xdebug works fine with it. In addition to following instructions from cybtachyon #1055 (comment) I did this:

I don't see any difference in what you're describing and what I've configured for my project. I still can't get PHPStorm to debug anything. On further inspection, I notice that the Windows IP Helper service seems to be using port 9000 for some reason. When triggering PHPStorm to listen for XDebug on port 9000, I get a notification from PHPStorm saying "Port 9000 is busy".

However, when I go to Settings and validate debugger configuration (under PHP > Debug), I get a successful result.

So my next thought was, ok, port 9000 is busy so let me just configure XDebug to use port 9001 instead. Should be easy enough, and it was. I created docksal-local.yml and added this:

version: '2.1'
services:
  cli:
    expose:
      - 9001
    environment:
      - XDEBUG_CONFIG=client_host=${DOCKSAL_HOST_IP} client_port=9001 remote_host=${DOCKSAL_HOST_IP} remote_port=9001

I run fin restart, go back to Settings in PHPStorm, change the port to 9001 and validate XDebug configuration again. Again validation succeeds, this time confirming remote port 9001. I'm able to toggle on listening for PHP XDebug connections. No notifications. If I check Windows, I can see that PHPStorm is using port 9001. All looks good.

Except PHPStorm still doesn't pick up the connection when using my browser.

I'm beginning to think JetBrains might just be releasing updates that are breaking WSL2 features.

I discovered my issue. It was actually very simple, but I'll mention it here in case someone else runs across this.

I was grabbing the Powershell script posted above and running it to open ports between Windows and WSL2. At some point I had port 9000 in my list of ports to open. I had removed that port from the script later. But of course (and as a I developer I should have recognized this much sooner than I did), that does not remove the firewall rule that was established the last time I ran it. So from that point forward, port 9000 was open and being manged by the IP Helper service in Windows 10.

So just keep in mind that you'll need to specifically remove the firewall rules for the port you no longer want to proxy between Windows and WLS2. Or make a new script for removing ports.

I just discovered that all the WSL mentions in fin are related to WSL1. These could be removed, no ?
WSL2 works like any Linux distro, the only thing that need to be implemented is to expose WSL on 192.168.64.100

I'm staring a PR in order to remove WSL1 support.
I made the hypothesis that WSL2 should be considered as a "standard Linux" (which is the current behaviour, intended or not...)

The remaining tasks:

• Test this PR for errors or regressions
• Add a new feature that will fix WSL2's IP to 192.168.64.100