WSL 2 runs on a subset of Hyper-V, and on a hypervisor, so basically yes.
However, there's some interesting things going on in WSL 2 versus a "normal" Hyper-V virtual machine. For example, a Linux distro running on WSL can (and will) use GPU partitioning (aka PCI/GPU passthrough) and a special implementation of DirectX enabling the installed video card to accelerate graphics within X and/or Wayland.
Although this feature can be enabled with a lot of hacking in both the Linux guest and vanilla Hyper-V on the host (the latter through Powershell) it is officially unsupported on Windows 10 and Windows 11, and is only supported on Windows Server.
Oh, I thought GPU passthrough was enabled on vanilla Windows 11, but I didn't delve into that feature enough. It's still extremely impressive of course. Perhaps I should write another article about graphical features.
No, PCI-E passthrough is not enabled on non-Server, and you arguably wouldn't do this on a Windows hypervisor. anyways, you'd do it with a Linux+KVM hypervisor for either Linux or Windows guests.
Using GPU passthrough, however, is allowed. WSL2 does this by using the existing Mesa/DRI/DRM open source stack, but instead of a GPU-specific DRM driver, it is one that speaks WDDM (the DRM equivalent in the Windows driver stack), and only requires a GPU-specific ennoblement package (provided by the vendor, and matches the Windows driver it is talking to; AMD, Nvidia, and Intel all ship one inside of WSL2).
> No, PCI-E passthrough is not enabled on non-Server, and you arguably wouldn't do this on a Windows hypervisor. anyways, you'd do it with a Linux+KVM hypervisor for either Linux or Windows guests.
If it was enabled on Pro, I would use PCI passthrough. I use hyper-v for a Linux dev environment on a windows workstation. My NIC supports virtual functions, so if I could passthrough one to the dev VM, I wouldn't need software bridging and that might be nice. (OTOH, I don't know if my motherboard has reasonable passthrough groups and all the other stuff that makes passthrough never work for me)
It relies upon SR-IOV and only several server-specific Nvidia GPUs are listed as supported.
Intel's Flex dGPUs and Arc iGPUs have supported SR-IOV for years now, but they aren't listed there. It would be super awesome if Microsoft could add it for Intel Arc iGPUs, desktop versions of Windows, and WSL2! Intel's GPU SR-IOV already works with KVM on Linux!
Thus far I have found the native WSL2 graphics integration to be pretty disappointing in comparison to what I used to get with X-server setup. Unfortunately the legacy X implementation doesn’t have the modern API and application developers are tapering their interest in it. Hopefully the groundswell of WSL2 support will improve this in time …
Agreed. No way to really test WebGPU, for instance. You can't really test GPU drivers under Linux or using the native Windows browsers. Lots of incomplete attempts to make this work, none of which are reliable or easy to use.
As an end user, the out of the box experience of getting a blurry window with the wrong content size isn't very useful. And I've never tried to actually configure it properly.
I wonder if it's a decent experience even when configured properly. In that case, why do all the IDEs come with remote development / WSL integrations that involve running the client on the Windows side?
Don't WSL2 and the WinNT kernel both run on top of Hyper-V, on (very approximately) equal footing? The NT kernel, of course, has all the hardware access, not necessarily granted to other VMs, such as WSL2.
> For example, a Linux distro running on WSL can (and will) use GPU partitioning (aka PCI/GPU passthrough) and a special implementation of DirectX
That is still just a normal VM, but it's nice that it's automated.
> enabling the installed video card to accelerate graphics within X and/or Wayland.
nit: X and/or Wayland is not involved in application rendering at all - its applications themselves that use the GPU and its acceleration directly.
Wayland and/or X is only involved when the apps are all done rendering[0], and the display servers own rendering is the comparatively simple task of stitching windows together[1], and sometimes not even that.
0: You can send buffers early over Wayland if you also send a sync fence, but this is just forwarded as a render dependency that the GPU scheduler will patiently wait for.
1: well also dealing with stuff like color transforms which can be complex to understand, but are computationally cheap and for fullscreen content possibly entirely free.
WSL2 is a bit like Firecracker for Linux. It's a lightweight VM, with a lot of optimizations here and there. For faster startup, lower memory footprint and so on.
PS: which means you need a lot of memory, if you use WSL2 extensively (multiple Docker containers for example). 8-16 GB on top of your usual workloads is a good starting point. Docker on WSL2 is not a lot of fun with less than 20 GB system memory.
Yes, a VM with extremely tight integration with the Windows environment to make things that would otherwise require lots of time to setup a breeze. I use it as my daily driver for dev work (at work, since we're required to use Windows :( ) and to be honest it's quite pleasant most of the time.
I usually work in a VM hosted by my company. But the performance is really starting to irritate me. Been considering switching to WSL2, but last time I checked all they supported was Debian based distros, and we do all our work on RHEL8. I don't think it would matter much but it's still annoying working on an entirely different setup from the rest of the team.
How is it "tight" when even `ps` or `top` show VM processes instead of OS ones? Could you give an example of functionality that can't be done with `docker run -it ubuntu`?
I used it for a little bit (got Windows laptop, thought maybe I'll switch but no), and just hated that split brain workspace.
I always found wsl to be a hack and not a true Linux distro, fake pid 1 not really starting or shutting down ect... Even the docker integration is really odd. I know it was fixed with wsl2 but wsl1 had terrible i/o performance.
Actually, there's an interesting question - how does Wine implement (or not implement) Windows API calls which interact with filesystem features which aren't available on Linux, like alternate data streams or complex ACLs?
Can you create multiple instances each with their own IP address like you can with Virtualbox? Networking was the reason I didn't stick with WSL2 when I tried it but that was a long time ago and it's probably improved.
Strangely, if you create multiple 'instances', they're actually all running as "containers" in the same vm with the same kernel. You can see this by running `wsl --system` and noticing that ps will show you processes from all running wsl distros.
The article mentions dynamic memory sizing as one of the benefits of WSL2 over traditional VMs, but afaik Hyper-V supports that on normal Linux VMs too. WSLg is genuinely pretty nifty, but for command-line stuff WSL2 imho doesn't really bring that many advantages.
While I understand _why_ they did WSL2 it's pretty sad that they at the same time they just dropped any WSL1 development.
We're using a lot of WSL in CI - we're mostly Linux based, but for some stuff toolchains came up which didn't work nicely with wine (like MSVC). So for us we want a Linux system that seamlessly can execute Windows stuff in a Linux based build process. WSL1 can do that, WSL2 can be kicked into working somewhat, but needs quite a few ugly workaround as they're not sharing a process namespace or file descriptors. While the faster IO would be nice that's pretty much the only thing we'd care about - and wouldn't work here, as we need shared access to the files. And while we could access the WSL2 files from Windows side that's even slower than just using WSL1.
Could one mount a real coexisting ext4 partition to reduce some of the perf penalty of having to simulate a block device on top of those ugly big image files?
WSL1 felt like a useful compatibility layer for running some Linux applications in Windows. It had plenty of warts, but it quickly became my preferred command shell for Windows.
WSL2 is more capable, but it's not Windows anymore. I might as well run a proper Linux VM or dual boot. Better yet, I'd rather run a Windows VM in a bare metal Linux OS. Why even bother with WSL2? What's the value add?
"1.6GB on a 32GB system. [...] I think that's pretty much okay. What'a a gigabyte to spare in these days anyway? Just assume that you're running your clock app under Electron."
I find WSL 1 incredibly useful. C++ and .NET compiler toolchains, ssh and scp clients, and many other command-line Linux tools are working flawlessly for me despite the fake emulated kernel lacking some of the APIs. When I develop anything related to Linux be it embedded or servers, I use WSL1 a lot.
I find WSL2 pretty much useless. When I want Linux inside a VM I use VMware which is just better. VMware has tree of snapshots to rollback disk state, hardware accelerated 3D graphics (limited though, I think only GL is there no Vulkan, but it’s better than nothing), can attach complete USB devices to the guest OS, can setup proper virtual networks with multiple VMs, and the GUI to do all that is decent, no command line required.
Some distros have better WSL support than others—some will only work with systemd disabled, others have issues with X11. Ubuntu is well supported of course, but on the RHEL-ish side I've found that AlmaLinux 10 works especially well.
50 comments
[ 2.9 ms ] story [ 74.1 ms ] threadHowever, there's some interesting things going on in WSL 2 versus a "normal" Hyper-V virtual machine. For example, a Linux distro running on WSL can (and will) use GPU partitioning (aka PCI/GPU passthrough) and a special implementation of DirectX enabling the installed video card to accelerate graphics within X and/or Wayland.
Although this feature can be enabled with a lot of hacking in both the Linux guest and vanilla Hyper-V on the host (the latter through Powershell) it is officially unsupported on Windows 10 and Windows 11, and is only supported on Windows Server.
Using GPU passthrough, however, is allowed. WSL2 does this by using the existing Mesa/DRI/DRM open source stack, but instead of a GPU-specific DRM driver, it is one that speaks WDDM (the DRM equivalent in the Windows driver stack), and only requires a GPU-specific ennoblement package (provided by the vendor, and matches the Windows driver it is talking to; AMD, Nvidia, and Intel all ship one inside of WSL2).
If it was enabled on Pro, I would use PCI passthrough. I use hyper-v for a Linux dev environment on a windows workstation. My NIC supports virtual functions, so if I could passthrough one to the dev VM, I wouldn't need software bridging and that might be nice. (OTOH, I don't know if my motherboard has reasonable passthrough groups and all the other stuff that makes passthrough never work for me)
https://techcommunity.microsoft.com/blog/windowsosplatform/a...
The keyword to search for: "GPU-P"
https://learn.microsoft.com/en-us/windows-server/virtualizat...
It relies upon SR-IOV and only several server-specific Nvidia GPUs are listed as supported.
Intel's Flex dGPUs and Arc iGPUs have supported SR-IOV for years now, but they aren't listed there. It would be super awesome if Microsoft could add it for Intel Arc iGPUs, desktop versions of Windows, and WSL2! Intel's GPU SR-IOV already works with KVM on Linux!
As an end user, the out of the box experience of getting a blurry window with the wrong content size isn't very useful. And I've never tried to actually configure it properly.
I wonder if it's a decent experience even when configured properly. In that case, why do all the IDEs come with remote development / WSL integrations that involve running the client on the Windows side?
Imagine licensing and installing Windows Server to run Linux software through WSL
https://learn.microsoft.com/en-us/azure/iot-edge/tutorial-de...
That is still just a normal VM, but it's nice that it's automated.
> enabling the installed video card to accelerate graphics within X and/or Wayland.
nit: X and/or Wayland is not involved in application rendering at all - its applications themselves that use the GPU and its acceleration directly.
Wayland and/or X is only involved when the apps are all done rendering[0], and the display servers own rendering is the comparatively simple task of stitching windows together[1], and sometimes not even that.
0: You can send buffers early over Wayland if you also send a sync fence, but this is just forwarded as a render dependency that the GPU scheduler will patiently wait for.
1: well also dealing with stuff like color transforms which can be complex to understand, but are computationally cheap and for fullscreen content possibly entirely free.
WSL2 is a bit like Firecracker for Linux. It's a lightweight VM, with a lot of optimizations here and there. For faster startup, lower memory footprint and so on.
PS: which means you need a lot of memory, if you use WSL2 extensively (multiple Docker containers for example). 8-16 GB on top of your usual workloads is a good starting point. Docker on WSL2 is not a lot of fun with less than 20 GB system memory.
How is the graphical app support these days?
I used it for a little bit (got Windows laptop, thought maybe I'll switch but no), and just hated that split brain workspace.
Of course this comes down to whether you care or not about the integrations with Windows.
Is the reverse also true? Does Wine face any similar performance problems?
Here is the tracking issue:
https://github.com/microsoft/WSL/issues/12103
And if nothing works you can still manually optimize.
https://superuser.com/questions/1827953/reclaim-wsl2-disk-sp...
"The Linux Kernel Hidden Inside Windows 10"
https://youtu.be/_p3RtkwstNk?si=V9vhvrdDOLu2Durr
WSL Pico Process Overview
https://learn.microsoft.com/de-de/archive/blogs/wsl/pico-pro...
The same Drawbridge technology is used to run SQL Server on Linux.
https://arstechnica.com/information-technology/2016/12/how-a...
We're using a lot of WSL in CI - we're mostly Linux based, but for some stuff toolchains came up which didn't work nicely with wine (like MSVC). So for us we want a Linux system that seamlessly can execute Windows stuff in a Linux based build process. WSL1 can do that, WSL2 can be kicked into working somewhat, but needs quite a few ugly workaround as they're not sharing a process namespace or file descriptors. While the faster IO would be nice that's pretty much the only thing we'd care about - and wouldn't work here, as we need shared access to the files. And while we could access the WSL2 files from Windows side that's even slower than just using WSL1.
WSL2 is more capable, but it's not Windows anymore. I might as well run a proper Linux VM or dual boot. Better yet, I'd rather run a Windows VM in a bare metal Linux OS. Why even bother with WSL2? What's the value add?
LOL, this made my day :P
http://www.colinux.org/
I find WSL2 pretty much useless. When I want Linux inside a VM I use VMware which is just better. VMware has tree of snapshots to rollback disk state, hardware accelerated 3D graphics (limited though, I think only GL is there no Vulkan, but it’s better than nothing), can attach complete USB devices to the guest OS, can setup proper virtual networks with multiple VMs, and the GUI to do all that is decent, no command line required.