Hyper-V virtual machines have their own independent isolated network, and they see Windows host as a separate system even though they all are running in the same computer. Hence, you need to take that into account when setting up your DISPLAY environment variable for X-Window GUI apps. The following connection methods are supported in X410 for Hyper-V virtual machines.
TCP
As Hyper-V virtual machines see their Windows host as a separate system, you normally need to specifically allow TCP public access for X410 in Windows Defender Firewall. However, starting from version 3.0.0, X410 is automatically added to the Windows Defender Firewall for full TCP public access while its installation.
When you allow such full public access, any external computer can connect to X410 using TCP connections. But, X410 has a built-in feature for permitting TCP connections only from the Hyper-V virtual machines that are configured to use the 'Default Switch'.
For your information, when you install Hyper-V, it initially creates a virtual network switch called 'Default Switch' that only allows internal networking among virtual machines and Windows host. Hyper-V also supports creating other types of virtual network switches, but X410 only targets the 'Default Switch' as it's automatically selected when you create a Hyper-V virtual machine, and it doesn't expose the virtual machine to external systems.
Before setting up the DISPLAY environment variable, you first need to enable option under » » . You can also just enable 'Allow full public access' option, but when you enable that full access option, you're also allowing other programs running in any computer to connect to X410. If you just want to run X-Window GUI programs in Hyper-V virtual machines, you should just enable the Hyper-V option in X410 for security reasons.
Extract an IP from 'ip route' Linux command
If the Linux/Unix distro you installed on your Hyper-V virtual machine has the 'ip' command, you can use its 'route' command-line switch to get the IP address for Windows host. The IP address for Windows host is reported as a default gateway in 'ip route' command and you can use that output for setting up the DISPLAY environment variable:
export DISPLAY=$(ip route | grep default | awk '{print $3; exit;}'):0.0Enable 'Allow full public access'
If you have created additional virtual network switches for Hyper-V and using them for your virtual machines, you need to figure out a way to extract or assign an address that can be used for connecting back to X410 from those virtual machines and use it for the DISPLAY environment variable. For example, you can try using the computer name for your Windows as an address (you can also try appending '.local' to the name).
export DISPLAY=<computer_name>:0.0As mentioned above, when you enable 'Allow full public access' option, you're also allowing other programs running in any computer to connect to X410. Hence, if you decide to use this option, you should also configure Windows firewall and protect your computer.
VSOCK
X410 also supports using VSOCK for connecting back to Windows host from Hyper-V virtual machines. If you're having problems while using the TCP method described above (ex. X410 connections are severed or hanged after your computer is coming back from Windows sleep mode, Linux GUI apps are terminated when your Wi-Fi is switched to a different access point or network, Linux GUI apps become unresponsive after VPN is activated or turned off, or etc.), try using the VSOCK method described below.
As VSOCK is based on a different communication mechanism that focuses on directly connecting virtual machines and their host, you should get much stable experience that doesn't affected by the TCP/IP network changes in your Windows. You can also completely avoid the hassles of setting up the firewall.
Please note that unlike WSL2, you also need to add Windows registry entries as described in the following post.
Adding entries to Windows registry for VSOCK connections in Hyper-V virtual machinesUse socat for relaying X-Window data
X-Window client programs don't natively support connecting to an X-Window server via VSOCK. Hence, you need to use a relay background program that accepts data from your X-Window client programs and forwards them to X410 and vice versa.
You can use a popular utility program called 'socat' for the relaying data purpose. It should already be included in most software package systems such as apt. For example, the following command installs socat in Ubuntu:
sudo apt install socatOnce socat is installed, you can check its version by using its '-V' command-line switch:
$ socat -V
socat by Gerhard Rieger and contributors - see www.dest-unreach.org
socat version 1.7.4.1 on Feb 4 2021 12:53:19
running on Linux version #29-Ubuntu SMP Wed Jan 12 17:36:47 UTC 2022, release 5.13.0-27-generic, machine x86_64
features:
#define WITH_STDIO 1
...
#define WITH_VSOCK 1
#define WITH_PROXY 1
...
If you're using socat version 1.7.4.0 or higher, it already natively supports VSOCK and you simply need to use the following format for connecting to X410:
VSOCK-CONNECT:<cid>:<port><cid> should be '2' that points to your Windows host (VMADDR_CID_HOST) and <port> should be '6000 + <display_number>' (if you configured X410 to be a display number '0', it should be '6000'. For display number '1', it becomes '6001' and so forth). If you assigned '0' for the display number of X410 (this is the default display number when you install and start X410), you can execute socat as the following:
socat -b65536 UNIX-LISTEN:/tmp/.X11-unix/X0,fork,mode=777 VSOCK-CONNECT:2:6000 &Once socat is properly executed, you should notice the 'X0' file in the '/tmp/.X11-unix' directory as indicated in the above example. That Unix socket file is used for accepting connections from X-Window client apps.
You should then set the DISPLAY environment variable to ':0.0'.
export DISPLAY=:0.0If you're using an earlier version of socat that doesn't natively support VSOCK, you can still use it for the VSOCK data relay. The following socat command is equivalent to the VSOCK example shown above:
socat -b65536 UNIX-LISTEN:/tmp/.X11-unix/X0,fork,mode=777 SOCKET-CONNECT:40:0:x0000x70170000x02000000x00000000 &Modify XCB (X protocol C-language Binding) library source codes
If you don't want to use any intermediate data relay program and have your X-Window client apps directly connect to X410 via VSOCK, you can try directly modifying XCB library source codes.
XCB library is commonly used in X-Window client programs for connecting to an X-Window server; XCB library is the one that actually decodes the DISPLAY environment variable and makes connections to the server.
You can find more information about replacing your existing XCB library with a modified version in the following post.
Transparently adding native support for VSOCK in X11 apps (patching libxcb)Once you have the modified version in your Linux/Unix distro, you can simply use the following DISPLAY environment variable and have your X-Window client apps directly connect to X410 without using any background data relay program:
export DISPLAY=vsock/:0Please note that if your program has its own routines for decoding the DISLAY environment variable, the modifying XCB library method shown above will not work. For example, if you enable the X11 forwarding feature in an OpenSSH client, you will get an error message similar to the following:
vsock/: unknown host. (Name or service not known) Error: Can't open display: localhost:10.0
OpenSSH has built-in codes for decoding the DISPLAY environment variable, and it obviously doesn't recognize the vsock/ method since it's not in an official X-Window specifications.
In such cases, you need to use an intermediate data relay program like the ones shown in Option 1. But, fortunately, Windows 10 and later has a built-in SSH client that is a port of OpenSSH client. Hence you can instead use that SSH client from Windows when you need X11 forwarding. Using the built-in SSH client for X11 forwarding should actually give you better performance as it connects directly to X410; they're both natively running in Windows and there is no need for any virtual machine network traffic conversion.
For more information about using X11 forwarding with the built-in SSH client in Windows and X410, please read the following post:
Built-in SSH X11 forwarding in PowerShell or Windows Command Prompt