WSL2 networking goals - need explanation

[luxzg]

In reading multiple issue threads regarding WSL2, including static IPs, network bridging, sharing localhost, hostnames, etc. ( #4210 /
#4601 / #4467 / #4150 / #4199 / etc. ) I came to a great discussion between @benhillis & @therealkenc (#4305) but which prompted even more questions (while providing some insight). Not to litter the other issues mentioned above with continued semi-offtopic discussion, I am opening this issue, and hope that two mentioned above can answer some questions.

On to the topic itself:

• it was mentioned that WSL2 runs all distros inside single VM - how is this possible, and how does the team plan to circumvent obvious issues stemming from it?
• one of prominent issues is running services on same ports between host, and (multiple?) WSL2 distro(s) - if we use simple "localhost" hack, we get issues
• again mentioned in few issues is the point of sharing hostname between host and distro(s), bringing issues like same hostname / different IPs; adding suffixes to hostname for WSL2 distros was proposed solution, bit I didn't see it implemented yet - any new on that? or is it just in the "idea" phase?
• again mentioned in other issues is the apparent goal of having WSL2 share same IP with host, like WSL(1) - is that official long term goal of WSL team? And again, in that case - how do you plan to limit or circumvent issues from using same ports on host and distros, or limit running 1 distro max, etc?
• this all seemingly goes to goal for WSL2 running as WSL (same hostname, same IP, same MAC, transparent localhost & loopback, etc) BUT at the same time we have feature requests of enabling nested virtualization for WSL2 and running KVM on it -- I really don't see the use case of KVM with limitations like ONE network, ever changing one, no possibility of bridging networks, or adding multiple NICs and/or setting up VLANs on those vNICs, etc
• again, going against "WSL2 as WSL" (networking wise) is whole positive feedback on WSL2 advances, which opens up whole new world of possibilities -- BUT(!) only if networking follows along

All these questions combined have a common theme, and simply stated could be put down to this:
Which overall direction WSL team plans to go with WSL2 : 1) "WSL1-like" simplified networking making WSL "user friendly" (ahem) with shared IP/hostname with host, and no further configuration possible, and automatically preventing a lot of advanced WSL usage ; OR ; 2) more "VM-like" advanced networking, perhaps with defaults being simplified (via Default Switch), but allowing for more advanced users setting up their own IPs (per distro), multiple vNICs, VLANs, hostnames, etc, eventually allowing for "native" systems like Docker on WSL2, KVM atop WSL2, etc.

I would be extremely grateful for any answer, even if it is a one-liner saying something like : "Goal is towards option 1)"

Why so much text and so many questions? And why an official team answer would be welcome? Simple - if we go for "1)" we can stop wasting time opening and maintaining issues like ones mentioned at beginning, or trying to make it work, or hope for fixes, and just turn to other solutions (eg. real Linux VMs on Hyper-V as so far). And if it is "2)" perhaps we can encourage two-way dialogue and allow general public to be of more help with actual scenarios or potential solutions.

As the end, I'd like to remind Microsoft that target audience for WSL aren't your average Joe's, it's IT professionals, be it devs, sysadmins, or anything in between, so a lot of those professionals really hope for "2)" as much as possible.

Thanks for understanding,
Luka

[luxzg]

Thanks for comments @therealkenc

[luxzg]

As per blogpost WSL2 will go live soon with Windows 10 2004.

https://devblogs.microsoft.com/commandline/wsl2-will-be-generally-available-in-windows-10-version-2004/

Looking at open issues, and lack of answers or infos in issues and changelogs, seems MS team chose neither 1) nor 2), instead going simply with "as-is", and everything beyond that just being described as "by design".

Too bad...