Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WSL2: hyper-v sockets, and VMID #4131

Closed
simonferquel opened this issue Jun 14, 2019 · 11 comments
Closed

WSL2: hyper-v sockets, and VMID #4131

simonferquel opened this issue Jun 14, 2019 · 11 comments
Labels
feature wsl2 Issue/feature applies to WSL 2

Comments

@simonferquel
Copy link

Please fill out the below information:

  • Your Windows build number: Microsoft Windows [Version 10.0.18917.1000]

  • What you're doing and what's happening:
    I am a member of the Docker Desktop team, working on integration with WSL2. We are using Hyper-V socket as a way to communicate between Windows and Linux processes (as cross-os unix sockets are not available yet on WSL 2). Everything works fine, but retrieving the VMID for setting up the HV-Socket connection requires admin privileges, and finding which running VM is hosting the current user's WSL distros.

  • What's wrong / what should be happening instead:
    We need an API for getting this VMID reliably without admin privileges.

@simonferquel
Copy link
Author

@Biswa96 You wrote the WslReverse thing right ? it's awesome ! I did not find anything about the VMID in the LxssManager COM interfaces though, have you ?

@craigloewen-msft craigloewen-msft added feature wsl2 Issue/feature applies to WSL 2 labels Jun 14, 2019
@benhillis
Copy link
Member

We are working on a better host / guest communication channel that does not rely on hvsocket. I would not suggest taking a dependency on undocumented COM APIs because a certain dev (who happens to have a very handsome dog as his profile picture) tends to change them with wanton disregard.

@Biswa96
Copy link

Biswa96 commented Jul 27, 2019

retrieving the VMID for setting up the HV-Socket connection requires admin privileges

I have a semi-documented method. Use HcsEnumerateComputeSystems() to get the list of running containers/VMs. The output will be a JSON arrays of VMs properties. From the output, get "Id" attribute and the value contains "WSL-" string. If the previous condition is true the "RuntimeId" contains the VMID. For example the full output is like this:

[
    {
        "Id": "WSL-03697A70-A16F-4AE6-BC91-73A1AD28E55B",
        "SystemType": "VirtualMachine",
        "Owner": "WSL",
        "RuntimeId": "89d139ca-2324-5976-8706-dd7fd705ef16",
        "State": "Running"
    }
]

More in my hvtool toy.

@simonferquel
Copy link
Author

That is what we do in Docker Desktop for now. Problem is: if there are multiple user sessions active at the same time running wsl, you have no way to know which VM belongs to which user. Also, this API requires elevated privileges

@Biswa96
Copy link

Biswa96 commented Jul 27, 2019

if there are multiple user sessions active at the same time running wsl

The VMID is same with multiple distribution.

this API requires elevated privileges

You can wrap those functions and run it as a service, just like LxssManager does.

@simonferquel
Copy link
Author

Again that is what we do.
The VM is unique for a single user. But 2different users on the same machine get each their own VM

@benhillis
Copy link
Member

I worked with @simonferquel offline and this is no longer a requirement for Docker.

@Biswa96
Copy link

Biswa96 commented Oct 21, 2020

this is no longer a requirement for Docker.

Is there any source available to see the change?

@simonferquel
Copy link
Author

@Biswa96 no source code, but the approach is simple: instead of using hv socks for win32/Linux process communication, we wrote a bridge witch exposes our unix sockets in the Linux world as windows named pipes and vice versa.
The bridge consist of a win32 executable that spawns a Linux executable within the target wsl distro, and they communicate exclusively via stdio streams (we previously multiplexed the unix socket and named pipe connections trough a single hv sock, we now multiplex the same thing trough stdio).

It is surprisingly scalable enough for all docker desktop needs.

@Biswa96
Copy link

Biswa96 commented Oct 21, 2020

This is many times more work than if a simple a GUID available to users since WSL2 introduction.

@simonferquel
Copy link
Author

This is if you need to do multiplexing. If you just need to connect to a unix socket from windows, you can just wsl.exe socat <correct args> and voila :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature wsl2 Issue/feature applies to WSL 2
Projects
None yet
Development

No branches or pull requests

4 participants