Replies: 34 comments 1 reply
-
|
WSL2 itself uses vsock. If there is an error in vsock implementation we wouldn't be able to use WSL2. There may be some error in the x410 program or their method. Can you provide the error in |
Beta Was this translation helpful? Give feedback.
-
|
Here's an strace -ff of the socat process in WSL... like I said, the same thing works in a full Hyper-V VM, so I'd suspect something on the WSL2/Microsoft kernel side. |
Beta Was this translation helpful? Give feedback.
-
|
subscribe, this is a really useful feature of X410 |
Beta Was this translation helpful? Give feedback.
-
|
Also subscribed |
Beta Was this translation helpful? Give feedback.
-
|
For a X GUI users on laptops this is a big deal since this effectively enables your X11 apps to survive a full hibernate. |
Beta Was this translation helpful? Give feedback.
-
|
This is also a big deal with VPN connection. When switching from a VPN connection to an other the X11 apps don't survive… |
Beta Was this translation helpful? Give feedback.
-
|
dmesg reports this when attempted for me (but only on the first attempt after wsl2 boot). So at this point, socat is already started, DISPLAY is set for xterm, then this is triggered the first time xterm tries to connect over socat -> vsock. Looking at the code in upstream, the enum does go up to 23: https://github.com/torvalds/linux/blob/master/include/linux/hyperv.h#L405 But in the Microsoft WSL fork it only goes up to 21: https://github.com/microsoft/WSL2-Linux-Kernel/blob/master/include/linux/hyperv.h#L408 So I wonder if this change is missing: |
Beta Was this translation helpful? Give feedback.
-
|
I tried building a 5.4 kernel with the patch @fquinner mentioned, and while the error in dmesg is gone, I still get the error below when trying to open an X11 app, so it seems like vsock is really not supported in WSL2. It does work for me in a real Hyper-V VM, so X410 is definitely set up correctly.
|
Beta Was this translation helpful? Give feedback.
-
|
I just got a suspicion about this. In the 4.19x series, vhost_vsock is disabled in the config due to a bug. However the bug is fixed in the 5.x series. Enable |
Beta Was this translation helpful? Give feedback.
-
|
@WSLUser that appears to be for a VM host kernel to provide AF_VSOCK sockets for communicating with guests, so it seems to be unrelated. In any case, I tried enabling it on a 5.4 kernel and it just causes WSL to not start... rebuilding the exact same kernel with only that one config option disabled resulting in a working kernel. |
Beta Was this translation helpful? Give feedback.
-
|
Strange. It works fine on the stable edition of the kernel. Are you also on Insiders? I'm just using 2004 with my config options and I have no difficulties whatsoever. In fact it feels better than normal. The crash is likely due to some other virtualization options not being enabled. The config option was originally enabled when WSL2 first appeared but was dropped due to issues that were later fixed. Those fixes never trickled down to the 4.19x LTS edition. See using my config as linked in my previous comment with the stable kernel. Be sure to run |
Beta Was this translation helpful? Give feedback.
-
|
The failures coming back are all "nothing listening on that port"; the "unknown msgtype" failure is just noise that can be ignored, since it turns into a timeout eventually, and the patch just silences this noise (which is a shame, since "port closed" would be a useful distinction for this case, versus "something there but it was too slow" timeouts). The traces show it trying to connect to vsock port 6000 (0x00001770) (i.e. display 0), so you may want to check on the host side exactly what hyper-v address is being listened for, and that the registry entry for display 0 is present. Based on MS Docs it should be a I'm not sure how you check that, something that lists listening sockets might support |
Beta Was this translation helpful? Give feedback.
-
|
The listen address and registry entries are correct since I can literally fire up a hyperv vm on same host and it works fine (I think others are doing the same). I did recompile latest upstream kernel and (after being amazed that it worked out of the box) it had no dmesg errors but still failed some weeks ago. I could try again with this configuration though I guess. |
Beta Was this translation helpful? Give feedback.
-
|
What if you run your Hyper-V VM with the kernel used in WSL2? Assuming no other problems come up, that would rule-in or rule-out a kernel-related issue. |
Beta Was this translation helpful? Give feedback.
-
|
@WSLUser I tried compiling kernel with your configuration and running it, but it did not work. Note that I see this which suggests that the kernel module is statically built in if i understand correctly (lsmod just returns an empty list on WSL since WSL config seems to favour static compilation and I remember last time i fought with this, trying to set up the hv modules as shared objects resulted on hanging on startup): |
Beta Was this translation helpful? Give feedback.
-
|
Ah right yeah the kernel does work fine when using latest kernel but vsock doesn't seem to play nicely with it. Vsock I think is only available on X410 and is super nice if it works because it means your x sessions can survive hibernate, suspend, network change etc. It's weird though because the kernel does look like it contains it OK but it doesn't seem to be able to work with X410 / wsl2. |
Beta Was this translation helpful? Give feedback.
-
|
According to https://github.com/microsoft/WSL2-Linux-Kernel/issues/7, at some point, WSL2's own startup process is using VSock to connect to systems on the host. So it seems unlikely that vsock itself is broken in the kernel build. We can see that with I wonder if the WSL2 uVM doesn't show up in a group such as That's speculation though. I haven't found anything like |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I'm very interested in having X410 + WSL2 + Vsock display working. Does anyone know how to achieve this? I currently have Sound working fine as I have Pulse Server installed a service on windows side, and x410 installed as a service windows side. But sleep/hibernate breaks the display x410 connection. If i was able to get it working under Sock, would the pulse server continue to work, or would i need to have an XRDP pulse sink? |
Beta Was this translation helpful? Give feedback.
-
|
When you use vsock and x410 there is no need for xrdp at all. |
Beta Was this translation helpful? Give feedback.
-
|
Just to nail this down, I confirmed that incoming VSock connections from Windows into the WSL2 session work fine with stock WSL2 Ubuntu and kernel For tracing HyperV sockets, you can use Winsock Tracing. "Family 34" in the resulting logs is So I turned the code from Stack Overflow into a listener, and I think I have identified the issue. (Full Host-side code and test instructions inside the Details fold) Fill in your MicroVM UUID and compile with If you get 'connected timed out' on the WSL side, it didn't work. If the test exits immediately, and so does the listener on the Windows side, then it worked. #include <iostream>
#include <winsock2.h>
#include <ws2tcpip.h>
#include <hvsocket.h>
#include <combaseapi.h>
#pragma comment(lib, "Ws2_32.lib")
int main()
{
// UUID FROM hcsdiag list
struct __declspec(uuid("4D5065CF-9632-484E-A27D-C2F1B09CDBD3")) ServerVsockTemplate {};
//----------------------
// Initialize Winsock
WSADATA wsaData;
int iResult = WSAStartup(MAKEWORD(2, 2), &wsaData);
if (iResult != NO_ERROR) {
wprintf(L"WSAStartup function failed with error: %d\n", iResult);
return 1;
}
//----------------------
// Create a SOCKET for connecting to server
SOCKET ListenSocket;
ListenSocket = socket(AF_HYPERV, SOCK_STREAM, HV_PROTOCOL_RAW);
if (ListenSocket == INVALID_SOCKET) {
wprintf(L"socket function failed with error: %ld\n", WSAGetLastError());
WSACleanup();
return 1;
}
//----------------------
// The sockaddr_in structure specifies the address family,
// IP address, and port of the server to be listened on.
SOCKADDR_HV clientService;
clientService.Family = AF_HYPERV;
clientService.Reserved = 0;
clientService.VmId = __uuidof(ServerVsockTemplate);
clientService.ServiceId = HV_GUID_VSOCK_TEMPLATE;
clientService.ServiceId.Data1 = 6000;
//----------------------
// Bind the socket
iResult = bind(ListenSocket, (SOCKADDR*)&clientService, sizeof(clientService));
if (iResult == SOCKET_ERROR) {
wprintf(L"bind function failed with error: %ld\n", WSAGetLastError());
iResult = closesocket(ListenSocket);
if (iResult == SOCKET_ERROR)
wprintf(L"closesocket function failed with error: %ld\n", WSAGetLastError());
WSACleanup();
return 1;
}
iResult = listen(ListenSocket, SOMAXCONN);
if (iResult == SOCKET_ERROR) {
wprintf(L"listen function failed with error: %ld\n", WSAGetLastError());
iResult = closesocket(ListenSocket);
if (iResult == SOCKET_ERROR)
wprintf(L"closesocket function failed with error: %ld\n", WSAGetLastError());
WSACleanup();
return 1;
}
wprintf(L"Listening for clients.\n");
SOCKET ConnectedSocket = accept(ListenSocket, nullptr, 0);
if (ConnectedSocket == INVALID_SOCKET) {
wprintf(L"accept function failed with error: %ld\n", WSAGetLastError());
WSACleanup();
iResult = closesocket(ListenSocket);
if (iResult == SOCKET_ERROR)
wprintf(L"closesocket function failed with error: %ld\n", WSAGetLastError());
return 1;
}
iResult = closesocket(ConnectedSocket);
if (iResult == SOCKET_ERROR) {
wprintf(L"closesocket(ConnectedSocket) function failed with error: %ld\n", WSAGetLastError());
WSACleanup();
return 1;
}
iResult = closesocket(ListenSocket);
if (iResult == SOCKET_ERROR) {
wprintf(L"closesocket(ListenSocket) function failed with error: %ld\n", WSAGetLastError());
WSACleanup();
return 1;
}
WSACleanup();
return 0;
}
While a normal Hyper-V VM can be listened-to using i.e., this worked: but this didn't work, which is almost certainly what X410 does internally. This version would work with any normal Hyper-V VM. So something about the way the MicroVM is set up, it doesn't see generically-listening Guest Communication Services. This is probably a bug MS will need to deal with, as I'm unsure if this is intrinsic to the GCS system, or something about WSL that can be fixed. It might also be possible that there's a different known-UUID that can be listened-on, or a socket option that can be set, to make the HCS MicroVM able to connect to a socket that isn't bound to it specifically. In the meantime, either X410 can be modified to be able to be told what HCS MicroVM to listen for, or (with Admin rights) it can search for one itself. Or perhaps a little utility could be written that listens for the MicroVM, and forwards to X410, rather than using X410's own VSock support. I also checked, and I didn't need to add the registry entries from the X410 docs. I suspect they are only needed when listening for |
Beta Was this translation helpful? Give feedback.
-
|
@TBBle Ha you beat me to it I was going to try exactly that when I got back from holidays - nice work. |
Beta Was this translation helpful? Give feedback.
-
|
One thing worth noting is that the WSL2 Edit: Yup, confirmed with Winsock Tracing. From a shutdown state, a HCS MicroVM with UUID "2F34B9CA-408C-428D-AC02-9666646AE568" was created, and you can see a socket bind and listen: You can see the bind address 0x22000000CAB9342F8C408D42AC029666: "Family 34, Reserved 00, VmID 0xCAB9342F8C408D42AC029666 (== UUID '2F34B9CA-408C-428D-AC02-9666...' cut off due to trace output)" I'm not sure what that return address (0x898BDB90350D794F8CE949EA...) is, but I suspect that it's the UUID of my machine, and I'd see it if I were to query the listening socket with So if there's a magic "Listen to all VMs and all HCS MicroVMs" GUID, the existing WSL2 code isn't using it. |
Beta Was this translation helpful? Give feedback.
-
|
Great work guy's. SO as x410 is closed source, we need some sort of way in to modify x410 either via conf files? Perhaps X410 dev can use your instruction to see how it can detect the GUID of the MicroVM on the host side and listen for it? |
Beta Was this translation helpful? Give feedback.
-
|
I pinged the x410 support desk and referenced this ticket will see what they come back with... |
Beta Was this translation helpful? Give feedback.
-
|
The WSL GUID changes every time the MicroVM is shutdown and restarted. |
Beta Was this translation helpful? Give feedback.
-
|
It's a bug. HV_GUID_WILDCARD and HV_GUID_CHILDREN are not called how they are without a reason. And thanks @TBBle for figuring this out. I hope MS will be able to fix this soon for insiders. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, sorry, I forgot to be explicit, that the GUIDs I used were just what happened to come up on my machine while testing: there's no fixed WSL2 MicroVM GUID. You can see the different GUIDs between my two comments. ^_^ I suspect the root cause here is that the HCS MicroVMs are also used for Windows Containers, and I am not sure if containers would be expected to see the same Guest Communication Services as VMs see, without something in the OCI setup specifying a shared network namespace, as it would be a silent isolation break. Hopefully this is something the WSL2 MicroVM can be configured to allow, without breaking the isolation of Windows Containers MicroVMs. |
Beta Was this translation helpful? Give feedback.
-
|
That, or we use X over tcp for now and wait for MS to release the Gui Apps via wsl which is on the roadmap. Because i think your right, Patching WSL2 to work on the standard Hyper-V stack would break isolation for windows containers. |
Beta Was this translation helpful? Give feedback.
-
|
I just learned today (from here) that WSL2-supporting Windows should also support Unix Domain Sockets (
If this also works for WSL2 micro VMs (which may be true for the same reason that that It's also possible that it won't work without doing some specific setup for the WSL2 microVM which we don't have control over anyway. I haven't followed up to confirm this discovery with any other documentation, but if that turns out to be a reasonable workaround, it would simplify a bunch of stuff. And poking around, #4240 (comment) suggests this either doesn't, or didn't work for WSL2. Edit: I did find documentation about how Windows/WSL Interop with AF_UNIX used to work, at least. |
Beta Was this translation helpful? Give feedback.
-
|
Someone has come up with an implementation that listens on the WSL2 micro VM's GUID that seems to work quite well: https://github.com/nbdd0121/x11-over-vsock Given that official GUI support is coming in the near future in WSL, this is probably a good enough workaround to avoid the sleep/resume disconnects until then. |
Beta Was this translation helpful? Give feedback.
-
|
That's a neat solution. Note that the Linux-side of that is pretty much the same thing done with The fact that daemon mode needs to be run with administrator privilege might be one reason X410 haven't implemented it. |
Beta Was this translation helpful? Give feedback.
-
Please fill out the below information:
Your Windows build number: Microsoft Windows [Version 10.0.19033.1]
What you're doing and what's happening:
Follow steps at https://token2shell.com/howto/x410/quick-testing-vsock-hyper-v-support-in-x410/ to add registry keys and launch X410 with vsock support.
In either Gentoo or Ubuntu 18.04 on WSL2:
$ socat -b65536 UNIX-LISTEN:/tmp/.X11-unix/X5,fork,mode=777 SOCKET-CONNECT:40:0:x0000x70170000x02000000x00000000 &
$ export DISPLAY=:5.0
$ xterm
$ xterm
2019/12/01 08:45:21 socat[334] E connect(5, AF=40 AF=40 0x0000701700000200000000000000, 16): Connection timed out
xterm: Xt error: Can't open display: :5.0
$ dmesg
[ 80.407004] ------------[ cut here ]------------
[ 80.407005] unknown msgtype=23
[ 80.407021] WARNING: CPU: 2 PID: 0 at drivers/hv/vmbus_drv.c:909 vmbus_on_msg_dpc+0xff/0x1c0
[ 80.407022] Modules linked in:
[ 80.407024] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.84-microsoft-standard #1
[ 80.407025] RIP: 0010:vmbus_on_msg_dpc+0xff/0x1c0
[ 80.407026] Code: 00 83 fe 15 0f 86 5d ff ff ff 80 3d 3c 24 d9 00 00 0f 85 72 ff ff ff 48 c7 c7 85 93 22 82 c6 05 28 24 d9 00 01 e8 7b 7b 8b ff <0f> 0b e9 58 ff ff ff 48 8b 3d eb c9 aa 00 ba 20 01 00 00 be 20 00
[ 80.407027] RSP: 0018:ffff888321c83f28 EFLAGS: 00010282
[ 80.407027] RAX: 0000000000000000 RBX: ffff888321eb2000 RCX: ffffffff82434ec8
[ 80.407028] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000247
[ 80.407028] RBP: 0000000000000000 R08: 0000000000000024 R09: 0000000000000001
[ 80.407028] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001
[ 80.407029] R13: ffff888321eb2210 R14: 0000000000000040 R15: 0000000000000006
[ 80.407030] FS: 0000000000000000(0000) GS:ffff888321c80000(0000) knlGS:0000000000000000
[ 80.407030] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 80.407030] CR2: 000055c11e3c7408 CR3: 000000000240a003 CR4: 00000000003606a0
[ 80.407032] Call Trace:
[ 80.407034]
[ 80.407038] tasklet_action_common.isra.21+0x5a/0x100
[ 80.407045] __do_softirq+0xde/0x2de
[ 80.407046] irq_exit+0xba/0xc0
[ 80.407047] hyperv_vector_handler+0x57/0x70
[ 80.407049] hyperv_callback_vector+0xf/0x20
[ 80.407049]
[ 80.407050] RIP: 0010:native_safe_halt+0xe/0x10
[ 80.407051] Code: 1f 44 00 00 e9 c5 fe ff ff 0f 0b eb 94 0f 0b e9 04 ff ff ff 90 90 90 90 90 90 90 90 e9 07 00 00 00 0f 00 2d 14 9e 5c 00 fb f4 90 e9 07 00 00 00 0f 00 2d 04 9e 5c 00 f4 c3 90 90 0f 1f 44 00
[ 80.407051] RSP: 0018:ffffc90000093ec8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff0c
[ 80.407052] RAX: ffffffff81a3ca30 RBX: 0000000000000002 RCX: ffffffff82436290
[ 80.407053] RDX: 0000000000008782 RSI: ffffffff82433ef8 RDI: 0000000000000082
[ 80.407053] RBP: 0000000000000002 R08: 0000000000000002 R09: 00000012b971d6c2
[ 80.407054] R10: 0000001e1b9929f6 R11: 0000000000000000 R12: ffff888107e33800
[ 80.407054] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 80.407055] ? __cpuidle_text_start+0x8/0x8
[ 80.407057] default_idle+0x1c/0x140
[ 80.407058] do_idle+0xe5/0x110
[ 80.407060] cpu_startup_entry+0x6f/0x80
[ 80.407061] start_secondary+0x195/0x1d0
[ 80.407062] secondary_startup_64+0xa4/0xb0
[ 80.407064] ---[ end trace ecf9bcf6815fbd08 ]---
Beta Was this translation helpful? Give feedback.
All reactions