11

Is there an easy way of running an X11 application on a KVM guest system the way that it is displayed on the host system?

I know I can ssh to a guest with X11 forwarding, but I am wondering if there is a native KVM/libvirt approach or just something simpler.

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
Mike
  • 211

2 Answers2

7

SSH's X11 forwarding is a bit more than generic port forwarding, and it probably is the simplest way to achieve what you want, at least from the user's viewpoint.

If you want technically simpler, you'll need to understand how X11 was originally envisioned to be used.

In an environment with a number of X11-capable computers, the user information might be centrally managed with NIS and home directories shared from a dedicated disk server to all the other computers with NFS (with a bit of automounter thrown in). All the computers would also have to be able to resolve each other's hostnames. In a trusted internal network, you (it was assumed) would not disable the TCP listening port of your X11 server.

In such an environment, you could connect from one host to another, and only need to make sure the DISPLAY environment variable was set properly to have any remote X11 client program make a direct connection to your local X11 server, and thus, to your local display. Since the home directories are shared with NFS, the same ~/.Xauthority would be seen by both the remote and the local host.

If there was no NIS? That is not a problem for X11: it does not really care about identity. As long as any client connecting to the X11 server can present the correct X11 authentication cookie from the ~/.Xauthority file (or a non-default file pointed to by the XAUTHORITY environment variable), X11 would work. However, without shared UID/GID number assignments, sharing the home directories might not be possible.

Without a shared home directory? In that case, you would also need to pass the X11 authentication cookie, typically by extracting it on your display host with e.g. xauth nextract /some/file :0.0, then getting the contents of /some/file transferred to the remote host using whatever method, and using xauth nmerge there to add it in the remote host's ~/.Xauthority file.

(Or you could use xhost + to disable the security check, either entirely or for specific remote host only. But that turned out to be a very bad idea: if the remote host had other users, doing that opened you up for getting xsnowed in, or for an xroach infestation, or worse things like getting all your keyboard and mouse events for you entire X11 session monitored.)

But the unencrypted X11 protocol was found to be a pretty big security weakness. Because of what the USA's crypto export laws were at the time, the world settled on using SSH with X11 forwarding and disabling the TCP port of the X11 server. It became the norm to see the X server started as Xorg -nolisten tcp <other options...>.

Fairly recently the X.org has recognized this and flipped the TCP listening logic: if your Linux distribution starts an X11 server without the -nolisten tcp option by default, it might be because your X11 server version actually requires an explicit -listen tcp option to enable the classic and insecure X11 TCP listener.

So... yes, you could:

  • enable the TCP listener on your host's X11 server
  • make sure your VM can resolve the host's IP address and connect to host's port 6000 (= corresponds to DISPLAY :0.0 over TCP)
  • arrange for your VM to have the DISPLAY variable point to kvmhost:0.0
  • take the necessary steps to get the X11 authentication cookie passed to the VM

That would allow X11 to work the "classic way", with minimal added technical complexity. But it's quite a lot more complicated to actually set up than just using ssh -X virtualmachine, and may open you up for various old, well-known attacks.

telcoM
  • 96,466
0

you can do it with a simple tap device tricj


-netdev tap,id=mynet0,ifname=qtap0,script=no,downscript=no -device e1000,netdev=mynet0,mac=fe:ed:be:ef:55:66

after installing some x-compatible binaries in vm, you can remotely start them over ssh :

xhost +10.11.12.10 ;ssh -p 6666 user@127.0.0.1 "LANG=de BROWSER=chromium-browser DISPLAY=10.11.12.11:0.0 dbus-run-session chromium-browser"

→ be careful , full hd youtube will eat 1.2+Gbit bandwith