KVM/Qemu VMs with a multi-screen Spice console – V – remote access via remote-viewer, a network port and a SSH-tunnel

Posted on 7. April 2021 by eremo

I continue my article series about methods to access the Spice console of a KVM/Qemu based VM. Spice clients – as e.g. remote-viewer and virt-viewer – enable local or a remote users to work on the graphical desktops of a VM.

KVM/Qemu VMs with a multi-screen Spice console – IV – remote access via SSH, remote-viewer and a Unix socket
KVM/Qemu VMs with a multi-screen Spice console – III – local access with remote-viewer via a Unix socket
KVM/Qemu VMs with a multi-screen Spice console – II – local access with remote-viewer via a network port
KVM/Qemu VMs with a multi-screen Spice console – I – Overview over local and remote access methods

In my last article I used a local socket based connection of remote-viewer to the Spice console of a VM on the KVM/Qemu host. I just added SSH to achieve a kind of elementary network capability: I transferred the graphical output of remote-viewer running on the KVM host via SSH to the X11-service of a remote client-system located somewhere in a LAN. With some additional SSH-tricks for audio data I got a well working, secure and surprisingly responsive solution for a remote desktop of a VM.

However, without data compression, such an approach consumes a considerable part of the LAN-bandwidth as soon as reactions of the VM’s window manager to fast window movements are requested on the remote SSH client: For a “virtio” video device of the VM we measured up to 45 MiB/s. SSH data compression helped to bring data transfer rates below 9 MiB/s. Unfortunately, the gzip based compression of SSH led to some reduction in responsiveness when I moved windows fast and irregularly across the VM’s desktop surface.

But when I worked with figures and operations of graphical applications (like Libreoffice Draw) within the “ssh -X” based display of the VM’s Spice console screens on my remote client, I found much, much smaller data transfer rates. These rates were even significantly smaller than the rates required for a direct “ssh -X” connection to the VM for the display of the chosen applications’s graphical output on our remote X11-service. So, even my simple scenario for the remote display of the VM’s whole desktop via “local Spice” and “ssh -X” offers a remarkable advantage in comparison to a pure “ssh -X” access to graphical applications of a VM.

With this article we now turn to “real” remote configurations. “Real” refers to the fact that both remote-viewer and virt-viewer are parts of a client/server architecture for the Spice protocol: This time we are going to run remote-viewer on the remote system.

This in turn means that we have to establish a network connection from the remote client-system to a (dedicated) TCP network port on the KVM-server to access the Qemu-hypervisor process for a specific VM. Graphical desktop data are then transferred between the Qemu-hypervisor on the KVM-server and the remote client via the Spice TCP protocol. This is much closer to the original intentions of the Spice developers than what I did in my last article.

But: As SSH allows for port-forwarding we can, of course, easily combine this kind of real remote client/server approach for Spice with SSH encryption. Thus we have two subjects
to cover in this article:

Method A: We access the Spice console of a VM by using remote-viewer on a remote client-system and interact with the VM via an unencrypted TCP connection to a specific network port on the KVM/Qemu-server.
Method B: We access the Spice console of a VM by using remote-viewer on the remote system but transfer encrypted data between the client and the KVM-server through a SSH-tunnel with port-forwarding.

Note that both approaches should already cover the transfer of audio data along with the video data without any additional measures – provided that Pulseaudio is running on the client-system. Remember what we saw already in the 2nd article of this series: remote-viewer opens multiple data transfer channels – one of it is intended for audio data.

As in the last article we will measure data transfer rates and consider the felt responsiveness of the solutions. In addition we are now able to apply (native) data compression methods within the Spice protocol and compare the results with the gzip compression offered by SSH.

Schematic drawing

Both methods for our remote scenario are displayed in the following drawing:

The main difference in comparison to the sketch in my last article is: The remote-viewer application is now started on the remote client-system and not on the KVM-server. The remote system is in my case a laptop “MyLAP”; I also speak of it as the (remote) client.

Spice configuration

In one of the previous articles I have already discussed the Spice configuration settings in a (libvirt) XML definition file for our test-VM “debianx”:

     <graphics type='spice' port='20001' autoport='no' listen='0.0.0.0' keymap='de' defaultMode='insecure'>
      <listen type='address' address='0.0.0.0'/>
      <image compression='off'/>
      <gl enable='no'/>
    </graphics>
    <sound model='ich6'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </sound>i
    <video>
      <model type='virtio' heads='2' primary='yes'>
        <acceleration accel3d='yes'/>
      </model>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>

We define a specific TCP port (20001) to be used for our test-VM. (Another additional VM on the KVM host would require the definition of another port). The “defaultMode“, by which we control whether TLS security measures are required to start the VM, is set to “insecure”; i.e. we neglect TLS encryption for the time being. Note also that I use a “virtio” video device. We made good experiences with it during our last experiments. If the virtio device should not work on your systems replace it by some reasonable QXL configuration.

The HW graphics “acceleration” can be set to “yes” for the “virtio” device. HW acceleration will, however, not be used as long as Spice has the setting “<gl enable=no>”. [You may try change this – good luck then with Nvidia cards and their proprietary drivers (it won’t work). I will not cover HW acceleration of the virtual graphics in this series.]

Note that I did not set a password to block other users from accessing the Spice console. So, anybody in our Intranet can take over an already opened Spice session – without any authentication. That
is one of the reasons why we shall invoke SSH again in a few minutes.

A first test

We open local and router based firewalls in our (segmented) LAN for the communication of the client-system with the virtualization server over port 20001. On the KVM-server “MySRV” a privileged user “uvma” starts our already familiar test-VM “debianx” (in my case with a Kali OS on it) via virt-manager. Just for control purposes user “uvma” opens the Spice console on the server with a local remote-viewer instance (with 2 screens), logs in into the VM and starts a VM desktop session:

Then I log myself in into the Linux client “MyLAP” as user “myself” and start remote-viewer there:

myself@mylap:~> remote-viewer spice://mysrv:20001 &

The expected result is that the Spice console session is closed on the (KDE) desktop session of “uvma” on MySRV. Instead Spice console windows are opened in the (KDE) desktop session of “myself” on “MyLAP” – displaying again the desktop of the VM:

(I adjusted the Spice window positions a bit).

The necessity of some security measures is obvious: The opened network port on the KVM server could in principle be accessed by anybody in the LAN. Even if we restricted access by some firewall rules to the MyLAP-client any of its users could hijack the Spice console session. Furthermore: No authentication is required; the person having accessed the Spice console can work freely on the VM with the rights of the user who was actively using the desktop on the VM before. And the data exchange between MyLAP and MySRV occurs unencrypted.

Before we take care of encryption and other security measures, let us compare the present data transfer rates with the rates seen in the experiment of my last blog post.

Data transfer rates without compression

In my last article we put some pressure on the window-manager of the VM by moving a window bigger than 800×800 px with complex content fast and irregularly across the surface of the VM’s desktop. We got data exchange rates between the remote client and the KVM-server beyond 80 MiB/s for a QXL device; for a “virtio” video device the pak rates were close to 45 MiB/s.

In my present remote scenario I observe the following rates for data sent from MySRV to MyLAP:

Hmmm …, rates of up to 70 MiB/s are not at all convincing. The responsiveness is excellent again: Application windows follow the erratic mouse movements across the desktop very quickly and with a completely negligible delay.

So far the client/server approach with remote-viewer does not offer us any advantage over our primitive “ssh -X” scenario for the transfer of graphical data from a local Spice client on the KVM-server to the X11-server on a remote system.

Transfer rates with activated Spice data compression

The Spice settings include an option <image compression=’….’/>.
In the experiments of last posts we could not use this option; virt-manager (libvirtd) would not start a VM
that provides a Spice console via a local pure Unix socket in combination with data compression. Obviously, such a combination was and is regarded useless by the Spice developers.

But now, as we work with a network port, we are allowed to define a method for the compression of Spice data. You find valid values for compression methods at https://libvirt.org/formatdomain.html#video-devices.

For our next test we use

 <graphics type='spice' port='20001' autoport='no' listen='0.0.0.0' keymap='de' defaultMode='insecure'>
      <listen type='address' address='0.0.0.0'/>
      <image compression='auto_glz'/>
      <gl enable='no'/>
    </graphics>

We get

The resulting data transfer rates are below 9 MiB/s. (Your rates may deviate a bit due to a different number of Spice screens, different Spice screen dimensions, different window dimensions and window content. With 2 Spice screens of 1920×1200 px and a FF window of 1200×800 px I get up to 12 MiB/s).
These values are comparable with the rates found for SSH data compression in the last article’s experiment. However, there is a major difference:

The responsiveness remains really excellent – despite data compression!

This is a first good argument for using remote-viewer in the manner it was originally designed for – namely as a remote tool!
But we have no encryption, yet ….

What about sound?

Remote-viewer should support the local Pulseaudio [PA] server on the client system without any further measures . And it indeed does so:

The picture above shows that PA (on MyLAP) has recognized the locally started remote-viewer there as a valid audio source – and we can play any sound with any player of the VM. So, getting sound with remote-viewer running on the remote client is considerably easier than fiddling around with the PA and SSH tricks we had to apply in the basic “ssh -X” scenario.

Data transfer rates for LO Draw (with Spice data compression)

As in my last article we also open a LO Draw sheet to test data transfer rates for a graphical application used within the VM’s desktop:

The measured data transfer rates whilst moving colored transparent figures fast across the LO sheet of LO Draw are excellent – namely on average below 500 KiB/s:

The rate depends a bit on the size of a moved element. Regarding the felt responsiveness: It is really comparable to working on a local application – you do not feel that you are working on a VM on some server over a LAN connection.

Add encryption via SHH and port forwarding

Now, let us add SSH encryption. On the remote
client-system “MyLAP” we open a terminal window and enter:

myself@mylap:~> ssh -N -f -L 31001:localhost:20001 -i ~/.ssh/id_rsa_x uvmb@mysrv
Enter passphrase for key '/home/myself/.ssh/id_rsa_x': 
myself@mylap:~> remote-viewer spice://localhost:31001 &

By “-N” we just signal that we do not want to get an interactive shell, and by “-f” we fork the SSH process into the background. In addition we redirect data traffic targeted for the arbitrarily chosen port 31001 on MyLAP to port 20001 on MySRV through an encryption tunnel. (Control question: What system does “localhost” in the SSH statement refer to?)

And there we go again:

And the data transfer rates as well as the responsiveness remain excellent as before; here the rates for moving a FF window quickly across a Spice screen of 1920×1200 px:

And here for quickly moving figures around a full screen LO Draw sheet:

Hints for improving security

We have established a SSH tunnel for encrypted data transfer between our systems. But this is not enough regarding security as anybody having SSH access to the KVM host can still hijack an open Spice console session in an uncontrolled way. What can we do to improve security? In particular, we have to restrict the access to the VM’s Spice console to specific users. The first measure to achieve this is to close the network port defined for Spice again on the KVM-host for remote access. We do not need it to be accessible from external locations as we use a SSH tunnel anyway. And then there is a cascade of additional things you can do with SSH:

You create a special user on the KVM-server – but set his login-shell to “/bin/false” or “/sbin/nologin”. Thus he/she cannot work interactively with a shell on the KVM-server. But port-forwarding would still be possible for him/her …
You allow SSH connections for this user from a special IP address, only, and via public key authentication, only. (You must configure the SSH service on the KVM host accordingly). Then you create the required key pair for this user and place the public key into the file “~/.ssh/authorized_keys” on the KVM/Qemu server.
You confine the actions of this special user even more by adding port-forwarding restrictions to his/her file for public keys “~.ssh/authorized_keys”.
You restrict the allowed actions of this special user in addition by a “Match user”-section in the sshd_config-file on the KVM-server.

The required restriction would be the dis-allowance for any port-forwarding with the exception of the defined Spice port for the VM. In addition you also disable X11-forwarding and SSH Gateway ports. Then you block port-forwarding to the VM’s Spice port for all other SSH users (with the exception of an administrator account, maybe).
For more information see the SSH documentation of your distribution and e.g. :
https:/
/askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for-port-forwarding
https://blog.tinned-software.net/restrict-ssh-access-to-port-forwarding-to-one-specific-port/

And last – but not least – you, of course, set a password in the Spice configuration. We have covered this topic already in a previous article.

Conclusion

Remote-viewer used on a remote client-system without any data compression requires almost the same data transfer rates as a solution based on the transfer of graphical data via “ssh -X” from remote-viewer running on the KVM-server to a remote X11-service. However, remote-viewer run as a real Spice client tool on a remote system has one big advantage over a scenario based on a pure “ssh -X” solution:
The compression methods integrated with the Spice protocol have almost no negative impact on the responsiveness of the VM’s desktop displayed in the remote Spice windows!
For a standard compression setting we get a substantial reduction of data transfer rates combined with an almost optimal responsiveness of the remote desktop. We can work with graphical applications within the desktop of a VM on remote Spice windows as if we were using a local application. Required rates for LO Draw are in the range of 0.5 MiB/s, only.
To get a secure configuration we can at any time sent the Spice data through an encryption tunnel established via SSH and port-forwarding. This had no negative effect on responsiveness. Additional restrictive user-specific configurations of SSH for port-forwarding offer a solid basis for the creation of a reasonably secure Spice solution.

Conclusion: The combination of remote-viewer on remote systems with Spice data compression and a SSH-tunnel offers users who can live with a “one seat” remote scenario an almost optimal solution for working with graphical applications of a VM within a remote desktop. Regarding data transfer rates this is much better than using “ssh- X” directly for the application (without the desktop environment).

In the next article we prepare our systems for a TLS encrypted connection instead of a SSH-tunnel.

KVM/Qemu VMs with a multi-screen Spice console – IV – remote access via SSH, remote-viewer and a Unix socket

Posted on 2. April 2021 by eremo

I continue with my series on methods to access the graphical Spice console of virtual machines [VM] based on the KVM/Qemu-hypervisor combination on a Linux host.

KVM/Qemu VMs with a multi-screen Spice console – III – local access with remote-viewer via a Unix socket
KVM/Qemu VMs with a multi-screen Spice console – II – local access with remote-viewer via a network port
KVM/Qemu VMs with a multi-screen Spice console – I – Overview over local and remote access methods

In the last article we saw that “remote-viewer” can be used locally on the KVM-host to directly access the Qemu-emulator of a specific VM via a Unix socket instead of a network port. Its a simple and fairly effective method – though not well documented. We confined the right to access the socket for a VM to a specific group of users.

Actually, the socket based access method also provides the basis for a simple remote scenario in an Intranet – namely via ssh -X. This is the topic of this article.

Such a method requires relatively high data transfer rates across the network – but in a switched Gigabit LAN the rates are within reasonable limits …. And despite a lack of OpenGL HW acceleration Spice reacts very responsively to mouse operations and window movements. In the course of our experiments I will also introduce another virtual “video” device model which can be used together with our VM – namely a “virtio” device with multiple heads. As the QXL device it corresponds to a kind of virtual graphics card.

I assume that the reader is familiar with SSH and the setup of the SSH-service on a Linux system. Some knowledge about Pulseaudio is helpful, too.

Why do we care about remote Spice scenarios in an Intranet?

Why do I discuss remote scenarios for a “one seat” console of a VM in an Intranet at all? One answer is:

Any free-lance consultant or developer must think about a systematic way of how to organize data and work for customers in accordance with security requirements like the EU-GDP or the German DSGVO. Personally, I strongly recommend to confine the work and all data exchange processes for a selected customer to a specific VM on a well managed Linux server host. You then can encrypt the virtual disks and isolate the VM(s) pretty well by configuring both firewalls in the virtual network, on each VM as well as on the KVM-host and on routers in your LAN. Backup, recovery and machine extensions are easy to manage, too.
But you may need to access a VM’s desktop graphically from a client system (PC, laptop). This is were Spice comes into the game – at least in a Linux environment. Being able to work with a full fledged graphical desktop of a VM from different clients and locations in your LAN might be a basic requirement for preparing presentations, documents and maybe some development work in parallel on the VM.

I myself, for instance, often access the full desktop of server-based VMs from my Linux workstation or from a Linux laptop. Via SSH and the Spice console. We shall see below that the network data transfer rates for applications as Libreoffice Draw via SSH to the KVM host and using the Spice console can become smaller than in a situation where we open Libreoffice remotely by a direct “ssh -X” call to the VM itself. And the situation is even better in other scenarios we shall study in forthcoming articles.

In general it will be interesting to watch the objective data transfer rates plus the felt
responsiveness of Spice clients in remote scenarios throughout all our coming experiments.

Encryption requirements – the advantages of SSH

Even in the LAN/Intranet of a free-lancer or in a home-office with multiple users encryption for remote interactions with VMs may be required. We have two main options to achieve this for remote-viewer:

We use SSH on the remote system, connect to the KVM-host and start remote-viewer there.
We start remote-viewer on the remote system and encrypt the connection to the VM on the KVM host with TLS.

Both methods have their advantages and disadvantages. In the end usability on the remote system is an important criterion. A TLS setup will be discussed in a forthcoming post. Note that we also can use remote-viewers’ sister application “virt-viewer” in a SSH-based scenario – but this is a different story, too.

It is clear that using “ssh -X” is a simple approach which just uses the X11-protocol capabilities to realize a remote scenario. But it has some major advantages over other scenarios:

We get encryption almost for free. Most SSH implementations on Linux systems work out of the box.
We can enforce the use of secure Opensource encryption algorithms – both for the asymmetric KEX and authentication mechanisms and for the symmetric encryption parts of the data exchange. (See https://stribika.github.io/2015/01/04/secure-secure-shell.html)
We get user authentication based on a public key algorithm almost for free.
We can use a “ssh-agent” on the remote client to control the different authentication keys for different users allowed to access different VMs.
It is sufficient to open a SSH-port on the server. We do not need to open extra network ports for the Spice protocol.
We can get encrypted audio data transfer with some simple tricks in combination with Pulseaudio.

Therefore, it is really worthwhile to test a combination of “ssh -X” with starting remote-viewer on the KVM host. I shall, however, not discuss basics of SSH server and client configurations in this article. The preferred or enforced use of certain encryption algorithms for specific SSH connections is something a Linux user should be or become familiar with.

Regarding authentication I assume a standard configuration where private and public authentication keys are organized in the folders “~./ssh/” both for the involved user on the remote client system and the invoked user on the KVM/Qemu server host, respectively.

Schematic drawing

I have not yet depicted the SSH scenario with remote-viewer in any of my schematic drawings so far. The combination of remote-viewer with SSH is a variant of a local scenario as we open the “remote-viewer”-application on the KVM host [MySRV] and just transfer its graphical output via SSH to the X-Server of a remote Linux workstation [MyWS].

We do not care about the transfer of audio data during our first steps. We shall cover this problem in some minutes.

On the left side we see a Linux workstation from which a user logs into our KVM host as user “uvmb”. I assume that user “uvmb” has become a member of the special group “spicex” on the KVM host which we gave read/write access to the Spice UNIX socket created by Qemu (see my last post). On the right side we have our a KVM/Qemu server host. The user starts the remote-viewer application there (i.e. on the KVM
host), but gets its graphical output on his desktop on the remote workstation. On the KVM/Qemu host we, of course, use the fastest method for the remote-viewer application to exchange data with the Qemu-emulator process – namely via a Unix socket. See the definitions for the VM’s XML file (for libvirt applications) discussed in the last post:

    
    <graphics type='spice' autoport='no' keymap='de' defaultMode='insecure'>
      <listen type='socket' socket='/var/spicex/spice.socket'/>
      <image compression='off'/>
      <gl enable='no'/>
    </graphics>

This scenario may appear a bit strange for those among my readers who know that remote-viewer is a network client application: Remote-viewer is normally used on a remote client systems to connect to the Qemu process for a VM on a server host via TCP over a LAN. In our present scenario, however, we start remote-viewer on the server host itself and achieve network capabilities only by making use of SSH. But such a scenario sets comparison standards regarding data transfer rates. Any real client/server solution should provide advantages over such a simple approach. We come back to such comparisons in the forthcoming articles of this series.

An interesting question, for example, is whether the whole data exchange will resemble more a transfer of image data in the case of a full desktop presentation by remote-viewer or a transfer of X commands for constructing individual desktop contents. We should not forget that Spice and remote-viewer have their own handling of graphical data and a special client-server model for it.

A first disadvantage of our simple SSH-based scenario could result from the following fact:

Spice does not accept an activation for the compression of image data for a local socket-based configuration. As we start remote-viewer in our scenario on the KVM host we, therefore, cannot use the image-compression option for the Spice configuration. If a reduction of data transfer rates is required due to a limited LAN bandwidth our only chance is to use data compression for SSH. SSH uses gzip; due to extra CPU activities on both sides using compression may reduce the performance of application which exchange many data between the SSH client and server during user interactions.

In my test setup the KVM-host is controlled by an Opensuse Leap 15.2 OS, whereas the remote client system – a laptop (MyLAP) – runs Opensuse Leap 15.1. (Yes, I should have upgraded it already …).

Requirements for a reasonable performance of remote scenarios with SSH, remote-viewer and Spice

“ssh -X” is not the most efficient way of transferring graphical data. The performance experience depends a bit on the symmetric encryption algorithm and very much on the bandwidth of your network. To make a long story short:

For the QXL device temporary peaks of the data transfer rate can reach 60 MiB/s to 90 MiB/s for some window operations on a Spice console. Such rates may e.g. occur appear when you move complex and large windows quickly around with the mouse on the displayed VM’s desktop – with transparency effects of a XRender compositor being active. With the “virtio” graphics device we reach a rate of around and below 40 MBit/s.

Such rates may seem quite high – and they indeed are. But a quick test shows that you reach 25 – 45 MiB/sec already when quickly moving around a complex transparent pattern within a “Libreoffice Draw” sketch remotely over a network connection with SSH. The presentation of transparent windows within a KDE desktop with compositor dependent effects is far more complex. So Gigabit NICs are required.

If your network becomes a limiting factor you can use the “-C”-option of SSH to enable data compression. This may give you a factor between 8 and 10 for the reduction of transfer data rates. In a test
case with remote-viewer I could reduce the data transfer rate below 8 MiB/s from something of 80 MiB/s without compression. This is an impressive reduction of data.

But there is a caveat of compression, too. The compression has to happen very (!) quickly for fast user interactions with the displayed VM-desktop in the Spice windows. So, you may get a delayed response now for some fast actions on the displayed desktop due to the compression overhead. Now you need pretty fast CPU cores on the KVM/Qemu host and the remote client system! Depending on your system and your LAN I would experiment a bit with and without compression.

A first test

I use a laptop with the hostname “MyLAP” with an Opensuse Leap 15.1 installation for a quick test. The VM (with a KALI 2020.4 OS) is located on a server host “MySRV” with Opensuse Leap 15.2 (see the last articles of this series for its configuration).

On the laptop I start a KDE session as user “myself”. We have a SSH authentication key pair prepared. Our (private) key resides in “~/.ssh/id_rsa_vm”. We have exported the public key to the KVM host into the “~/.ssh/”-directory of the user “uvmb” there (probably “/home/uvmb/.ssh/”). User “uvmb” is a member of the group who got “rw”-access by ACL rules on the KVM-server to the specific UNIX socket used by our test VM “debianx” (see the previous articles).

On the KVM host a privileged user “uvma” has already started the VM “debianx” (with a local socket configuration) for us. Just to be on the safe side we open a desktop session for user “uvmb” on the KVM/Qemu” server and test remote-viewer there:

All Ok here.

Now, we move to the laptop. There we open a KDE session, too, as user “myself”. In a terminal we start the ssh-session:

myself@mylap:~/.ssh> ssh -X -i ~/.ssh/id_rsa_x uvmb@mysrv
Enter passphrase for key '/home/myself/.ssh/id_rsa_x': 
Last login: Thu Mar 25 09:54:53 2021 from 192.168.2.22
Have a lot of fun...
uvmb@mysrv:~> 
uvmb@mysrv:~> remote-viewer spice+unix:///var/spicex/spice.socket &
[1] 5041
uvmb@mysrv:~> 
(remote-viewer:5041): GStreamer-WARNING **: 12:37:49.271: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though.

(remote-viewer:5041): GSpice-WARNING **: 12:37:49.409: Warning no automount-inhibiting implementation available

We ignore the warnings – and get our two Spice windows (on the KDE desktop of the laptop).

So far so good.

Let us move a complexly structured window (Firefox or the KDE settings window with a significant size (800×800)) around on the VM’s desktop in the Spice window of the laptop, with the help of fast mouse movements. Whilst we do this we measure the data transfer rates over the relevant NIC on the KVM server:

If you enlarge the picture you see peak rates of 85 MiB/s for data sent to the SSH-client.
In my network this has, fortunately, no major effect on the interaction between laptop and the VM – no major delay or lagging behind. And due to a fast switch my wife can nevertheless stream videos over a gateway system from the Internet. 🙂

How can we explain such transfer rates? Well, the window within the Spice screen I moved around had a size of around 800×800 px. Assume a 32 Bit color depth and a refresh rate of the pixel information on the virtual screen of around 30 times a second. You can do the calculation by yourself. The data fit well to the observations. Thus, we probably transfer changed image data of the window area on the VM’s desktop.

Reducing data transfer rates by SSH integrated (gzip) compression

We end the Spice session now on the laptop (by closing the Spice windows) and log out of the SSH session. Then we restart a new SSH-session with

<pre>myself@mylap:~/.ssh> ssh -XC -i ~/.ssh/id_rsa_x uvmb@mysrv
Enter passphrase for key '/home/myself/.ssh/id_rsa_x': 
Last login: Thu Mar 25 09:54:53 2021 from 192.168.2.22
Have a lot of fun...
uvmb@mysrv:~> 
uvmb@mysrv:~> remote-viewer spice+unix:///var/spicex/spice.socket &
[1] 5041
uvmb@mysrv:~>

Note the “C“-option for the ssh-command!
Now the measured transfer rates on the KVM-server are less than 9 MiB/s.

However, I notice some lagging of the moved windows reaction to quick mouse cursor changes on the remote client. Not, that it affects normal working – but palpable. I cross checked by working with complex figures within Libreoffice Draw – absolutely no problems with the performance there. So, the reduced responsiveness is mainly due to operations which trigger the VM’s window manager and the re-drawing of the windows as well as the desktop within the Spice induced X-window on the client-system. In our case fast mouse movements to change the position of some application windows on the displayed VM desktop quickly and erratically ….

I see the lagging also with the Gnome desktop of the Kali guest – especially, when moving transparent terminal windows. In my opinion the lagging is even more pronounced. So, KDE 5 is not so bad after all 🙂 . And then its time for optimizing via desktop settings. Remember that you can switch off a compositor totally for the KDE desktop.

I also found that the decline of responsiveness with SSH data compression also depended somewhat on the number of opened Spice “displays” or “screens” and their sizes. Responsiveness is better with just one Spice window open on the remote system. In our SSH-based scenario responsiveness depends

on the number of virtual Spice displays,
on the size of the moved window,
on the complexity and to a minor degree also on transparency effects.

I could also see these dependencies for a “ssh -XC” when I exchanged the QXL device with a so called “virtio”-video-device.

Using a “virtio” video device

So far we have worked with the QXL device for a virtual graphics card device in the VM’s configuration. Let us try an alternative – namely a so called “virtio”-video-device. “virtio”-devices for virtual NICs and virtual storage devices enhance performance due to special interaction concepts with the real hardware; see the links at the bottom of this post for more information on the ideas behind virtio-drivers. Can we get a performance improvement in our scenario by a “virtio” device for the virtual graphics card?

Our configuration for the VM then, for example, looks like

   <graphics 
type='spice' keymap='de' defaultMode='insecure'>
      <listen type='socket' socket='/var/spicex/spice.socket'/>
      <image compression='off'/>
      <gl enable='no'/>
    </graphics>
    ...
    ...
    <video>
      <model type='virtio' heads='2' primary='yes'>
        <acceleration accel3d='yes'/>
      </model>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    ...

You see that we can set multiple heads for a virtio video device, too. A big advantage is that we do not need any special memory settings as for the QXL device.

When you try this setting, you will found out that it works quite well, too. And there is a remarkable difference regarding data transfer rates:

The maximum rates for the same kind of window movements are now well below 48 MiB/s. For the same kind of fast movements of complex windows across the desktop surface in the Spice window.

Now, if you in addition use SSH compression (ssh -XC) you get the rates down to 8.2 MiB/s – but with only a slightly better responsiveness of windows to the mouse movement on the remote Spice window than for a QXL setup.

In my opinion a virtio-display device is something worth to experiment with (even without 3D acceleration).

Libreoffice Draw as a real world test case

Let us briefly compare data rates for something more realistic in daily work.

In the tests described below I firstly open Libreoffice [LO] Draw by a direct “ssh -X” call to the VM itself. Then I open LO Draw within the remotely displayed desktop of the VM based on a “SSH -X” connection to the KVM server. This means a major difference regarding the SSH connection and the data transfer requests!

Within LO Draw I use a sketch like the following

and, later on, move the green or violet figures very fast around in the LO frame with the mouse. Transparency included.

So, for a first test, let us open the VM’s LO Draw on my laptop MyLAP via a direct “ssh -X” command (without data compression!) directed to the VM:

<pre>myself@mylap:~/.ssh> ssh -X -i ~/.ssh/id_rsa_x myself@debianx
Enter passphrase for key '/home/myself/.ssh/id_rsa_x': 
Linux debianx 5.10.0-kali3-amd64 ......
......
Last login: Fri Mar 26 17:38:16 2021 from 192.168.2.22
...
myself@debianx:~> 
myself@debianx:~$ libreoffice --draw

Note that “debianx” is now used as a host name! (The host name was chosen to be the same as the name of the VM in virt-manager; but the meaning in a network context, where “debianx” must be resolved to an IP, is now different. Note that the VM communicates to the outside world via a virtual network of the KVM host and routes defined on the VM and the KVM host directing data from the VM in the end over some NIC of the KVM host).

When moving the drawing’s figures around I measure data transfer rates on the relevant Ethernet device of the KVM-server:

Taking sent and received data together we have total rates around 25 MiB/s.

Now, in a second test, let us do something very different: We open Libreoffice Draw on the VM’s KDE desktop displayed in a Spice window, which in turn got transferred via SSH to the X11-service on my laptop:

And, again, we move the figures around very fast. The measured rates then are significantly smaller – below 4.4 MiB/s.

This proves the following statement which in turn justifies the whole Spice approach:

It may be more efficient to work remotely with a VM application on the VM’s desktop via Spice and a “SSH -X” connection to the KVM-server than requesting the graphical output of the VM’s application directly via “SSH -X” from the VM itself!

And what about sound?

We now turn to a topic which also deserves more documentation – namely the handling of sound with a remote solution like ours. We need Pulseaudio for a transfer of sound data from a VM (on the KVM/Qemu server) to the remote client system. Well, the very same Pulseaudio [PA] which often enough has ruined some of my nerves as a Linux user in the past 12 years or so. In combination with remote-viewer we simply cannot avoid it.

To be able to understand its configuration in a network with Opensuse Leap systems we must deal with the server properties of PA. See e.g. the following links for some explanation:
Free desktop Org documentation on Pulseaudio in a network
Archlinux documentation on PulseAudio

A Pulseaudio installation can work as a daemon-based service for other client-applications than the ones started locally during the desktop session of a user. Such clients can be applications started on other computers. PA’s client/server structure has network capabilities! To use PA in a network context some requirements must be fulfilled:

The module “module-native-protocol-tcp ” must be loaded. On a standard Opensuse Leap system this is the case; see the settings in the files “/etc/pulse/default.pa” and for a specific user in “~/.config/pulse/default.pa“.
For a direct connection between two PCs, as we need it for our present purpose, we can use a special TCP-port. The standard port is “4713“. For some first tests we will open this port for a directed transfer from the server to the client on local firewalls of the systems as well as on firewalls in between. But later we will rather integrate the port handling into our SSH tunnel.
The PA service must be told to accept remote connections over TCP. We can use the “paprefs” application for it.
We may require some form of authentication to grant access. We move this point to SSH by opening a remote tunnel – so we can forget about this point.

To get some information about
what is playing where during the next steps it is useful to have the applications “pavucontrol” (pulseaudio volume control) and “paman” (pulseaudio manager) running. You find the relevant packets in the standard Update Repository of your Leap distribution. The packet “qemu-audio-pa” should be installed, too, if it is not yet present on your system.

Where is sound of the VM played if we do nothing?

The funny thing about sound in our remote scenario with SSH and a Unix socket on the KVM host is the following:

When we start remote-viewer on the KVM-server in our scenario without any special measures for audio, we will see the graphical output on the remote client, but hear the sound on the speaker system of the server (if it has any). Well, in my test scenario the “server” has such an equipment.

well, let us start some sounds via the Spice windows on the client “MyLAP”. In the above images you saw that I had opened a directory with KDE sound files. Whilst we play them (e.g. with the parole player) we can at the same time have a look at the pavucontrol window on the KDE desktop of user “uvmb” on the server “MySRV”:

If you enlarge the image you see a PA-client there with the name “Remote Viewer”. This is not too astonishing as we had started remote-viewer on the KVM server and not on the remote laptop. And as a default remote-viewer interacts with the active PA on the system where remote-viewer itself is running:

Well this might be okay if the client and the server are in the same room. But if you had moved with your laptop into another room you, of course, would like to hear the sound on your laptop’s speakers. To achieve this we have to redirect the audio data stream of an application of the VM to a remote PA service.

How do we transfer sound from a SSH-server to the PA-system on the client during a SSH session?

I assume now that port 4713 is open on all firewalls. Still we have to prepare the PA-service on the remote client system – here on our laptop “MyLAP”.
For this purpose we open “paprefs” on MyLAP (NOT in the VM displayed in the Spice windows there, but in a standard terminal window of MyLAP’s desktop):

myself@mylap:~> paprefs

we turn to the tab “network server” and activate the following options:

Your laptop (the SSH- and Spice-client) is then able to work as a sound-server within the LAN.

Do not worry too much about the deactivated authentication. You can control in your firewall settings which system gets access – and later on we shall close port 4713 completely again for remote access by restrictive firewall rules. (If you really need authentication you must copy the cookie under “~/.config/pulse/cookie” from your laptop onto the server and uvmb’s folder structure.)

But now: How, do we tell an application started on the KVM-server to direct its audio output to the PA server on the laptop? Well, this is controlled by an environment variable “PULSE_SERVER”; see the documentation mentioned above about this.

You
can easily test this by opening a “ssh -X” connection from your remote system to an SSH server and redirect the audio output of an application like smplayer to the PA on your remote system. In my case:

<pre>myself@mylap:~/.ssh> ssh -X -i ~/.ssh/id_rsa_x uvmb@mysrv
Enter passphrase for key '/home/myself/.ssh/id_rsa_x': 
Last login: Thu Mar 25 09:54:53 2021 from 192.168.2.22
Have a lot of fun...
uvmb@mysrv:~> 
uvmb@mysrv:~> env PULSE_SERVER=192.168.2.22 smplayer & 
[1] 5041
uvmb@mysrv:~>

Any sound played with smplayer is now handled by the PA on the laptop. See the screenshot from the laptop:

Now, we can of course do the same with our remote-viewer:

<pre>myself@mylap:~/.ssh> ssh -X -i ~/.ssh/id_rsa_x uvmb@mysrv
Enter passphrase for key '/home/myself/.ssh/id_rsa_x': 
Last login: Thu Mar 25 09:54:53 2021 from 192.168.2.22
Have a lot of fun...
uvmb@mysrv:~> 
uvmb@mysrv:~> env PULSE_SERVER=192.168.2.22 remote-viewer spice+unix:///var/spicex/spice.socket &
[1] 5041
uvmb@mysrv:~>

You should hear any sound played with an audio application within the VM on the remote system (in my case on the laptop MyLAP):

Isn’t it fun?

Remote SSH tunnel and port forwarding for the transfer of audio data

Ok, we have a sound transfer – but not encrypted. This can – dependent on your audio applications – be a security hole. In addition we lack control over the users who may access our PA-server on the remote system. To cover both problems we are going now to make use of the full power of SSH. We open a reverse SSH tunnel with port forwarding from some arbitrarily chosen port on the KVM/Qemu server to port 4713 on the laptop:

<pre>myself@mylap:~/.ssh> ssh -X -R 44713:localhost:4713 -i ~/.ssh/id_rsa_x uvmb@mysrv
Enter passphrase for key '/home/myself/.ssh/id_rsa_x': 
Last login: .... from 192.168.2.22
Have a lot of fun...
uvmb@mysrv:~> 
uvmb@mysrv:~> env PULSE_SERVER=tcp:localhost:44713 remote-viewer spice+unix:///var/spicex/spice.socket &
[1] 5041
uvmb@mysrv:~>

You see the difference? We direct the audio output of remote-viewer on the KVM-host to port 44713 – and SSH does the rest for us via port-forwarding (plus encryption). (Control question: Which system does “localhost” in the SSH statement refer to? The laptop or the KVM/Qemu server?)

The result of this sound redirection looks, of course, the same on pavucontrol on our remote client system as before.

We now can close the port 4713 by some suitable firewall rule on our client system for any external access. Due to SSH port forwarding we only access the port locally there. You can even pin it on the “lo”-device with the SSH command. Read about it on the Internet.

The additional overhead of the audio data transfer is minimal in comparison to the video data transfer triggered by window manager operations:

We speak about some 600 KiB/s for some stereo sound.

To make things complete –
here are the data transfer rates for high resolution Live TV video streaming from the VM on the KVM-server over “SSH -X” to the remote client (without data compression):

You see: Its Easter time! Old Hollywood movies are running on German TV …

Conclusion

The method to access the Spice console of a VM with remote-viewer and via a Unix socket locally on the KVM host enabled a first secure remote scenario by simply redirecting the graphical data stream from the KVM-server to a remote X-window service with “SSH -X”.
The combination with a virtio-video device proved to deliver a relatively small peak data transfer rate around 45 MiB/s for complex window operations requiring a fast redraw of major parts of the desktop in the remote Spice windows. Without SSH data compression we got a very good responsiveness of complex windows to fast movements induced by the mouse cursor on the remotely displayed desktop of the VM. We saw that we could reduce the resulting data transfer rates below 9 MiB/s by using SSH data compression. However, this had some negative impact on the felt responsiveness of operations triggering the window manager of the VM’s graphical desktop.
However, working with graphical applications like Libreoffice Draw on the remotely displayed desktop of the VM via Spice and SSH required substantially smaller transfer rates than in a scenario where we requested a display of the application by a direct “ssh-X” connection to the VM itself.
I have shown in addition that we can easily transfer the sound created by audio applications within the VM via a remote SSH tunnel and port forwarding to the Pulseaudio server on the remote client system.

In the next article of this series we are preparing a TLS based remote solution for accessing the Spice console of a VM.

Links

SSH with compression
https://www.xmodulo.com/how-to-speed-up-x11-forwarding-in-ssh.html?format=pdf

SSH with Pulseaudio
https://askubuntu.com/questions/371687/how-to-carry-audio-over-ssh

Remote Desktop für Debian 8 mit X2Go auf Strato-V-Servern

Posted on 3. May 2017 by Ralph Mönchmeyer

In unserer Firma fallen z.Z. mehrere technische Schritte an, die wir parallel abwickeln müssen:

So stellen wir einerseits zwei Opensuse-Leap-Server für einen Kunden auf Debian-8-basierte vServer beim Hoster Strato um. Zeitgleich ersetzen wir das von uns unter Eclipse genutzte Versionsverwaltungssystem SVN durch Git und binden u.a. auch dabei einen der gehosteten vServer ein.

Damit wir und unser Kunde auf dem vServer

das dortige Git-Server-Repository besser kontrollieren und verfolgen können,
gelegentlich Branches anlegen und Merge-Aktionen durchführen können,

sollen auf dem vServer auch graphische GIT-Frontends zum Einsatz kommen. Z.B. “cola-git”, “qgit”, “giggle”. Ziel ist u.a. die Ansicht solcher Graphen wie in der nachfolgenden Abbildung:

Obwohl die Anwendung am Server läuft, wollen wir den Output natürlich auf dem Desktop unserer Arbeitsplatz-PCs oder denen des Kunden ansehen können.

So stellte sich uns also die Frage, wie man am schnellsten zu einem performanten graphischen Remote-Desktop für ein gehostetes “headless” System, also für ein System ohne echte eigene Grafik-Ressourcen, kommt. In unserem Fall zeigte sich, dass X2GO die richtige Wahl war und ist.

Nomenklatur – Remote Hosts, X-Server, X-Clients

Wir verwenden im weiteren Text die nachfolgende Nomenklatur, um Missverständnisse zu vermeiden. Bekanntermaßen ist ja beim X11-Protokoll die laufende Grafik-Anwendung ein “X-Client”. Das Umsetzungsprogramm, das aus den Grafik-Befehlen des Clients schließlich Fenster und grafische Inhalte auf den Bildschirm eines Linux-Desktops oder oder die Grafikstation eines Thin Client zaubert, ist hingegen der “X-Server”.

Die zuständigen Protokolle für den Datenaustausch zwischen X-Client und X-Server funktionieren auch über Netzwerke hinweg:

Als “Remote-Host” bezeichne ich den vServer bei Strato. Dort laufen dann Linux-Anwendungen, die grafischen Output im Rahmen ihres Benutzerinterfaces anbieten (in unserem Beispiel GIT-Anwendungen mit GUI).
Das Linux-System, von dem aus wir auf den vServer zugreifen, nenne ich “Arbeitsplatz-PC” oder kurz “PC”. Auf ihm läuft unter Linux selbstverständlich auch ein lokaler X-Server. Dieser dient wiederum einem Linux-Desktop – in meinem Fall KDE 5 – als technische Basis für die Integration grafischer Benutzerschnittstellen zu lokalen und entfernten Anwendungen.
Die graphischen Programme wie “qgit”, die auf dem vServer (=Remote-Host) laufen und ihren Output wie grafische Anweisungen einem lokalen oder über das Internet auch einem entfernten X-Server zuweisen, nennen wir “Remote X-Clients”.

Bzgl. möglicher Lösungen für Remote-Desktop-Darstellungen auf einem Arbeitsplatz-PC ist es nicht von vornherein klar, wo und in welcher Form ein X-Server zum Einsatz kommt. Natürlich läuft auf einem normalen Linux-PC ein X-Server für eine grafische Oberfläche; das schließt aber nicht aus, dass auch auf dem Remote-System ein X-Server aktiv ist.

Ein Remote-X-Client-Programm könnte also einerseits mit einem (headless) X-Server auf dem Remote-Host zusammenarbeiten. Er könnte andererseits aber auch direkt mit dem X-Server am Arbeitsplatz-PC über das Internet interagieren (z.B. über ssh -X oder die explizite Vorgabe eines entfernten X-Servers samt Screen über die Umgebungsvariable “DISPLAY”).

Funktionsweise von VNC vs. X2Go

Der Vollständigkeit halber werfen wir deshalb auch einen kurzen Blick auf Unterschiede in der typischen Funktionsweise von VNC und X2Go. Man beachte, dass in beiden Fällen “Server”-Komponenten auf dem Remote-Host und “Client”-Komponenten auf dem Arbeitsplatz-PC zum Einsatz kommen; das ist gerade umgekehrt wie bei den X11-Komponenten:

VNC: Auf dem Remote-Host kann theoretisch ein headless X-Server laufen, für dessen Implementierung ggf. die zu installierende Remote-Desktop-Umgebung (wie etwa ein VNC-Server-Modul) sorgen muss. Dessen Bilddaten-Output könnten dann über ein VNC-Programm abgegriffen und über das Internet an einen Arbeitsplatz-PC bei uns übertragen werden. Dort greift dann ein VNC-Client-Programm die Daten auf und blendet sie als lokaler X-Client über ein passendes Fenster in den grafischen Linux-Desktops des PCs ein.
X2Go: Unter X2Go läuft auf dem Remote-Host der sog. “X2Go-Server”. Der nutzt essentielle Teile des X11-Protokolls um Daten und Grafikanweisungen an den X-Server eines Arbeitsplatz-PCs zu übertragen. Dort koppelt allerdings ein zwischengeschalteter “X2Go-Client” an den X11-Server des Arbeitsplatz-PCs an. (Unter Windows Clients ist ein geeigneter X11-Server bereitzustellen!). Im Unterschied zu ” ssh -X” oder einem direkten Remote Zugriff auf einen X11-Server werden von den zwischengeschalteten X2Go-Komponenten zusätzlich Kompressionsalgorithmen und Caches exzessiv genutzt und der Statusabgleich zwischen X11-Server und X11-Client auf das notwendige Minimum reduziert.

In beiden Fällen müssen die VNC- oder X2Go-Client-Komponenten natürlich die Keyboard- und Mausinteraktionen mit den relevanten Fenstern am Arbeitsplatz-PC abfangen und an die X-Clients auf dem Remote-Host übertragen.

Ich gehe nachfolgend von klassischen X-Servern (und nicht Wayland) aus. Wayland ist meines Wissens nicht mit X2Go kompatibel.

SSH -X als Alternative ?

Natürlich habe ich auf unserem Strato-vServer erstmal eine direkte grafische Datenübertragung zwischen den X-Clients der vServer und meinem Arbeitsplatz-PC mittels “ssh -X” ausprobiert. Dabei wird der Grafik-Output der X-Remote-Clients (über das zwischengeschaltete Internet) direkt vom X-Server am Arbeitsplatz-PC behandelt. Aber Qgit, Giggle und Co. sind doch schon recht komplexe Anwendungen, die mit einem X-Server relativ häufig relativ viele Informationen austauschen müssen.

Ich war mit der Performance überhaupt nicht zufrieden. Das Arbeiten an sich erwies sich zwar nicht als unmöglich; aber bei verschiedenen Schritten treten doch spürbare Wartezeiten auf – u.a. beim Aufbau von Verzeichnis- und Strukturbäumen. Die Durchführung von Änderungen war dann nicht wirklich bequem, sprich nicht flüssig möglich. Mein Eindruck war: Es wird eine deutlich bessere Kompression und Pufferung der Daten benötigt.

Probleme mit VNC – und Einschränkungen bzgl. der Desktop-Umgebung

Ich dachte als Nächstes natürlich an klassische VNC-Anwendungen (https://de.wikipedia.org/ wiki/ Virtual_Network_Computing), mit deren Hilfe man einen echten Remote-Desktop realisiert.

In LANs hatte ich früher schon mal TurboVNC eingesetzt. Ich hatte das damals als recht performant empfunden. Sogar der Einsatz von VirtualGL für Remote-Hosts, die mit einer 3D-Grafik-Karte ausgestattet waren, war möglich. Nun braucht man für einen Strato vServer und GIT-Frontends natürlich kein VirtualGL. Aber TurboVNC war ja auch sonst ganz OK – zumindest unter älteren Opensuse-Systemen.

Dennoch habe ich den Einsatz von TurboVNC auf einem Strato-vServer mit Debian nach ein paar Experimenten abgebrochen. Unter Debian 8 gab es (fast erwartungsgemäß) Probleme mit Gnome 3 (trotz vorhandener Mesa-Bibliotheken). Gnome 3 ist (wie KDE 5 auch) von Haus aus für VNC problematisch, da 3D-Fähigkeiten der Umgebung vorausgesetzt werden. Bei mir klappte der Start des Desktops trotz vorhandener Mesa-Bibliotheken und des lokalen VMware-Grafiktreibers des Virtuozzo-Containers für den Strato-vServer nicht.

Auch eine kurze Recherche im Internet zeigte: Der Einsatz von Gnome erfordert unter klassischen VNC-Servern (und auch unter TurboVNC) einfach viel zu viele Klimmzüge. Wie funktionabel und performant dagegen der in Gnome integrierte VNC-Server “vino” ist, habe ich in meinem Frust dann nicht mehr ausprobiert.

KDE 4 unter Debian 8 ging zwar unter TurboVNC; ich bekam aber keine Veränderung der Auflösung jenseits 1024x768px am TurboVNC-Client auf dem Arbeitsplatz-System hin. Der Zeitaufwand für das Rumprobieren wurde mir dann irgendwann zu groß. Das hatte zwei Konsequenzen:

Als erstes reduzierte ich meine Anforderungen an eine Desktop-Umgebung kurzentschlossen auf LXDE und KDE4. Mit letzterem kennt sich auch unser Kunde in hinreichendem Maße aus.
Als zweites konzentrierte ich mich auf die von Debian im Standardumfang mitgelieferten VNC-Pakete: “tightvnc” und “vnc4server”.

Ein Kurztest der beiden VNC-Varianten überzeugte mich aber hinsichtlich der Performance mit KDE 4 nicht; besonders nicht der vnc4server. Mit LXDE konnte ich dagegen ganz gut arbeiten.

KDE 4 ist halt ein Desktop-Schwergewicht, das den X11-Server je nach Desktop-Gestaltung laufend belastet. Dabei ist zu bedenken, dass die meisten VNC-Systeme auf dem Remote-Linux-System einen laufenden (headless) X11-Server brauchen, dessen Bilddaten dann abgegriffen und an einen VNC-Client auf einem lokalen PC übertragen werden. Das ist vom logischen Prozess-Ablauf her gesehen ein Umweg, weil neben dem X11-Server noch eine Zwischenschicht auf dem Remote-System ausgeführt werden muss. Die Bilddaten auf dem lokalen PC müssen zudem wieder in einem Fenster auf dem lokalen X11-Server dargestellt werden.

X2Go als Alternative ?

Wenn es denn hinreichend schnell funktionieren würde, würde man deshalb als Linuxer eigentlich immer gerne direkt Remote-X11 über SSH einsetzen. Auf dem Remote-System – hier also dem vServer – liefen dann Anwendungen, die als X-Window-Client-Programme ihre Daten und graphischen Steuerbefehle (über einen SSH-Tunnel) direkt an den aktuell laufenden X11-Server auf meinem Arbeitsplatz-PC übertragen. In unserem LAN klappt das auch wunderbar – sogar mit der Übertragung von 3D-Grafik-Daten. Da reicht die Bandbreite schon in einem Gigabit-Netz zur schnellen Datenübertragung völlig aus. Das gilt aber leider nicht unbedingt für Remote-Systeme im Internet zu denen die Bandbreite in beide Richtungen begrenzt ist. (Zumindest bei mir).

Dann fiel mir ein: Eine hinsichtlich Kompression, Caching und X11-Server/Client-Abgleich optimierte Variante des X11-Protokolls über ein Netzwerkverbindungen lieferte doch das NX3-Nomachine-Protokoll; es bildet die Grundlage des Opensource Forks X2Go (siehe hierzu die Links weiter unten).

Ergebnis eines kurzen X2Go-Tests

Am Ostersamstag habe ich mir dann nach ein wenig Internet-Recherche (und zum Leidwesen meiner Frau) auch den X2Go-Server und X2Go-Client angesehen. Ergebnis: Ich bin nach wie vor begeistert! Stichpunkte sind:

Denkbar einfache Installation und Konfiguration. Einfache Integration von SSH-Schlüsseln. Einfache Einstellung unterschiedlicher Auflösungen.
Sehr gute, wirklich überzeugende Performanz!
Der Datenaustausch zwischen Remote-System und dem Arbeitsplatz-PC erfolgt von vornherein auf SSH-Basis.

Weitere erwähnenswerte Features, die die praktische Nutzung erleichtern, sind:

Copy/Paste zwischen nativen lokalen Fenstern des Arbeitsplatz-PCs und Fenstern des Remote-Desktops ist nahtlos möglich.
Freigabe lokaler Verzeichnisse: X2Go erlaubt vom Remote-Desktop aus auch einen Zugriff auf (dafür freigegebene) lokale Verzeichnispfade des Arbeitsplatz-PCs. Damit können Files auf dem Remote-Host z.B. in einem graphischen File-Manager zwischen den dortigen Verzeichnissen (des Hosts) und dem lokalen Verzeichnis des Arbeitsplatz-PCs verschoben/kopiert werden. Zur Wahrung der Sicherheit bei solchen Transaktionen gibt es die Option, den Datenaustausch über SSH getunnelt durchzuführen.
Mehrere Sitzungen gleichzeitig: Will man mehrere Sitzungen zu verschiedenen Servern gleichzeitig öffnen, so startet man auf dem lokalen PC mit “x2goclient &” einfach einen neuen Client. Auch zwei Sitzungen unter unterschiedlichen Benutzernamen zum gleichen Server sind möglich. Ebenso zwei Sitzungen mit derselben Remote-UID für verschiedene Desktops/Window-Manager – z.B. eine Sitzung mit LXDE und eine mit KDE für ein und denselben User auf demselben Remote-Host. X2Go-Client zeigt einem eine Liste laufender Sitzungen und fragt, was mit den laufenden Sitzungen passieren soll. Die lässt man weiterlaufen und wählt für die neue Sitzung die Option “Neu”. Die verschiedenen Remote-Sitzungen zum gleichen Remote-Host teilen sich dann aber natürlich dessen Netzwerk-Ressourcen. Die sind bei Stratos vServern durchaus begrenzt.
Seamless Mode: X2Go erlaubt anstelle der Anzeige eines kompletten Remote-Desktops theoretisch auch das Remote-Starten einer einzelnen Anwendung und deren Anzeige auf dem lokalen Desktop des Arbeitsplatz-PCs. (Seamless Mode; das Ganze entspricht dann in der klassischen SSH-Welt in etwa dem vorkonfigurierten Aufruf einer grafischen Remote-Applikation nach einem ssh -X.). Leider klappt das aber auf einem KDE5-Plasma-Desktop (s.u.) nicht wie erwartet.
Desktop-Sharing: X2Go bietet auch die Möglichkeit des Desktop-Sharings zwischen verschiedenen Nutzern an – das habe ich aber unter den Bedingungen eines vServers aber noch nicht ausprobiert. Ich gehe darauf in diesem Artikel auch nicht weiter ein.

Mit jedem dieser Punkte kann ja jeder mal selber herumexperimentieren. Siehe zur Thematik paralleler Sitzungen auch
https://gist.github.com/ ledeuns/ f0612fb43b967c129c88)

Bzgl. des Desktop-Sharings:
http://wiki.x2go.org/ doku.php/ doc:usage:desktop-sharing

Arbeitet man gleichzeitig unter derselben UID mit 2 getrennten Sessions – z.B. einer LXDE- und einer KDE-Sitzung – auf demselben Arbeitsplatz-PC, so können dabei interessante Effekte z.B. unter Libreoffice auftreten: Ist Libreoffice bereits auf einem der (Remote-)Desktops (z.B. dem KDE-Desktop) geöffnet, so wird ein nachfolgendes Libreoffice-Programm, das in einer parallel laufenden LXDE-Sitzung gestartet wird, trotzdem im KDE-Desktop angezeigt. Ansonsten läuft das Meiste aber normal und erwartungsgemäß.

Für mich war wirklich überraschend, dass neben meinen Git-GUIs auch stark grafiklastige Anwendungen wie Libre-Office Draw, Impress, Inkscape etc. gleichzeitig und sehr, sehr flüssig nutzbar waren. Aus meiner Sicht ist hier die Performance eines Terminal-Servers gegeben, die im wesentlichen nur durch die Netzanbindung des vServers ans Internet limitiert wird und im getesteten Umfang (4 parallele 1920×1200 Sitzungen) überhaupt nicht durch CPU/RAM des Virtuozzo Containers für unseren vServer [V30 bzw. V40, HP3PAR] begrenzt wurde.

Weil es so schön ist, nun eine Zusammenstellung der wichtigsten Hinweise zur Installation und Inbetriebnahme von X2Go, die ich bei dieser Gelegenheit im Internet aufgesammelt habe.

X2Go-Installation: Passende Repositories ziehen

Unter folgendem Link ist beschrieben, wo man die aktuellen Repositories mit X2Go-Komponenten für Debian 8 (64Bit) findet: http://wiki.x2go.org/ doku.php/ wiki:repositories:debian.

Man trägt dann die Repositories über folgende Zusatzzeilen in die Datei “/etc/apt/sources.list” ein:

root@myremotedebian:~# cat /etc/apt/sources.list
# See sources.list(5) for more information, especialy
# Remember that you can only use http, ftp or file URIs
# CDROMs are managed through the apt-cdrom tool.
deb ftp://ftp.stratoserver.net/pub/linux/debian/ jessie main contrib non-free
deb ftp://ftp.stratoserver.net/pub/linux/debian-security/ jessie/updates main contrib non-free

#ICH - 15.04.2017 - Repos for X2Go:
# -----------------------------------
#X2Go Repo
deb http://packages.x2go.org/debian jessie main
# X2Go Repository (sources of release builds)
deb-src http://packages.x2go.org/debian jessie main

Zur Sicherheit machen wir den zugehörigen Key verfügbar; als root:

root@myremotedebian:~ # apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E

Dann Update der Paket-Datenbank durchführen:

root@myremotedebian:~ # apt-get update

Nun – als Test – Installieren des Schlüssels über ein Paket aus dem X2Go-Repository:

root@myremotedebian:~ #  apt-get install x2go-keyring && apt-get update

Dann die Pakete x2goserver und x2goserver-xsession installieren:

root@myremotedebian:~ #  apt-get install x2goserver

Bei mir wurde x2goserver-xsession automatisch mit installiert. Falls das nicht der Fall sein sollte:

root@myremotedebian:~ #  apt-get install x2goserver-xsession

Man glaubt es vielleicht nicht – aber das war es im Prinzip serverseitig schon. Zumindest was X2Go anbelangt. Der Grund hierfür ist, dass der X2GO-Client (s.u.) eine SSH-Sitzung nutzt und im Zuge des SSH-Logins die nötigen Umgebungsvariablen setzt und erforderliche Programme auf dem Server für eine Remote-X-Sitzung startet.

LXDE und KDE 4 installieren

Sollte man LXDE oder KDE 4 unter Debian 8 noch nicht installiert haben, so ist dies über

root@myremotedebian:~ #  apt-get install lxde

bzw.

root@myremotedebian:~ #  apt-get install kde-standard

möglich.

Will man Remote-Audio nutzen, sollte man ggf. auf dem Remote-Host und auch auf dem Arbeitsplatz-PC Pulseaudio installieren. Für mich ist Sound irrelevant – und Pulseaudio kommt bei mir aus Prinzip nicht auf einen PC-Desktop. Aber das mag ja bei anderen anders sein … 🙂

Natürlich muss auf beiden Systemen SSH bereitstehen ..

Auf dem Debian 8 Remote-Host muss zwingend das Paket “openssh-server” installiert sein. Zudem sollte der Server aus Sicherheitsgründen so konfiguriert sein, dass der SSH-Port verlagert ist, sichere Kex-Algorithmen genutzt und eine Authentifizierung über asymmetrische Keys (hinreichender Länge) durchgeführt wird. Der Zugang sollte ferner durch eine Firewall und weitere Maßnahmen auf bestimmte Clients beschränkt werden. Ich gehe auf die SSH-Server-Konfiguration hier nicht weiter ein. Da wir es hier mit gehosteten Remote-Systemen zu tun haben, gehe ich davon aus, dass der zuständige Admin dieses Metier beherrscht.

Jedenfalls muss auf dem Server ein SSHD-Dämon laufen und bereit sein, Logins über einen in der Firewall für bestimmte Clients geöffneten Port entgegen zu nehmen. X2Go tunnelt später die gesamte Kommunikation zwischen Client und Server durch die SSH-Verbindung. Darum muss man sich nicht mehr selber kümmern; s.u.. Es ist übrigens nicht notwendig, für verschiedene Sitzungen auf ein und demselben Remote-Host mehrere unterschiedliche SSH-Ports zu öffnen.

Installation und Nutzung auf dem Arbeitsplatz-PC (X2Go-Client)

Bzgl. der Client-Installation gilt: Es sind passende Pakete für die Distribution zu finden, die man auf seinem Arbeitsplatz-PC einsetzt. Siehe für Hinweise
http://wiki.x2go.org/ doku.php/ doc:installation: x2goclient.

Ich beschreibe die Clientseite hier nur für einen Opensuse Leap 42.2 Client. Für Opensuse liegen die erforderlichen RPMs unter folgendem Repository:
repositories/X11:/RemoteDesktop:/ x2go/openSUSE_Leap_42.2/
Von dort installiert man mittels YaST etwa “x2goclient”, “pyhoca-gui”. Der Rest der benötigten Pakete wird dann über Abhängigkeiten nachgezogen:

Nun öffnet man auf seinem Client-PC den Client am Terminal etwa über:

ich@mytux:~> x2goclient &

Es öffnet sich initial eine Oberfläche, die die Anlage von sog. “Sitzungen” zu Remote-Hosts erlaubt; diese “Sitzungsvarianten” werden später im X2Go-Client-Fenster zur Auswahl angeboten.

Ich zeige nachfolgende die verschiedenen Konfigurationsdialoge für eine Sitzung (die ich “Dummy” genannt habe). Natürlich muss man die Eingabefelder mit den für seine eigene Situation passenden Daten ausfüllen.
Siehe für eine ausführliche Beschreibung des X2Go-Client-Setups zudem:
http://wiki.x2go.org/ doku.php/ doc:usage:x2goclient

Zunächst – und das ist das Wichtigste – müssen wir die Serververbindung einstellen:

Dann steht eine Konfiguration der Bandbreite der Verbindung an:

Wir wenden uns anschließend einer Konfiguration der Auflösung der Desktop-Darstellung zu:

Für erste Tests deaktivieren mal die Sound-Unterstützung:

Als letztes kann man konfigurieren, ob man bestimmte Verzeichnisse auf dem Arbeitsplatz-PCs für einen direkten Zugriff durch Remote_X-Client-Programme freigeben will. Tut man das, so sollte man in jedem Fall die zugehörige Option zur SSH-Port-Weiterleitung aktivieren.

Man kann all diese Konfigurationseinstellungen später über den Menüpunkt “Sitzung => Sitzungsverwaltung” nachbessern.

Resultate

Hat man seine “Sitzung” konfiguriert, so steht diese im rechten Bereich des X2Go-Client-Fensters zur Aktivierung bereit.

Nach einem Doppelklick rückt die aktivierte Verbindung ins Zentrum der Anzeige; in unserem Fall öfnnet sich zudem ein kleines Dialogfenster, in dem wir die Passphrase für unseren SSH-Key eingeben müssen. Und nach wenigen Augenblicken/Sekunden öffnet sich schließlich das Fenster für unseren Remote-Desktop – hier mit LXDE :

Der aufmerksame Betrachter wird Qgit im linken Bildbereich entdeckt haben – hier für ein noch sehr langweiliges Test-Repository. Ich habe fast alle mir unter Linux bekannten Git-Clients ausprobiert – jeder läuft flüssig; fast wie lokal.

Das Ganze nun auch nochmal für einen Remote-KDE-Desktop:

Für 2 parallele Sitzungen zum gleichen Server muss man einfach zwei x2go-Clients öffnen und in einer zwischenzeitlichen Anzeige bereits geöffneter Sessions die Optionen so wählen, dass die bereits geöffnete Sitzung nicht unterbrochen werden soll, sondern dass eine neue Sitzung geöffnet werden soll.

Die nachfolgende Abbildung zeigt zwei parallel zu einem vServer unter Debian 8 geöffnete Sitzungen – eine unter LXDE, die andere unter KDE4:

Getestet habe ich das Ganze mit einer vDSL-Leitung, aber auch einer ADSL-16MBit-Leitung – auch bei letzterer sind mehrere gleichzeitige Sitzungen kein Problem !

Wo so viel Licht ist, gibt es aber auch Schatten. Daher sei abschließend noch auf 2 Punkte hingewiesen, die in der Praxis relevant werden können.

Problematischer Punkt bzgl. der Soundunterstützung und Firefox unter X2Go

Im Prinzip kann X2Go (angeblich) Audio-Daten übertragen. Allerdings über einen Pulseaudio-Server. Den habe ich bei mir allerdings wegen vieler Probleme mit einer Xonar D2X und einer X-Fi nicht am Laufen. Ich benutze ausschließlich plain Alsa – das funktioniert zuverlässig und erlaubt das Umschiffen vieler Pulseaudio-Probleme. Fakt ist jedenfalls, dass es mit einer aktivierten Sound-Unterstützung für Pulseaudio unter X2Go und einem remote gestarteten Firefox ESR erhebliche Probleme gibt:

Alle Menüpunkte der Firefox-Oberfläche reagieren nicht mehr bzw. mit erheblicher (!) Zeitverzögerung auf Maus-Klicks im X2GO-Client. Firefox wirkt wie eingefroren; das stimmt aber nicht – die Reaktion kommt nur mit Minuten Verzögerung. Das ist u.a. hier beschrieben:
http://thescriptingadmin.blogspot.de/ 2015/09/ firefox-freezing-on-linux-x2go.html
https://debianforum.de/ forum/ viewtopic.php?t=164257

Wer immer daran Schuld hat. Da das mit anderen GTK-Anwendungen als FF nicht passiert, tippe ich darauf, dass FF bei installiertem PA auch erwartet, dass PA reagiert. Was remote evtl. ein Problem darstellt, wenn dort PA ggf. gar nicht installiert ist.

Ich habe mangels Interesse nicht getestet, ob dieser Fehler u.U. daran liegt, dass auf meinem Arbeitsplatz PA nicht aktiv ist. Lasst mir gerne eine Email zukommen, wenn ihr dazu was wisst. Ich persönlich verzichte aber lieber auf Sound von einer Remote-X2Go-Quelle, als mich mit PA herumzuschlagen. Vielleicht probiere ich das später mal auf einem Laptop. Falls ihr auch auf dieses Problem mit FF stoßen solltet und bereit seid, auf Sound vom X2go-Server zu verzichten, gilt Folgendes:

Wichtiger Hinweis zu einem Problem mit Firefox und dem X2Go-Client unter Linux:

Soundunterstützung im X2Go-Client abschalten (Reiter “Medien” unter den Einstellungen) oder aber auf einen anderen Soundserver umschalten. Bei mir funktionierte ein Remote-Firefox FF im X2Go-Desktop-Fenster nach einer Abschaltung der Soundunterstützung durch Pulseaudio problemfrei.

X2Go Seamless Mode funktioniert nicht unter KDE5

X2Go bietet zwar im Prinzip die Möglichkeit an, Remote X-Anwendungen auch als singuläre Applikationen zu starten, die direkt als Fenster (also ohne umgebenden Remote-Desktop) in den Desktop des Arbeitsplatz-PCs eingeblendet werden.

Hierzu konfiguriert man eine entsprechende Sitzung, z.B. nur für “qgit”, wie folgt:

Danach startet die angegebene Applikation im seamless Fenstermode. Das klappt auch mit einem Terminal wie etwa “lxterminal” (“/usr/bin/lxterminal”). Von der Kommandozeile aus, kann man dann weitere Anwendungen wie “qgit” starten, die dann wiederum als Einzelapplikation auf dem lokalen Desktop angezeigt werden.

Leider täuscht aber der erste positive Eindruck; unter KDE5 sind die zugehörigen Fenster für komplexere Anwendungen als ein Terminal in ihrer Größe leider nicht veränderbar. Das macht den Einsatz des “Seamless Mode” für KDE5 am Arbeitsplatz-PC in der Praxis unbrauchbar. Der seamless Mode funktioniert aber sehr wohl unter einem LXDE-Desktop am Arbeitsplatz-PC.

Fazit

X2Go bietet eine einfache zu handhabende Möglichkeit, performant von einem Linux-Arbeitsplatz-PC auf grafische Anwendungen eines Remote-Strato-vServers zuzugreifen. Die Linux-Installation des vServers muss lediglich einen LXDE- oder KDE4-Desktop unterstützen. (Desktops unter XFCE, Mate, LXQT habe ich nicht getestet; das sollte aber auch alles funktionieren).

Als einzige Wermutstropfen bleiben, dass der Seamless Mode auf einem KDE5-Target-Desktop des Arbeitsplatz-PCs nicht richtig funktioniert und dass im Moment weder native KDE5- noch Gnome3-Desktops des vServers unterstützt werden. Angeblich wird daran aber bereits von den X2Go-Entwicklern gearbeitet; wir freuen uns auf entsprechende neue X2Go-Versionen.

Links

Was ist X2GO?
http://www.mn.uio.no/geo/ english/services/it/help/ using-linux/x2go.html
https://de.wikipedia.org/ wiki/ NX_NoMachine
http://xmodulo.com/x2go-remote-desktop-linux.html
https://serverfault.com/ questions/227542/ what-alternatives-to-vnc-are-there-for-linux

Details zum Server
http://wiki.x2go.org/doku.php/wiki: advanced: x2goserver-in-detail

Installation von X2Go
http://wiki.x2go.org/doku.php/ wiki:repositories:debian
https://www.sugar-camp.com/x2go-vorstellung-und-installationsanleitung/
http://wiki.x2go.org/ doku.php/ doc:installation:x2goserver
http://www.linux-community.de/Internal/Artikel/ Print-Artikel/LinuxUser/2011/07/X2go-Terminalserver-auch-fuer-den-Hausgebrauch
http://xmodulo.com/x2go-remote-desktop-linux.html
https://mun-steiner.de/ wordpress/ index.php/ linux/ x2go-mit-ssh/
https://wiki.archlinux.de/title/X2go

Installation und Übersicht über ein paar Bugs
http://www.mn.uio.no/geo/english/ services/it/help/ using-linux/x2go.html

VNC : Benötigt VNC einen X-Server?
https://unix.stackexchange.com/ questions/ 129432/vnc-server-without-x-window-system