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.
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.
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 800x800 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>
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 1920x1200 px and a FF window of 1200x800 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 1920x1200 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. :
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.
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.