Announcement

Collapse
No announcement yet.

Microsoft Releases A Big Update To Windows Subsystem For Linux, New Experimental Options

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • edxposed
    replied
    Originally posted by dragorth View Post

    Could it be the Android subsystem? Don't they use the same kernel for both? They may need more time to test that kernel.
    WSA uses another ACK-based kernel that just shares the HV guest driver with the WSL2 kernel.

    Leave a comment:


  • edxposed
    replied
    Originally posted by elvis View Post
    Quite the disappointment, I have to say. WSL users have been requesting a proper, supported bridged interface forever it feels. We've had the NAT option since day one, which is fine for very basic outbound usage. This new "mirrored" option is designed to alleviate the want for inbound connections, except it has serious limitations. Try and start any listening service inside your WSL VM where the network port is in use inside of your Windows host, and the service fails, as this mirrored mode clones your MAC and IP inside the WSL instance entirely. (I've tested this just now to confirm).

    There were some workaround for bridged networking options in Windows 10/11 in the past, but they were troublesome. There was about a 50% hit rate on success based on your specific brand of NIC and driver (and wireless NICs in particular hard a very low success rate). And then any updates to your system generally broke your bridge setup and required you to rebuild it. Compare to other desktop-focussed VM solutions like VirtualBox, where network bridging is very simple, and completely independent of your brand/type of NIC.

    The argument remains that bridging is "advanced usage" territory and "nobody wants it", except I call total BS on that. WSL itself is "advanced usage" territory already, so claiming that customers aren't smart enough to understand network bridging is an insult. Additionally, enough people want a fully supported bridged network setup that we got this "mirrored" thing to appease those requests, except it's a half-solution at best. I also don't really accept the argument that putting a bridged interface in will kill off Hyper-V sales to any level that warrants argument. If people want unrestricted $0 virtualisation, that exists across a multitude of simple solutions today (VirtualBox, ProxMox, many more). There are zero valid reasons for not offering this very standard, very banal feature.

    I really hope Microsoft just get it together and offer bridged networking like literally every other modern desktop VM solution. It's been long enough.

    [wsl2]
    networkingMode = bridged
    vmSwitch = Bridge

    Unrecorded, but is working. 22H2+ only

    Leave a comment:


  • dragorth
    replied
    Originally posted by justinkb View Post
    I checked literally 3 hours ago to see if they updated their kernel and stuff lately. Missed this by one hour, wouldn't have checked again for weeks if it weren't for this article, cheers for that. Weird they still haven't moved the kernel to 6.1 yet when they've already tagged a release for that months ago. I've run that for a while without any problems, not sure why they haven't gone with it
    Could it be the Android subsystem? Don't they use the same kernel for both? They may need more time to test that kernel.

    Leave a comment:


  • elvis
    replied
    Quite the disappointment, I have to say. WSL users have been requesting a proper, supported bridged interface forever it feels. We've had the NAT option since day one, which is fine for very basic outbound usage. This new "mirrored" option is designed to alleviate the want for inbound connections, except it has serious limitations. Try and start any listening service inside your WSL VM where the network port is in use inside of your Windows host, and the service fails, as this mirrored mode clones your MAC and IP inside the WSL instance entirely. (I've tested this just now to confirm).

    There were some workaround for bridged networking options in Windows 10/11 in the past, but they were troublesome. There was about a 50% hit rate on success based on your specific brand of NIC and driver (and wireless NICs in particular hard a very low success rate). And then any updates to your system generally broke your bridge setup and required you to rebuild it. Compare to other desktop-focussed VM solutions like VirtualBox, where network bridging is very simple, and completely independent of your brand/type of NIC.

    The argument remains that bridging is "advanced usage" territory and "nobody wants it", except I call total BS on that. WSL itself is "advanced usage" territory already, so claiming that customers aren't smart enough to understand network bridging is an insult. Additionally, enough people want a fully supported bridged network setup that we got this "mirrored" thing to appease those requests, except it's a half-solution at best. I also don't really accept the argument that putting a bridged interface in will kill off Hyper-V sales to any level that warrants argument. If people want unrestricted $0 virtualisation, that exists across a multitude of simple solutions today (VirtualBox, ProxMox, many more). There are zero valid reasons for not offering this very standard, very banal feature.

    I really hope Microsoft just get it together and offer bridged networking like literally every other modern desktop VM solution. It's been long enough.

    Leave a comment:


  • rhavenn
    replied
    Originally posted by RAINFIRE View Post
    Last I checked OpenSSH wasn't fixed if installed by any method including Features in Win 10, 11, Server or WSL. The SSH Agent was broken effectively disabling passwordless SSH login by public/private key which is huge on the linux side. Broken unless they they fixed the OS part. Last I checked months ago, you still had to download and replace with Github version. In my humble opinion, WSL is a toy linux. Here's the fixed version:

    https://github.com/PowerShell/Win32-OpenSSH/releases
    and that has nothing to do with WSL or WSL2. WSL runs a psuedo Linux VM in a process or hypervisor layer. WSL2 is functionally a HyperV VM that just doesn't have a full network stack. You're talking about the OpenSSH server that you can install as a Windows service and then you can SSH in to a PowerShell prompt at the Windows layer. Totally different beast. Yeah, I had issues awhile back to logging in with an SSH key, but I did fix it, but I don't remember how. then I went..hugh, neat and promptly blew that test box away.

    Honestly, while kinda cool, PS Remoting and the ability to run PowerShell at remote systems and/or run through WSMAN is way more than enough to manage Windows systems. The SSH layer is just a cool "toy" or if you're 99% a Linux shop, but they should fix that SSH key problem.
    Last edited by rhavenn; 18 September 2023, 09:14 PM.

    Leave a comment:


  • Markopolo
    replied
    Great update. I’m most looking forward to the auto memory reclaim feature. It’s not often I have to restart wsl but when I do it’s normally a few minutes into a weird build issue where one instance took too much ram, and the other instances compiles suddenly fail in fun and unique ways I’ve never seen before… (normally windows security updates force a full restart first)

    Leave a comment:


  • damonlynch
    replied
    Originally posted by RAINFIRE View Post

    You don't understand having working public/private keys in SSH, even if it is a sub-system? It means WSL is not usable past the host system without typing passwords everywhere. This makes WSL non-usable on any serious system that has to talk to other computers.
    You are unable to use passwordless SSH on Linux in WSL? That's very odd. I use it to log into a remote server, as well as for GitHub. Works just like on bare metal Linux.

    Leave a comment:


  • rhavenn
    replied
    Originally posted by RAINFIRE View Post

    You don't understand having working public/private keys in SSH, even if it is a sub-system? It means WSL is not usable past the host system without typing passwords everywhere. This makes WSL non-usable on any serious system that has to talk to other computers.
    You've just described a VM running on top of Hyper-V. WSL isn't meant for running a "full" VM with networking, etc... if you need that then just enable Hyper-V, install a VM and there ya go. Considering WSL2 basically installs HyperV for you anyway and is running more or less as a VM then the next logical step is just go full hypervisor.

    and you can talk out just fine. The VM is just not getting it's own IP or a listening port for inbound connections, but you can certainly setup a SSH key (create one or import one) and SSH out to anything you like using keys.
    Last edited by rhavenn; 18 September 2023, 09:06 PM.

    Leave a comment:


  • RAINFIRE
    replied
    Originally posted by V1tol View Post

    I don't understand your use case here. SSH into running WSL instance? Why when you can do it directly via terminal. SSH into some remote server? That's more like it but since when we are talking about WSL you could do that from WSL with it's not-broken client. That means broken ssh.exe has nothing to do with WSL at all.
    You don't understand having working public/private keys in SSH, even if it is a sub-system? It means WSL is not usable past the host system without typing passwords everywhere. This makes WSL non-usable on any serious system that has to talk to other computers.

    Leave a comment:


  • V1tol
    replied
    Originally posted by RAINFIRE View Post
    Last I checked OpenSSH wasn't fixed if installed by any method including Features in Win 10, 11, Server or WSL. The SSH Agent was broken effectively disabling passwordless SSH login by public/private key which is huge on the linux side. Broken unless they they fixed the OS part. Last I checked months ago, you still had to download and replace with Github version. You have to uninstall the OS version and replace with Github version. In my humble opinion, WSL is a toy linux. Here's the fixed version:

    https://github.com/PowerShell/Win32-OpenSSH/releases
    I don't understand your use case here. SSH into running WSL instance? Why when you can do it directly via terminal. SSH into some remote server? That's more like it but since when we are talking about WSL you could do that from WSL with it's not-broken client. That means broken ssh.exe has nothing to do with WSL at all.

    Leave a comment:

Working...
X