Since back in December, I have a ‘Headless’ HP Z440 workstation under my desk with lots of RAM, storage and an Nvidia graphics card to run virtual machines and compute intensive stuff there instead of on my notebook. This works very well in practice and I use X over SSH a lot with virtual machines on the Workstation. There is one application, however, that doesn’t work very well this way: The Virtualbox management GUI. For some reason, the window doesn’t render correctly, and while it is usable, it’s a pain. One way to fix the problem would be to run the Virtualbox GUI on the display of the Z440 and then use VNC to access the screen. However, since I use the Z440 without a screen attached, this does not work, as no real display buffer is created during startup if no screen is attached. A few days ago I came across a “Display Port Dummy” adapter, and I immediately knew that this would fix my problem.
The HDMI / Display Port dummy dongle simulates a real display by responding to information requests of the graphics card the way a physical display would do. As a result, the display buffer is initialized by the operating system and the output is generated on the HDMI or display port, but is, of course, just terminated in the dongle. With this little trick I can get a remote VNC session working and hence I’m now able to use the VirtualBox GUI application in a much better way.
There’s only one thing that I needed to solve in addition: After startup, the display shows the login screen, which does not belong to a real user. Fortunately, the x11vnc server debug output contained a hint how to attach to the greeter and log in: To make it work an authentication token for the greeter x-session is required. This token is held by a special user and can be found in a sub-directory of ‘/run/user/xxx’, xxx being the user id of the ‘display manager’ user. Ubuntu 20.04 uses the Gnome Display Manger (gdm) login front end, so the x11vnc command that can be issued over ssh to connect to the screen looks as follows:
sudo x11vnc -localhost -auth /run/user/125/gdm/Xauthority -usepw -forever -repeat -display :0
In my case, the login user id was ‘125’. The command above starts the VNC server, and a VNC client such as Remmina can then be used to log-in as a normal user on the GUI. As soon as the user logs in, the VNC display goes dark, and one needs to restart x11vnc with the authentication credentials of the user that has logged in. The command looks pretty similar but the user ID in the authentication token path is different and the display number has changed:
x11vnc -localhost -auth /run/user/1000/gdm/Xauthority -usepw -forever -repeat -display :1
Also, note that I’ve used the ‘-localhost’ option, which means the Remmina VNC connection profile needs to be configured with an SSH tunnel for security. For testing purposes, x11vnc can be run without the ‘-localhost’ option and Remmina can just connect to remote TCP port 5900. That’s easy but not very secure.
A cool fix for less than 10 euros!
Libvirt works seamlessly with remote management. Setting up a remote virtualisation server is as simple as apt install libvirtd, and the client package is called virt-manager. I’m writing this because I too was using Virtualbox and spending a lot of time working around its limitations before I’ve found libvirt.
Sorry about the unsolicited advice if you’re using Virtualbox by concious choice.