I can't agree with this. Everything is running on Windows. The VM runs on Windows and WSL exchanges data with Windows all the time. That the data on the Windows side can leak because I installed a Microsoft-approved product from the Microsoft store on a Windows box with a Microsoft firewall is unacceptable.
This is how you get real linux “on” windows - the on part is an illusion, trickery to make using linux transparent and integrated. By comparison, WSL1, which is still supported, is “just” (it’s actually pretty impressive in its own right) syscalls translated to the NT kernel.
Microsoft could do a better job communicating this, but I don’t think any of their design decisions are bad in this regard.
You know, just like the software inside the Windows VM can launch a separate Linux VM; you're already controlling HyperV from inside that VM.
It makes perfect sense now you say it - I knew hyper-v was a hypervisor, I knew in basic broad strokes what a hypervisor is and where it sits, but for some reason this didn't occur to me.
It could be very alarming to people running containers 'on a Windows' server, but then such people are probably more familiar with hypervisors anyway.
Is hyper-v networking still somehow configurable from the 'host', or is it undesirable for containers unless you don't want to do anything to the network (in software on that machine)?
Microsoft should make it more obvious since most Windows 10 users shouldn't be expected to make this distinction by themselves.
As far as I understand, that is not quite right. With WSL2, everything is running on Hyper-V, the VM and Windows both run in parallel on Hyper-V.
