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!
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.
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.
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.
As WSL1 runs on the same kernel I have stuff like named pipes available. I can fully mix processes from both worlds in one workflow. _Some_ of that works with WSL2 as well, but as it's processes on two different kernels requires hidden workarounds to make that work - and not everything is working (and may be even possible).
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.
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.
> For faster startup, lower memory footprint and so on
Any idea how they do this? My WSL2 starts insanely fast, like about 1-2 seconds. I've never seen a linux distro natively boot that fast. Assuming they suppress any sort of BIOS startup screen for starters, but what else?
At high level, WSL2 provides a single optimized VM and Microsoft-compiled Linux kernel. Optimized here means that the VM only provides a small set of devices to the Linux kernel, and the kernel operates with exact known hardware, which is much smaller and simpler compared to a full blown kernel (which detects a large variety of hardware) and fuller featured VMs (c.f. qemu emulated devices: https://kashyapc.fedorapeople.org/virt/qemu/qemu-list-of-emu...).
And when you run multiple "distributions" or instances, they all share the same running VM and kernel. So after a one-time startup of the VM+kernel, opening more distributions/instances is like starting new system containers (similar to lxc/lxd or systemd-nspawn, which are also very quick to spawn on Linux) rather than new VMs. The architecture is quite similar to Linux-on-ChromeOS (Crostini).
It’s a very trimmed down kernel with minimal set of drivers and modules. It doesn’t even support SD cards out of the box. That’s probably the main reason as no hardware probing/initialization delays are incurred.
Actually I don't know it either. But WSL2 doesn't really start a lot of processes, like a desktop/server Linux distribution. It starts up only a minimal set of processes, and a shell.
dmesg looks like the kernel is booting up normally, so I guess they don't use some memory snapshots magic.
I guess they just tweaked the kernel and the hypervisor to start up fast. There is also no BIOS/UEFI delay.
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.
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.
We use it work to do things on WSL2 in Azure Desktop that don’t require a Linux VM and using Windows versions of tools that feel clunky like helm, kubectl, etc. We can easily interface with ACR and AKS this way.
I guess the main issue is, that Windows filesystem APIs are slow. Windows does a lot of things when opening/closing file handles (acls, virus scanning, and many more). Unix style applications with a lot of small files just perform really poorly. That's also why npm install takes ages on Windows.
They made it much better with Dev Drives, that use ReFS instead of NTFS and disables most of the filters in the filesystem stack.
I am advising a dev team that's used to using windows to use WSL for the new NextJS app we're building.
But the filesystem performance really put a huge spoke in this. I thought everything was better with WSL2, but I was surprised to see that MS hasn't engineered some driver or something that would make this much more performant or pass-thru so that you can have a directory on windows but also have it perform really well in the VM.
The file operations on macOS are rather slow too. I needed to invest in some rsync-based syncing for an in-docker application build as accessing the mounted volume from a Docker container was around 20 times slower than on Linux :O
That’s another issue. The access from macOS/windows to the Linux filesystem (docker volume) is over the loopback network. Also the other way around docker bind mounts to windows/macos filesystem.
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.
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)
Thanks!
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!
Regular Hyper-V VMs can use it too but it's not well documented.
The keyword to search for: "GPU-P"
https://learn.microsoft.com/en-us/windows-server/virtualizat...
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.
See https://learn.microsoft.com/en-us/windows-server/virtualizat....
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.
Missed the background info that WSL 1 was a pico process, based on Drawbridge research, and not the same as previous subsystems.
"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...
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.
Windows files are still available via /mnt/c on WSL2
As WSL1 runs on the same kernel I have stuff like named pipes available. I can fully mix processes from both worlds in one workflow. _Some_ of that works with WSL2 as well, but as it's processes on two different kernels requires hidden workarounds to make that work - and not everything is working (and may be even possible).
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.
The issue I have is VHDX keeps expanding, and you need to manually compact it to claim disk back to host.
You need to enable sparse VHD! However it doesn't alwyas trigger. I have moderate success with enabling TRIM systemd service on the distro.
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...
I think there is an auto shrink feature, but it might cause more trouble than good.
cpu 100% and shitty integration.
Yes, it's "just" a VM.
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.
Thankfully getting laptops with 32 GB on PC land isn't the same as paying Apple premium.
I guess you didn't check the latest memory prices. 64 GB used to be dirt cheap, but not anymore.
Well thankfully I don't buy hardware every year, my laptop is from 2021.
Also the difference to Apple tax in SSDs and RAM remains, or do you think Apple will let go of their beloved margins on top?
if you're buying 'gaming' laptops - sure, but in business laptop world, Lenovo/Dell/HP premiums on RAM and SSD can be much higher than Apple's.
I've just put a stick of memory into my company thinkpad.
> For faster startup, lower memory footprint and so on
Any idea how they do this? My WSL2 starts insanely fast, like about 1-2 seconds. I've never seen a linux distro natively boot that fast. Assuming they suppress any sort of BIOS startup screen for starters, but what else?
At high level, WSL2 provides a single optimized VM and Microsoft-compiled Linux kernel. Optimized here means that the VM only provides a small set of devices to the Linux kernel, and the kernel operates with exact known hardware, which is much smaller and simpler compared to a full blown kernel (which detects a large variety of hardware) and fuller featured VMs (c.f. qemu emulated devices: https://kashyapc.fedorapeople.org/virt/qemu/qemu-list-of-emu...).
And when you run multiple "distributions" or instances, they all share the same running VM and kernel. So after a one-time startup of the VM+kernel, opening more distributions/instances is like starting new system containers (similar to lxc/lxd or systemd-nspawn, which are also very quick to spawn on Linux) rather than new VMs. The architecture is quite similar to Linux-on-ChromeOS (Crostini).
It’s a very trimmed down kernel with minimal set of drivers and modules. It doesn’t even support SD cards out of the box. That’s probably the main reason as no hardware probing/initialization delays are incurred.
Actually I don't know it either. But WSL2 doesn't really start a lot of processes, like a desktop/server Linux distribution. It starts up only a minimal set of processes, and a shell.
dmesg looks like the kernel is booting up normally, so I guess they don't use some memory snapshots magic.
I guess they just tweaked the kernel and the hypervisor to start up fast. There is also no BIOS/UEFI delay.
you can access the internal VM disk via
UNC and you should be able to easily subst a drive letter for the dumb software from eons ago that doesn't support UNC paths.Tip for all you hackers out there. WSL bypasses windows firewall rules by default. Not sure why Microsoft ever thought that was a good idea.
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.
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.
Imo, WSL2 is almost indistinguishable from a true Ubuntu VM. If you haven't tried it since WSL1, I'd give it a shot.
Of course this comes down to whether you care or not about the integrations with Windows.
We use it work to do things on WSL2 in Azure Desktop that don’t require a Linux VM and using Windows versions of tools that feel clunky like helm, kubectl, etc. We can easily interface with ACR and AKS this way.
> Linux and Win32 filesystem APIs were too different, and translating them made some apps and some workflows seriously suffer.
Is the reverse also true? Does Wine face any similar performance problems?
I guess the main issue is, that Windows filesystem APIs are slow. Windows does a lot of things when opening/closing file handles (acls, virus scanning, and many more). Unix style applications with a lot of small files just perform really poorly. That's also why npm install takes ages on Windows.
They made it much better with Dev Drives, that use ReFS instead of NTFS and disables most of the filters in the filesystem stack.
I am advising a dev team that's used to using windows to use WSL for the new NextJS app we're building.
But the filesystem performance really put a huge spoke in this. I thought everything was better with WSL2, but I was surprised to see that MS hasn't engineered some driver or something that would make this much more performant or pass-thru so that you can have a directory on windows but also have it perform really well in the VM.
No, don’t use WSL for JavaScript development. Dev Drive is what you’re looking for.
But also pnpm has quite decent performance on NTFS, it uses symlinks
Sadly DevDrive doesn't perform that much better. ReFS write performance is slower than NTFS due to journaling.
https://github.com/NullVoxPopuli/disk-perf-git-and-pnpm
The file operations on macOS are rather slow too. I needed to invest in some rsync-based syncing for an in-docker application build as accessing the mounted volume from a Docker container was around 20 times slower than on Linux :O
That’s another issue. The access from macOS/windows to the Linux filesystem (docker volume) is over the loopback network. Also the other way around docker bind mounts to windows/macos filesystem.
Every FS I've ever had the misfortune of using chokes on lots of small files, especially if they're stored in a flat manner.
Everything except FAT/NTFS is fine for small files. Refs works fine on windows too.
Listing large directories is slow. But it is what it is.
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?
wine gets support from the kernel, like case-insensitive directories on ext4.
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.
yes just use brige networking instead of nat
[dead]
[dead]