Announcing WSL 2
Today we’re unveiling the newest architecture for the Windows Subsystem for Linux: WSL 2! Changes in this new architecture will allow for: dramatic file system performance increases, and full system call compatibility, meaning you can run more Linux apps in WSL 2 such as Docker.
What exactly is WSL 2?
Our top requests from the WSL community have been to increase the file system performance, and make more apps work inside of WSL (i.e: introduce better system call compatibility). We have heard your feedback, and are glad to announce that WSL 2 helps solve these issues.
WSL 2 is a new version of the architecture that powers the Windows Subsystem for Linux to run ELF64 Linux binaries on Windows. This new architecture changes how these Linux binaries interact with Windows and your computer’s hardware, but still provides the same user experience as in WSL 1 (the current widely available version). Individual Linux distros can be run either as a WSL 1 distro, or as a WSL 2 distro, can be upgraded or downgraded at any time, and you can run WSL 1 and WSL 2 distros side by side. WSL 2 uses an entirely new architecture that uses a real Linux kernel.
Microsoft will be shipping a Linux kernel with Windows
Yes, you did just read that heading correctly! We will be shipping a real Linux kernel with Windows that will make full system call compatibility possible. This isn’t the first time Microsoft has shipped a Linux kernel, as we have already shipped one in 2018 when we announced Azure Sphere. However, this will be the first time a Linux kernel is shipped with Windows, which is a true testament to how much Microsoft loves Linux! We’ll be building the kernel in house from the latest stable branch, based on the source available at kernel.org. In initial builds we will ship version 4.19 of the kernel.
This kernel has been specially tuned for WSL 2. It has been optimized for size and performance to give an amazing Linux experience on Windows. We will service this Linux kernel through Windows updates, which means you will get the latest security fixes and kernel improvements without needing to manage it yourself.
Lastly, of course this Linux kernel will be fully open source! When we release WSL 2 we will have the full configuration available online on Github, so you can see how it works and build it yourself. If you’d like to read more about this kernel you can check out this blog post written by the team that built it.
A quick explanation of the architectural changes in WSL 2
WSL 2 uses the latest and greatest in virtualization technology to run its Linux kernel inside of a lightweight utility virtual machine (VM). However, WSL 2 will NOT be a traditional VM experience. When you think of a VM, you probably think of something that is slow to boot up, exists in a very isolated environment, consumes lots of computer resources and requires your time to manage it. WSL 2 does not have these attributes. It will still give the remarkable benefits of WSL 1: High levels of integration between Windows and Linux, extremely fast boot times, small resource footprint, and best of all will require no VM configuration or management.
Here’s a quick demo of WSL 2 in action. When we start our distro we get access to a working bash shell in under two seconds, and can run services and apps like docker right away. To summarize: while WSL 2 does use a VM, it will be managed and run behind the scenes leaving you with the same user experience as WSL 1.
You can expect more detail on the exact changes to the architecture posted to this blog in the near future, so please stay tuned!
How much faster is WSL 2?
File intensive operations like
apt upgrade, and more will all be noticeably faster. The actual speed increase will depend on which app you’re running and how it is interacting with the file system. Initial tests that we’ve run have WSL 2 running up to 20x faster compared to WSL 1 when unpacking a zipped tarball, and around 2-5x faster when using git clone, npm install and cmake on various projects. We’re looking forwards to seeing speed comparisons from the community when we release!
Full System Call Compatibility
Linux binaries use system calls to perform many functions such as accessing files, requesting memory, creating processes, and more. In WSL 1 we created a translation layer that interprets many of these system calls and allows them to work on the Windows NT kernel. However, it’s challenging to implement all of these system calls, resulting in some apps being unable to run in WSL 1. Now that WSL 2 includes its own Linux kernel it has full system call compatibility. This introduces a whole new set of apps that you can run inside of WSL. Some exciting examples are the Linux version of Docker, as well as FUSE!
Using WSL 2 means you can also get the most recent improvements to the Linux kernel much faster than in WSL 1, as we can simply update the WSL 2 kernel rather than needing to reimplement the changes ourselves.
WSL 2 will be a much more powerful platform for you to run your Linux apps on, and will empower you to do more with a Linux environment on Windows.
Initial builds of WSL 2 will be available through the Windows insider program by the end of June 2019.
We will be announcing when the initial release is available right here on this blog, as well as on Twitter. You can follow the WSL team on Twitter below, where you can ask us questions and get more updates on everything WSL.
WSL Team members on Twitter:
- Taylor Brown @Taylorb_msft
- Yosef Durr @yosefdurr
- Sven Groot @svengroot_ms
- Ben Hillis @benhillis
- Craig Loewen @craigaloewen
- Sunil Muthuswamy @SunilMut
- Brian Perkins
- Palkesh Soni @sonipalkesh
- John Starks @gigastarks
- Craig Wilhite @CraigWilhite
- Kayla Cinnamon @cinnamon_msft
Thank you so much for your support. We can confidently say that WSL would not be what it is today without its amazing community, and as always, we look forwards to hearing your valued feedback about the new WSL!
-The WSL Team
So if I understand correctly this will be available until end of June right , because currently I get this output: cguizar@N-20L6PF1JBK83:~$ sudo /etc/init.d/docker start[sudo] password for cguizar:* Starting Docker: docker [ OK ]cguizar@N-20L6PF1JBK83:~$ sudo docker run -it alpine ashdocker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.See ‘docker run –help’.cguizar@N-20L6PF1JBK83:~$ sudo /etc/init.d/docker status* Docker is not runningcguizar@N-20L6PF1JBK83:~$ sudo iptables -Liptables v1.6.1: can’t initialize iptables table `filter’: Table does not exist (do you need to insmod?)Perhaps iptables or your kernel needs to be upgraded.
Indeed. It’s a new technology that hasn’t been released yet. At the moment your system only has WSL v1 which is an incomplete implementation of the Linux ABI on top of the NT kernel rather than ‘real’ Linux like WSL v2 will be. It isn’t fully compatible with Linux so there are still quite a few applications such as Docker that don’t work properly.I’m hoping it will be possible to try out this new version (and the Windows Terminal) on Windows 10 v. 1903 and it won’t be necessary to install the whole 19H2 preview.
I am running 1903. Can I install WSL v 2? If so, how. I need to ruby rails running in docker.
I believe you have to be running Insiders Fast ring 18900+ to install WSL2.
I got this to work for me (using WSL 2). I did have to make sure I was running cmd.exe as admin, before running bash.
Since it is a “lightweight” VM, are there any additional dependencies? (i.e. Hyper-V)
First question I was going to ask. This is important for me, since I’m currently tied to using VirtualBox for other applications which can’t presently function properly alongside Hyper-V since access to VT-x and hence the ability to run 64-bit applications is blocked. The same is true for VMware.
Yeah, presumably it does need Hyper-V, and that’s why they are keeping WSL-1 so that you can still use it when Hyper-V is not an option?
The best thing would be if they were to fix the limitation with Hyper-V but I’m not sure how hard that it is and whether there are any plans to do so.
IIRC VirtualBox >=6.0 can run with Hyper-V present, it uses HV as the execution backend.
This was on the release notes. I haven’t tried it but I went to look and found lots of people complaining that it is difficult to get it to work. (Maybe it has since been fixed up somewhat.) Anyway, I rely heavily on VMware Workstation, so I can’t use this if Hyper-V is actually required. VMware has stated interest in working with Microsoft to make Hyper-V and VMware Workstation get along. Maybe they will actually get around to doing this soon…
This is an amazing engineering effort, I’m seriously impressed by the WSL in its current form let alone in the v2. I’m busy imagining all sorts of fun applications for this.