KVM/Qemu VMs with a multi-screen Spice console – II – local access with remote-viewer via a network port

Posted on 8. March 2021 by eremo

In my first article in this series on local and remote connections to the Spice console of a KVM/Qemu virtual machine [VM] I have given you an overview over some major options. See the central drawing in

KVM/qemu with the graphical multi-screen Spice console – I – Overview over local and remote access methods

In this post we explore a part of the drawing’s left side – namely a local connection with the remote-viewer client over a network-port and the “lo”-device. Local means that we access the Spice console with a Spice client in a desktop session on the KVM/Qemu host.

You can find some basic information on “remote-viewer” here.

Note: “remote-viewer” supports VNC, too, but we ignore this ability in this series.

A local scenario with remote-viewer on a KVM/Qemu host corresponds to desktop virtualization – though done with a remote tool. Such an approach can become a bit improper, because setting up ports for potential remote network connections always has security implications. This is one of the reasons why I actually want to discuss two different local access methods which can be realized with remote-viewer:

Method 1: Access via a network port (TCP socket). This standard method is well documented on the Internet both regarding the VM’s setup (e.g. with virt-manager) and the usage of remote-viewer (see the man pages). The network based scenario is also depicted in my drawing.
Method 2: Access via a local Unix socket. This method is not documented so well – neither regarding the VM’s setup (e.g. with virt-manager) and not at all by the man pages for remote-viewer.

You may complain now that I never indicated anything in the above drawing about a pure Unix socket! Well, at the time of writing the first article I did not even know that remote-viewer worked over a pure Unix socket and how one can configure the VM for a Unix socket. I will discuss the more common “Method 1” in this present article first. “Method 2” will be the subject of the next post – and then I will provide an update of the drawing. Talking about sockets: When you think a bit about it – Unix sockets must already be an ingredient of the local interaction of libvirt-tools with qemu, too, ….

Below I will discuss a set up for “Method 1” which is totally insecure. But it can be realized in a very simple way and is directly supported by virt-manager for the VM setup. Thus, it will give us a first working example without major efforts for creating TLS certificates. But, you are/were warned:

Disclaimer:
The test-configurations I discuss in this and the next articles of this series may lead to major security risks. Such configurations should NOT be used in productive multi-user and/or network environments without carefully crafted protection methods (outside the qemu-configuration) – as local firewall protection, system policies, etc. I take no responsibility whatever for an improper usage of the ideas presented in this article
series.

Assumptions for test scenarios

The KVM/Qemu host in this article series is an Opensuse Leap 15.2 host. Most of the prescriptions discussed may work with some minor modifications also on other Linux distributions. But you must look up documentations and manuals …
I assume that you already have set up a KVM/Qemu based test-VM with virsh or virt-manager. Let us call the VM “debianx“. Actually, it is a Kali system in my case. (Most of the discussed measures will work on guests with a Debian OS, too.)
On our Opensuse KVM host we find a XML-definition file “debianx.xml” for a libvirt domain (i.e. a VM) below the directory “/etc/libvirt/qemu/“, i.e. “/etc/libvirt/qemu/debianx.xml”. It has a typical XML structure and can be edited directly if required.
The KVM host itself has a FQDN of “MySRV.mydomain.de“. (MySRV is partiall writtenin big letters to remind you that you have to replace it by your own domain.
The user on the KVM host, who invokes remote-viewer to access the VM, has a name “uvma“. We will later add him to a group “libvirt” which gets access rights to libvirt tools. We shall also work with a different user “uvmb” who is a member of the group “users”, only. Both users work on a graphical desktop on the KVM/Qemu host (!) – let us say a KDE desktop. These users open one or more Spice client windows on the host’s desktop to display graphical desktops of the KVM/Qemu guest VMs – as if the windows were screens of the VM.

We must carefully distinguish between the (KDE) desktop used by “uvma” on the KVM host and the desktop of the guest VM:

The Spice client windows on the KVM host’s (or later on independent remote systems) desktop present full graphical desktops (Gnome, XFCE, KDE …) of the VM and allow for interactive working with the VM. The desktop used on the host can, of course, be of a different type than the one used on the guest.

I will use this first practical article also

to have a brief look at two basic configuration files for libvirtd and qemu settings,
to discuss some basic setup options for a Qemu VM,
to check the multi-screen ability of remote-viewer
and to prove the “one-seat” situation for the Spice console.

I restrict my hints regarding the guest configuration to Kali/Debian or Opensuse Leap guest systems on the VM. I provide images for a Kali guest system, only. I do not have time for more …

Make backups

Before you start any experiments you should make a backup of the directories “/etc/libvirt” and “/etc/pki” of your host – and in doubt also of the disk-files (or real partitions) of your existing VMs. You should also experiment with a non-productive test VM, only.

Basic security considerations

(In-) Security is always a bit relative. Let us consider briefly, what we intend to do with respect to “Method 1”:

With the first method we define a network port for unencrypted connections without authentication.

In principle the port can be used by anyone having access to your network or anyone present on your PC. Such a configuration is therefore only reasonable for desktop virtualization

if you really are alone on your PC

AND if you have a local firewall preventing access to the port from any other system AND if there is a local policy restricting access to the Qemu-hypervisor or Spice-clients.

nOtherwise it opens a much too big attack surface. Remember: Anyone being able to use the network port can kick you off your Spice console session seat, remotely, locally and also when you are already logged into the guest OS. And:

All data transfer over any kind of network device (lo, ethernet, virtual devices on the host, …) occurs unencrypted. Other users on your machine (legal users, e.g. active via ssh, or attackers) may with some privilege escalation be able to read it.

Access to the Spice console itself can, however, be restricted to users who know a password. At the end of this article we will add such a simple password to our configuration to get at least some basic protection against kicking you out of a Spice console session.

Preparational step 1: Settings in “/etc/libvirt/qemu.conf” and the integration of Spice with Qemu

As mentioned in the last article, Spice is fully integrated with the Qemu-emulator. So, it will not surprise you that we can modify some general properties of connections to a VM’s Spice console by parameter settings in a configuration file for Qemu. The relevant file in the libvirt-dominated virtualization environment of Opensuse Leap 15.2 is

“/etc/libvirt/qemu.conf“.

Readers of my last article may ask now: Why do we need to configure the Qemu-driver of libvirt at all, when we access the Spice console with remote-viewer directly via Qemu ? I.e., without passing a libvirt-layer? As depicted in the drawing?

Answer: Probably you and me start KVM/Qemu based VMs through “virsh” or “virt-manager“, i.e. libvirt components. Then libvirt drivers which are responsible to start the VMs according to its setting profile must know what we expect from the Qemu emulator. If you worked directly with the qemu-emulator (by calling “/usr/bin/qemu-x86_64”) you would have to specify a lot of options to control the outcome! Some sections below you will find an example. Libvirt-programs only automate this process.

“qemu.conf” allows for general default settings of a variety of qemu-parameters. Some of them can, however, be overwritten by VM-specific settings; see the next section. When you scroll through the file you come to a major section which contains Spice parameters. For an easy beginning of our experiments we set some selected parameters to the following values:

 
#spice_listen = "0.0.0.0" # just leave it as it is 
# .... 
spice_tls = 0  # This corresponds to a deactivation of TLS and a INSECURE configuration!
spice_tls_x509_cert_dir = "/etc/pki/libvirt-spice"
# .... 
# just leave the next settings as it is - it creates a socket at  "/var/lib/libvirt/qemu/domain-1-debianx/monitor.sock"
#spice_auto_unix_socket = 1  
spice_sasl = 0

Our first setting deactivates TLS. This is reasonable as long a we have not created valid TLS server certificates and encryption keys. But we can already define a default directory into which we later place such a certificate and key files. We also deactivate any SASL authentication support for the time being. (Actually, even if you left it at the default value of “1” it would not help you much – as on Opensuse systems a required file “/etc/sasl2/qemu.conf” is missing, yet. As standard SASL encryption methods are insecure today, SASL activation makes sense in combination with TLS only.

General security precautions in “/etc/libvirt/qemu.conf”
Talking about security: On an Opensuse system with activated “apparmor” you could/should set the following parameters in “/etc/libvirt/qemu.conf”:

 
security_driver = "apparmor"
security_default_confined = 1

to confine VMs.

Note: If “apparmor” is deactivated for some reason you will after these settings not be able to use virt-manager or virsh.
You can check the status of apparmor via “rcapparmor status” or systemctl status apparmor”.
(Off topic: Those interested in process separation should also have a look at cgroup-settings for the VMs. I would not change the basic settings, if you do not know exactly what you are doing. But folks trying to experiment with “virgl3D” may need to add “/dev/dri/renderD128” to the device list for ACLs.)

Preparational step A: A brief look a “/etc/libvirt/libvirtd.conf” – allow a selected standard user to use virt-manger or virsh

As we are within the folder “/etc/libvirt”, we take the chance to very briefly look at another configuration file, which will become more interesting in later articles:

/etc/libvirt/libvirtd.conf

Among other things this file contains a variety of parameters which control the access to libvirt tools via Unix sockets or TCP-sockets – with and without TLS and/or some form of authentication. This is of no direct importance for what we presently are doing with remote-viewer – as we access Spice console directly via qemu, i.e. without a libvirt-layer. However, for convenience reasons you should nevertheless be able to use virt-manager or virsh. If you do not want to work as root all the time you, i.e. he normal user “uvma”, need(s) special access rights to access Unix sockets which are automatically opened by libvirtd. How can this be achieved on an Opensuse Leap system?

You can configure a special user-group (e.g. a group named “libvirt”) to get access to virt-manager. You can do this in a section named “UNIX socket access controls”. The instructions in Opensuse’s documentation on virtualization (see: Connections and authorization and section 9.1.1.1 therein) will help you with this. Afterwards you must of course add your selected and trusted user (here: “uvma”) to the defined group.

Note: The libvirtd-process is nevertheless run by the user “root” and not with the rights of the standard user (here “uvma”). The group just allows for a kind of sudo execution. Note also that the central sockets by which libvirt-clients connect to the libvirtd-daemon are created by systemd.

By the way – who is the user for qemu-processes on an Opensuse Leap system?
On an Opensuse there is a special user “qemu” which is used to run the Qemu-emulator processes for VMs. We also find a related group “qemu”. User and group have special rights regarding aes-keys for potential credential encryption related to a VM. The user and its group also define the access right to special Unix sockets generated directly by the Qemu emulator and not by libvirtd. We shall request such a Unix socket from Qemu in the next article.

On other operative systems you may find a different pre-configured group for libvirt access rights. In addition the standard qemu-user may have a different name. For Debian and derivatives you find related information at the following links:
whats-the-purpose-of-kvm-libvirt-and-libvirt-qemu-groups-in-linux,
install-configure-kvm-debian-10-buster,
libvirt_qemu_kvm_debian .

Preparational step B: Restart libvirtd or reload its configuration after changes to qemu.conf, livirtd.conf or changes to XML-definition files for VMs

Changes of the file “/etc/libvirt/qemu.conf” or “/etc/libvirt/libvird.conf” require that the libvirtd daemon is restarted or forced to reload its configuration. The same is true for any changes of
XML-definition files for VMs located in “/etc/lbvirt/qemu/”. (We will change such files later on). According to the man page sending a SIGHUP signal to the daemon will enforce a reload of the configuration. You can indirectly achieve this by the commands

rclibvirtd reload [on Opensuse systems)
or
systemctl reload libvirtd [any system with systemd]

But: Any libvirt or qemu changes will NOT affect already running VMs. You have to stop them, then restart libvirtd, reload the daemon’s configuration and restart the VMs again.

Preparational step C: Configure the VM to use a Spice-console – and some other devices

Ok, let us prepare our VM for “Method 1”. As we are in a libvirt environment we could use virt-manager to perform the required Spice configuration (see the image in the first article) . But we can also directly edit the XML configuration file “/etc/libvirt/qemu/debianx.xml” – assuming that you already have a working configuration for your VM. You need to be root to edit the files directly. See the restrictive access rights of the domain definition files

-rw------- 1 root root   4758 Mar  8 13:33 debianx.xml

By the way: A detailed description of possible parameter settings is provided at https://libvirt.org/formatdomain.html. Search for Spice and qxl …..

Regarding “Method 1” I use the following settings. The listing below only gives you an excerpt of the XML domain file, but it contains the particularly relevant settings for “graphics” (can be looked upon as a display device) and “video” (an be interpreted as a kind of virtual graphics card):

Excerpts from a libvirt domain definition XML file

   
   <interface type='network'>
      <mac address='52:54:00:93:38:4c'/>
      <source network='os'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
   ...
   <graphics type='spice' port='20001' autoport='no' listen='0.0.0.0' keymap='de' >    
      <listen type='address' address='0.0.0.0'/>
      <image compression='off'/>
    </graphics>
   ... 
    <sound model='ich6'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </sound>
    ...
    <video>
      <model type='qxl' ram='262144' vram='65536' vram64='2097152' vgamem='65536' heads='4' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
...

Parameters which affect general qemu-related properties (as e.g. the “listen”-settings) will overwrite the settings in “qemu.conf”. The choice of the PCI slot numbers may be different for your guest.

You see that I defined a network (!) port for the VM by which we can access the Spice console data stream directly. I have changed this port from the default “5900” to “20001”.

You should be aware of the fact that this sets a real network port on the KVM host – i.e. a network stack is invoked when accessing the Spice console. As indicated above we can avoid the superfluous network operations by directly working with a Unix socket (Method 2), but this is the topic of the next forthcoming article.

Regarding network port definitions for a Spice console three rules apply:

Each of the VMs defined requires its own individual port !
Firewalls between the client and the VM have to be opened for this port. This includes local firewalls on the VM, on the KVM host (with rules that may apply to virtual bridges, on the client system and on any network
components in between.
A TLS port has later to be configured in addition if you deactivated the “autoport” functionality – as we have done in the example above. I shall describe how to set the TLS port in a forthcoming article.)

The individual port definitions already imply the provision of a URI with port specification when starting remote-viewer (see below).

Let me briefly comment on the QXL-settings:

The QXL configuration shown above allows for 4 so called “heads” (or connectors) of the virtual graphics device. These heads support up to 4 virtual screens, if requested by the Spice-client. Note that the situation is different from real hardware consoles:
The (Spice) client (here remote-viewer) defines the number of screens attached to the VM’s console by a number of Spice client windows opened on the user’s desktop on the KVM host. The dimensions of these Spice client windows determine the dimensional capabilities of the virtual “screens”.

How the virtual screen resolution is handled afterwards may depend on the user’s own desktop resolution (on the KVM host or a remote system) AND the display settings of the VM’s guest system’s own tools for screen management. Today these are typically tools integrated into the guest’s graphical desktop (KDE, Gnome, XFCE) itself. Present Gnome and KDE5 desktops on the VM’s guest Linux system automatically adapt to the virtual display dimensions – i.e. the Spice window dimensions. But a XFCE desktop on the guest may behave differently; see below.

A short note also on the network settings for our test VM:
A virtual machine will normally be associated with a certain type of virtual network. At least if you want to use it for the provision of services or other network or Internet dependent tasks. You can configure virtual networks with virt-manager (menu “edit” >> “connection details”); but you must be root to do this:

In my case I prefer a separate virtual network for which we need routing on the KVM host. This allows us to configure restrictive firewall rules – e.g, with netfilter on the host. It even allows for the setup of virtual VLANs – a topic which I have extensively covered in other article series in this blog. And when required we just can stop routing on the host.

Guest requirements
Note that the QXL-configuration must also be supported on the VM guest itself: You need a qxl-video-driver there – and it is useful to also have the so called spice-vdagent active (see the my referenced series about a qxl-setup in the last article). On the guest system this requires

the installation of the “spice-vdagent” package and the activation of the “spice-vdagent.service” (both on Debian/Kali and Opensuse guest systems) ,
the installation of the packet “xserver-xorg-video-qxl” on a Debian/Kali-guest or “xf86-video-qxl” on an Opensuse guest

Present Debian, Kali or Opensuse operative system on the KVM/Qemu guest VM should afterward automatically recognize the QXL-video-device and load the correct driver (via systemd/udev).
Regarding the (virtual) network device on the VM itself you must use the guest system’s tools for the configuration of NICs and of routes.

Preparational step D: Starting the VM – and “Where do I find logs for my VM”?

I assume that you as user “uvma” are logged in to a graphical desktop session on your KVM host “MySRV”. If you are not
yet a member of the libvirt-privileged group, you may need to use sudo for the next step. On a terminal window you then enter “virt-manager &”, select our VM “debianx” and boot it.

If you look at the process list of your KVM host you may find something like:

qemu     17662  5.5  6.8 15477660 4486180 ?    Sl   18:11   2:29 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=debianx,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-debianx/master-key.aes -machine pc-i440fx-2.9,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Skylake-Client -m 8192 -overcommit mem-lock=off -smp 3,sockets=3,cores=1,threads=1 -uuid 789498d2-e025-4f8e-b255-5a3ac0f9c965 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=33,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -blockdev {"driver":"file","filename":"/virt/debs/debianx.qcow2","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null} -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=libvirt-2-format,id=virtio-disk0,bootindex=1,write-cache=on -device ide-cd,bus=ide.0,unit=0,id=ide0-0-0 -netdev tap,fd=35,id=hostnet0,vhost=on,vhostfd=36 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:93:38:4c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=37,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=20001,addr=0.0.0.0,disable-ticketing,plaintext-channel=default,image-compression=off,seamless-migration=on -k de -device qxl-vga,id=video0,ram_size=268435456,vram_size=67108864,vram64_size_mb=2048,vgamem_mb=64,max_outputs=4,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x9 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

You see that the user “qemu” started the qemu-process by calling “/usr/bin/qemu-system-x86_64” and adding a bunch of parameters. You may identify some parameters which stem from the settings in libvirt’s XML definition file for our special the VM (or “domain”).

Afterwards, have a look at connections with
netstat on the host; you should see that something (qemu) listens on the defined Spice port of the VM:

MySRV:/etc/libvirt/qemu # netstat -a -n | grep 20001
tcp        0      0 0.0.0.0:20001           0.0.0.0:*               LISTEN
...

Regarding logs of the VM for error analysis: You will find them in the directory ” /var/log/libvirt/qemu” (on an Opensuse Leap system).

Method 1: Local access to the Spice console with remote-viewer

Now, we are prepared to test a local access to the Spice console with remote-viewer. (As we work via a network port you may still need to open the Spice port on a local firewall – it depends of how you configured your firewall.) The format of the URI we have to specify for remote-viewer is

spice://FQDN_OR_IP:PORT_NR

with

FQDN_OR_IP: You have to present a host address which can be resolved by DNS or a directly an IP-address.
PORT_NR: The port for the Spice service – here “20001”.

For our setup this translates to

spice://localhost:20001

and thus the command

remote-viewer spice://localhost:20001

As user “uvma” we enter this command in another terminal window of our graphical desktop on the KVM host :

uvma@MySrv:~> remote-viewer spice://localhost:20001

(remote-viewer:22866): GSpice-WARNING **: 12:43:58.150: Warning no automount-inhibiting implementation available

Just ignore the warning. Then you should get a window with a graphical display of some login-screen on the VM. Details depend of course on the configuration of your VM’s operative system. In my case, I get the “gdm3”-login-screen of my virtualized Kali system:

The desktop-manager may be a different one on your system. After a login to a Gnome desktop I use remote-viewer‘s menu to open a 2nd screen:

and get two resizeable screen-windows :

As expected! When we change the dimensions the desktop of the VM adapts to the new virtual screen sizes. Just try it out.

Will this work with a KDE desktop on the Kali guest, too? Yes, it does. KDE5 and Gnome3 can very well coexist on a Kali, Debian or Opensuse Leap15.2 (guest) system! For a Kali system you find information how to install multiple graphical desktop environments e.g. at the following links:
install-kali-linux,
kde-environment-configuring-in-kali,
kali switching-desktop-environments.

The next image shows the transparency effect of a moving terminal window on a KDE desktop of the same Kali VM – again with 2 Spice screens requested by remote-viewer:

Such effects, which can also be configured on Gnome, require an active compositor on the guest’s desktop. At least when working locally on a KVM host I never got any problems with the performance of QXL/Spice and remote-viewer with an active compositor on the guest’s Gnome, KDE, and XFCE-desktops (without OpenGL acceleration). This is a bit different on a remote system and using remote-viewer over a LAN connection; see the next articles.

KDE and Gnome desktops on the VM automatically adapt to the sizes of the virtual screens. XFCE does not … XFCE is the present default desktop on Kali; so I installed after a distribution upgrade. Here some remote-viewer hints for XFCE fans on a VM with Kali/Debian and XFCE:

Set the number of screens in remote-viewer to 1. After installing XFCE with ” sudo apt update && sudo apt install -y kali-desktop-xfce” and a reboot we can choose “XFCE-Session” on a button of the gdm3-screen (after having entered the username). It will the boot into a XFCE session.
Then with the setting tool you can configure fixed resolutions for the screen displays (see below).
Or: Just deactivate a virtual display, resize the respective window on your host’s desktop and reactivate the virtual display again in your XFCE guest. XFCE then automatically recognizes the new screen size and adapts.
When logging out choose an option to save the desktop.

Unfortunately, XFCE has no seamless coexistence with KDE or Gome on Kali, yet. The following sequence of steps may fail:
1) Log out of a XFCE desktop-session, 2) choose a KDE or Gnome session afterwards /(this works without rebooting via the gdm menu), 3) log out of KDE/Gnome again and 4) try to restart a XFCE desktop.
On my Kali guest (on an Opensuse KVM host) I always have to reboot the guest to get a working XFCE session again, even if I did not change the screen dimensions during the KDE/Gnome session .. 🙁

Netstat reveals multiple connections corresponding to Spice channels

Using remote-viewer with a netowrk port is a really simple exercise. Most of the text above was spend on looking at the general virtualization environment. But, actually, the situation behind the scenes is not so simple. When we use netstat again, we get the following:

  
MySRV:/etc/libvirt/qemu # netstat -a -n | grep 20001
tcp        0      0 0.0.0.0:20001           0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:20001         127.0.0.1:46738         ESTABLISHED
tcp        0      0 127.0.0.1:20001         127.0.0.1:46750         ESTABLISHED
tcp        0      0 127.0.0.1:46734         127.0.0.1:20001         ESTABLISHED
tcp        0      0 127.0.0.1:46750         127.0.0.1:20001         ESTABLISHED
tcp        0      0 127.0.0.1:20001         127.0.0.1:46742         ESTABLISHED
tcp        0      0 127.0.0.1:46738         127.0.0.1:20001         ESTABLISHED
tcp        0      0 127.0.0.1:46740         127.0.0.1:20001         ESTABLISHED
tcp        0      0 127.0.0.1:46748         127.0.0.1:20001       
  ESTABLISHED
tcp        0      0 127.0.0.1:20001         127.0.0.1:46740         ESTABLISHED
tcp        0      0 127.0.0.1:20001         127.0.0.1:46734         ESTABLISHED
tcp        0      0 127.0.0.1:20001         127.0.0.1:46728         ESTABLISHED
tcp        0      0 127.0.0.1:20001         127.0.0.1:46744         ESTABLISHED
tcp        0      0 127.0.0.1:46728         127.0.0.1:20001         ESTABLISHED
tcp        0      0 127.0.0.1:46742         127.0.0.1:20001         ESTABLISHED
tcp        0      0 127.0.0.1:20001         127.0.0.1:46748         ESTABLISHED
tcp        0      0 127.0.0.1:46744         127.0.0.1:20001         ESTABLISHED

We find many, namely eight (8), active established connections. What do these connections correspond to? Well, they correspond to individual data exchange channels; I quote from
https://libvirt.org/formatdomain.html#video-devices:

“When SPICE has both a normal and TLS secured TCP port configured, it can be desirable to restrict what channels can be run on each port. This is achieved by adding one or more elements inside the main element and setting the mode attribute to either secure or insecure. Setting the mode attribute overrides the default value as set by the defaultMode attribute. (Note that specifying any as mode discards the entry as the channel would inherit the default mode anyways.) Valid channel names include main, display, inputs, cursor, playback, record (all since 0.8.6 ); smartcard ( since 0.8.8 ); and usbredir ( since 0.9.12 ).”

Testing the “one seat situation” at a Spice console

Now its time to test what I claimed in the last article: The Spice console can be accessed only by one user at a time. Let us assume, that user “uvma” is a member of the libvirt-group. Let us in addition create another user “uvmb” which is member of the group “users” on the host, only. I assume that “uvma” has opened a graphical desktop session on the KVM host (MySRV). E.g. a KDE session.

Step 1: As user “uvma” start virt-manager and boot your VM “debianx”. On a terminal window (A) use remote-viewer to open the Spice console of the VM with 2 screens. Log into a graphical desktop of the VM.

Terminal A:

uvma@MySRV:~> remote-viewer -v  spice://localhost:20001
Guest (null) has a spice display
Opening connection to display at spice://localhost:20001

(remote-viewer:20735): GSpice-WARNING **: 18:21:31.344: Warning no automount-inhibiting implementation available

Step 2: On your host-desktop open another terminal window (N) and login via “su – uvmb” as the other user. As “uvmb” now enter “remote-viewer spice://localhost:20001“.

uvma@MySRV:~> su - uvmb
Passwort: 
uvmb@MySRV:~> remote-viewer -v  spice://localhost:20001

This will at once close the open two Spice windows and after a blink of a second open up one or two new Spice windows again. The effect is clearly visible.

On terminal A we get:

Guest debianx display has disconnected, shutting down
uvma@MySRV:~>

On terminal B we get a lot of warnings – but still the spice windows open in exactly the same status as we left them.

uvmb@MySRV:~> remote-viewer -v  spice://localhost:20001

(remote-viewer:20903): dbind-WARNING **: 18:25:40.853: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Guest (null) has a spice display
Opening connection to display at spice://localhost:20001

(remote-viewer:20903): GSpice-WARNING **: 18:25:40.936: PulseAudio context failed Verbindung verweigert

(remote-viewer:20903): GSpice-WARNING **: 18:25:40.936: pa_context_connect() failed: Verbindung verweigert
Cannot connect to server socket err = Datei oder Verzeichnis nicht gefunden
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
AL lib: (EE) ALCplaybackAlsa_open: Could not open playback device 'default': Keine Berechtigung

(remote-viewer:20903): GLib-GObject-WARNING **: 18:25:40.962: g_object_get_is_valid_property: object class 'GstAutoAudioSink' has no property named 'volume'
AL lib: (EE) ALCplaybackAlsa_open: Could not open playback device 'default': Keine Berechtigung

(remote-viewer:20903): GLib-GObject-WARNING **: 18:25:40.964: g_object_get_is_valid_property: object class 'GstAutoAudioSrc' has no property named 'volume'
AL lib: (EE) ALCplaybackAlsa_open: Could not open playback device 'default': Keine Berechtigung
AL lib: (EE) ALCcaptureAlsa_open: Could not open capture device 'default': Keine Berechtigung

(remote-viewer:20903): GSpice-WARNING **: 18:25:41.015: record: ignoring volume change on audiosrc

(remote-viewer:20903): GSpice-WARNING **: 18:25:41.018: record: ignoring mute change on audiosrc

(remote-viewer:20903): GSpice-WARNING **: 18:25:41.021: Warning no automount-inhibiting implementation available

(remote-viewer:20903): GSpice-WARNING **: 18:25:41.052: playback: ignoring volume change on audiosink

(remote-viewer:20903): GSpice-WARNING **: 18:25:41.052: playback: ignoring mute change on audiosink

The warnings are mainly due to the fact that user “uvmb” has no rights to access the Pulseaudio context of the desktop of user “uvma”. (I take care of Pulseaudio in one of the next articles …) At the first switch between the users you may only get one Spice window as “uvmb”. Choose two screens then. Afterwards you can switch multiple times between the users uvma and uvmb. Two windows get closed for the user with present Spice console session, two windows are opened for the requesting user, and so on.

Conclusion: “uvmb” and “uvma” can steal each other the Spice console with remote-viewer as and when they like.

By the way: A Spice console can be left regularly by a user by just closing the Spice client window(s). Note that this will not change the status of your desktop session on the host! This is left open – with all consequences.

Restricting access by setting a password

Let us prevent being thrown of the “seat” in front of our Spice console. As root change the <graphics> definition in VM’s definition file to

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

If you haven’t noticed: The relevant difference is the “passwd” attribute. You could have added this setting via virt-manager, too. Try it out.

Shut down and restart your VM. Any user that now wants to access the Spice console using “remote-viewer spice://
localhost:20001” will be asked for a password. You yourself, too, if you close the console and try to reopen it.

Regarding security: The password transfer will to my understanding be AES encrypted. See Daniel P. Berrangé’s blog https://www.berrange.com/posts/2016/04/01/improving-qemu-security-part-3-securely-passing-in-credentials/. But as long as the rest of the data exchange with the VM is not encrypted, this precaution measure won’t help too much against ambitioned attackers.

Conclusion

Using remote-viewer locally on a KVM host in combination with a network port to access a VM’s graphical Spice console is easy and convenient. It requires a minimum of settings. In addition it offers up to four virtual screens which you can open via a menu.
However, using a network port implies security risks. You should think about proper counter-measures first if you want to lean on “remote-viewer”. Once configured in the way described above there is no libvirt-layer or anything else which may hinder ambitious attackers to analyze the unencrypted data flow between the Spice client and the VM through the host’s network port.

In the next article

KVM/Qemu VMs with a multi-screen Spice console – III – local access with remote-viewer via a Unix socket

I want to show you how one can configure the VM such that remote-viewer can access the Spice console via a local Unix port. A network port is not opened in this approach. Security is none the less hampered a bit as we have to give a standard user some rights which normally only the “qemu” group has. But we shall take care of this aspect by using ACLs.

Links

Virtualization on Opensuse
https://doc.opensuse.org/ documentation/ leap/ virtualization/ single-html/ book.virt/index.html

Libvirtd daemon
https://www.systutorials.com/docs/linux/man/8-libvirtd/

Libvirt connection URIs
https://libvirt.org/uri.html

Find the Spice URI to use
https://access.redhat.com/ documentation/ en-us/ red_hat_enterprise_linux/7/ html/ virtualization_deployment_and_ administration_guide/ sect-Domain_Commands- Displaying_a_URI_ for_connection_to_a_graphical_display

TLS disabled
https://unix.stackexchange.com/ questions/ 148794/ how-to-create-kvm-guest-with-spice-graphics-but-tls-disabled-using-virt-install

General Kali installation
https://www.cyberpratibha.com/blog/how-to-update-and-upgrade-kali-linux-to-latest-version/

KDE, XFCE on Kali
https://technicalnavigator.in/kde-vs-xfce-which-one-is-better/

KVM/Qemu VMs with a multi-screen Spice console – I – Overview over local and remote access methods

Posted on 26. February 2021 by eremo

KVM/Qemu based virtual machines [VMs] are a nice and comfortable part of my life with Linux. I use them both as dedicated entities for various services on a server host and as experimental test or work environments on my Linux workstation. Whereas the access to server VMs was dominated by SSH connections and CLI interaction so far, working with VMs on my PC was and is is characterized by graphical user-interfaces.

In the latter case we speak of desktop-virtualization: Connections to the virtual guests are set up locally via sockets (or via a network port over device “lo”) on the very same PC or workstation which also serves as KVM host. Supported by a client/server model for graphics, KVM/Qemu provides multiple capable methods for the local display of the graphical output of a VM. And by graphical output I mean a desktop environment as KDE, XFCE or Gnome.

For KVM/Qemu the combination of the so called

“Spice display” and the Spice protocol
with drivers for potent virtual video devices (as QXL or Virtio)

offers a very convenient solution for the presentation of a VM’s graphical desktop with high performance – which, in my experience, is considerably faster than most VNC variants.

In addition:
With the help of certain Spice clients one can access a local VM via a desktop display which extents over up to four “screens“. All of these “screens” are displayed within scalable windows of your preferred basic desktop environment on your Linux machine – e.g. KDE, LXDE. This means that you can graphically work with a full fletched KDE desktop of the VM displayed in multiple windows within a KDE or Gnome environment on your local KVM/Qemu host (e.g your Linux workstation).

Can we get this comfort also with remote connections over a LAN? With encryption tunnels? The answer is yes – and related Qemu and Libvirt configurations are the main topics of this article series.

Why do I write about these subjects, at all? Recently, I needed to work with a KVM/Qemu guest remotely on an Opensuse Leap 15.2 server. I wanted to use a SSH tunneled connection with password authentication for a special graphical Spice client, namely “virt-viewer“. Being a bit naive, I ran into some major trouble. This in turn forced me to look closer at different possibilities for remote connections to KVM/Qemu based VM. Unfortunately, I found Opensuse’s documentation on Spice sparse – to say the best. But Spice gets especially interesting and somewhat complex with remote access methods, encryption and authorization.

In this article series I discuss some of the multiple configuration options I have experimented with. I restrict myself to Spice based solutions with the clients “virt-viewer“, “remote-viewer” and also “virt-manager“. In combination with SSH, TLS. I hope my experiences help other Opensuse Leap users to set up convenient remote solutions.

After giving some documentation links, I start with an overview over some selected remote access scenarios which are available. They are the most important ones and are all based on network ports. But, in the coming posts I will cover local access scenarios based on Unix sockets, too. And their combination with SSH.

Limitations

Unfortunately, I have to reduce expectations of readers who are out for “multi-user remote desktop solutions”. This is not what the present Spice solutions with the named clients will offer you. See below.

A topic which I will not address in the forthcoming articles is the setup of a local VM with OpenGL acceleration on the graphics device of the KVM host. With Nvidia cards and drivers this is
unfortunately a mess – and it is Nvidia’s fault, in my opinion. Very similar, by the way, to Nvidia’s EGL-based solution attempt for Wayland. All of this because of their own OpenGL handling and their declined support for GBM. So, let us not go there to avoid frustration …

Basic preparations of a KVM/Qemu VM: Documentation and guides?

I assume that you are already familiar with the basic set up and configuration of a KVM/Qemu based virtual machine – e.g. with virsh or virt-manager. If not, you will find valuable hints for Opensuse Leap systems in SuSE’s “Virtualization Guide”

However, as said above, Opensuse’s documentation on virtualization does not give you much information about Spice. We only get a glimpse of it at the sections on “virsh” and “Qemu“. The information is rather spurious there; one doesn’t get a broader context. You may get a better understanding by reading introductory pages on the site “https://www.spice-space.org/“, especially the user manual
https://www.spice-space.org/spice-user-manual.html.
Regarding special configuration settings of a VM, see https://libvirt.org/formatdomain.html.

Spice with multiple screens requires a non default configuration of the VM’s QXL device

For a basic Spice setup there is not too much to do; “just” choose Spice for the display-settings of your VM and configure the VM’s QXL graphics device. Such a device corresponds to something like a virtual graphics card. Well, it sounds easy, but when I tried it myself, I had to experiment. To help others a bit: I have already discussed in depth how we can configure a KVM/Qemu guest and its QXL device such that it supports multiple scalable high-resolution screens for Spice clients. See the following articles:

KVM/qemu mit QXL – hohe Auflösungen und virtuelle Monitore im Gastsystem definieren und nutzen – I
KVM/qemu mit QXL – hohe Auflösungen und virtuelle Monitore im Gastsystem definieren und nutzen – II
KVM/qemu mit QXL – hohe Auflösungen und virtuelle Monitore im Gastsystem definieren und nutzen – III
KVM/qemu mit QXL – hohe Auflösungen und virtuelle Monitore im Gastsystem definieren und nutzen – IV

These posts were written in German; but with a little bit of goodwill one can understand the configuration settings and related commands.

An alternative today is to use a “virtio” video device in the VM’s configuration. I shall come back to this point in a later article.

What I did not cover in my previous posts on Spice was the broader spectrum of access options to a KVM/Qemu-based VM with libvirt/Space clients – both regarding local and remote connections. I only discussed how to use the “remote-viewer” client locally – despite the fact that its name already indicates something else. What I also disregarded in my articles in 2017 is the fact that
there are various (remote) access methods – direct ones and some through a libvirt-layer on the KVM-host. As always with Linux there are multiple ways to achieve your objectives :-).

However, when we use Spice instead of VNC we speak about a “one person” or a “one seat” solution.

Spice and libvirt => multiple methods to access exactly one graphical console of a KVM/Qemu based VM

What you should be aware of when you think of using Spice for a graphical access to a KVM/Qemu VM is the following:

1. The Spice protocol and the Spice display for KVM/QEMU based VMs do NOT provide a multi-user service for graphical remote terminals or remote desktop displays – at least not in their default configuration.

According to what I have read, anything in this direction still seems to be experimental. Instead:

2. We access a data stream describing the graphical contents of one or multiple screens of a console which is virtually “attached” to the VM.

Let us call this device a multi-screen Spice console of the VM.

The Spice console solution is fully integrated into the QEMU-emulator. The console screen data and related sound can, however, also be displayed and played on a remote Linux system. And here we face a point which makes the user’s life both convenient and complex at the same time :

3. The Spice console of a VM can be accessed by various protocols or protocol combinations. The Spice console is fully integrated with Qemu and directly accessible there via a (network) socket, but it is in addition accessible via libvirt components. This leads to a variety of connectivity options.

These aspects can be underestimated: Remote access for multiple screen requires sufficient band-width of the network. The second point excludes the application of Spice for multi-user scenarios. The third point opens up a range of local and remote access possibilities – some are more complicated to configure, some are more secure than others. Some options are deactivated in a default libvirt installation (not only on Opensuse Leap systems).

The most important connection options for standard libvirt/spice clients are summarized in the following schematic drawing.

The Spice console of a KVM/Qemu VM

The graphics shows a Linux KVM host at its center. KVM supports the VM emulator QEMU in the Linux kernel – thus making QEMU fast. Two virtual machines VM1 and VM2 are shown. VM1’s configuration includes a Spice (console) display – e.g. set up according to the following excerpt of a configuration example for a VM (done with virt-manager):

Note that the configuration item is called “display” in virt-manager (and “graphics” in the XML-configuration of a VM). I think that in the case of Spice “Console” would have been a better name. I should also warn you that the displayed configuration may lead to security risks – if not accompanied by protective measures.

Note also that “virt-manager” does not allow for a detailed QXL-configuration required for multiple screens on the displayed dialog. But you can edit the XML-files of the VM for this purpose via the second tab (or an editor;
you find the XML-files for VMs in the directory “/etc/libvirt/qemu” on Opensuse Leap systems):

The QXL configuration displayed here is an example – you may choose other parameters. (Or test out a “virtio” device; see a later article).

“One seat” console
In the lower right part of the first sketch above I have tried to express that a graphical Spice console corresponds to a “one console with one seat” situation. The console is only available for exactly one (authorized) user at a time. Note:

Any user having sufficient access rights may any time claim the console and throw you off the seat in front of the graphical console screen, if you do not secure the access to the console by a password (or other measures)!

We did not do this in the configuration example above; see the empty field for the password. I quote from the documentation:

“Spice does not support multiple connections to the same QEMU instance by default. So anybody who will connect to the same host and port can simply take over your session. You can solve this problem by using ticketing.” (see: https://www.spice-space.org/spice-user-manual.html)

“Ticketing” means setting a password to access the VMs console screen; but still anyone knowing the password could claim the console – a password is no real solution for a multi-user situation. To say it clearly:

If your objective is to establish something like a multi-user graphical access to a KVM/QEMU-based virtual machine with a full desktop display for each user (i.e. a “remote desktop solution”), then think about something like a headless graphical server configuration of the KVM guest. On a Linux VM, you can achieve this by either implementing a X2GO server, a commercial NoMachine server, a VNC server-variant or even XRDP. Some of these solutions can easily be combined with SSH.
And do not forget: In a LAN with sufficient bandwidth “ssh -X” may already serve most practical purposes.

But in many cases a local or remote “one seat situation” with a full graphical desktop may be sufficient. Now, let us look at the other parts of the drawing.

Different access options to the Spice console of a KVM/Qemu-based VM

There is a multitude of options to connect to the Spice console (https://www.spice-space.org/spice-for-newbies.html). We shall describe them briefly in this first article. In forthcoming articles we shall have a closer look at each of them.

Option 1: Simple connection with “remote-viewer” via a Spice (network) port

The Qemu-emulator is able to handle requests over the Spice protocol on its own, i.e. without the invocation of special libvirt-support. The Spice solution offers connections to the console either on the basis of a pure Unix socket (local solution) or a network port (remote solution).

A network oriented solution, which can be realized with the Spice client “remote-viewer” is depicted on the left side of our central sketch:

You access the Spice console of a specific VM directly via a specific network port. Spice ports have to be configured independently for each of the VMs. I.e., if you have 2 VMs whose Spice consoles you want to access independently then you need to define two different ports for the Spice consoles. Actually, you won’t be able to start a VM which has the same port associated with its Spice console as another already running VM.

nProperties of a remote-viewer connection over a network port:

Default port? The standard Spice port is 5900 (which is also the port used by VNC). In the example displayed above I instead used port 20001. (Do not forget to open your firewalls for your chosen ports!)
Security by encryption? The connection to the port is not secured by any encryption. However, it is possible to define an additional specific TLS-secured port. We shall cover spice + TLS protocol combinations in another article.
User authentication on the KVM server host? Can optionally be achieved via SASL.
Preferred Spice client? The Spice client which uses the Spice protocol directly and without libvirt is “remote-viewer“.
Works locally and/or remotely? Both.

Some additional hints:

In some old articles or posts on the Internet you may find descriptions of “virt-viewer” together with URIs like “spice://host:5900”. This does not work any more – at least on my systems.

By setting proper attributes to the VM, we can in addition enforce that it only accepts secured connections. For those who are eager to experiment already: Where do we learn something about such machine specific settings in XML-format? The answer is:
https://libvirt.org/formatdomain.html

Option 2: Connection with “virt-viewer” or “virt-manager” via libvirtd and a defined TCP port

Besides “remote-viewer” there is another Spice client called “virt-viewer“. This client is of special use when you work on a KVM host with multiple VMs. What some admins do not know is that it can be used via a simple socket with a specific TCP-port. You do not need SSH or TLS, if you can disregard security. This corresponds pretty much to what we got with remote-viewer and a Spice port. The difference is that we access the socket via the mediation of libvirtd components:

virt-viewer requires URIs which specify the target hypervisor for the libvirtd daemon – in our case “qemu”. Such URIs differ from URIs used for remote-viewer as they always contain a two fold protocol definition.

We shall apply such URIs in a later article. In addition this access method requires a special (non-default) configuration of the libvirt-daemon. Among other things, you, of course, have to define the port. The ability to listen to an insecure TCP port is normally deactivated in the libvirtd configuration; we have to activate it manually. This is something we shall have a closer look at.

Unencrypted access to the Spice console via a special libvirtd port may be a useful solution for KVM guests sitting in a secured physical LAN-segment or behind a virtual bridge/firewall in a virtualized LAN-segment of the KVM host.

Properties of a virt-viewer connection via a TCP port

Default port? 16509.
Security by encryption? The connection to the port is not secured by any encryption. However, we have other options for virt-viewer to connect to the VM via SSH or TLS secured connections. See below.
Preferred Spice client?: virt-viewer (You cannot provide a valid URI to remote-viewer this way). However, this connection option also works with “virt-manager” (and its included graphical access to the Spice console).
User authentication? Can be achieved via SASL.
Works
locally and/or remotely? Both.

on the KVM host.
Note that the access to libvirtd must be allowed for the user invoking the connection! This can be configured on Opensuse Leap systems by some policy and/or libvirtd settings.

Option 3: Connection with “virt-viewer” or “virt-manager” via SSH and libvirtd

A very convenient method to get a secure connection with Linux is to use SSH encryption. Therefore, we are not astonished to find that “virt-viewer” can be combined with SSH. This connection method also requires a special URI-format. And again: access to libvirtd must be allowed for the user using this type of connection.

Properties of a virt-viewer connection via a SHH port:

Default port? 22 or otherwise the defined SSH-port on your system.
Security by encryption? SSH.
Preferred Spice client?: virt-viewer (You cannot provide a valid URI to remote-viewer this way). However, this connection option also works with “virt-manager” (and its included graphical access to the Spice console).
User authentication? Via SSH (preferably public-key authentication)
Works locally and/or remotely? Both.

Both options 2 and 3 work with virt-manager, too. However, virt-manager does not provide you with a multi-screen access to the Spice console.

Note that a combination of SSH and remote-viewer is also possible; but then you would open a “SSH -X” connection first and run remote-viewer on the KVM/Qemu host and not on the network client system. I will present such a solution in a later article, too.

Conclusion

The Spice console of KVM/Qemu offers access to a graphical desktop of a virtual machine guest. Spice clients as “remote-viewer”, “virt-viewer” and “virt-manager” can be used locally and remotely. The first two clients offer multiple screens – but all clients provide a one seat solution, only. This may, however, be sufficient for many use cases. There is a variety of local and remote access methods. Connections can be secured by TLS or SSH encryption.

In the next article

KVM/Qemu VMs with a multi-screen Spice console – II – local access with remote-viewer via a network port

I shall have a closer look at a local connection from the “remote-viewer” client to the Spice console of a VM.

Links

Spice console and Spice protocol
https://linuxhint.com/ configure_ spice_server_ debian_10/
https://www.spice-space.org/ spice-user-manual.html
https://www.spice-space.org/ spice-for-newbies.html

Activate spice
https://www.linux-kvm.org/page/SPICE
https://linux-blog.anracom.com/2017/08/15/kvmqemu-mit-qxl-hohe-aufloesungen-und-virtuelle-monitore-im-gastsystem-definieren-und-nutzen-iv/
https://octetz.com/docs/2020/2020-05-06-linux-hypervisor-setup/

Nvidia 🙁
https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API

Further
articles in this series

KVM/Qemu VMs with a multi-screen Spice console – VIII – VM and user specific restrictions for remote-viewer connections – iptables and sudo
KVM/Qemu VMs with a multi-screen Spice console – VII – remote-viewer, qemu and SASL authentication
KVM/Qemu VMs with a multi-screen Spice console – VI – remote access with remote-viewer and TLS encryption
KVM/Qemu VMs with a multi-screen Spice console – V – remote access via remote-viewer, a network port and a SSH-tunnel
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

Opensuse Leap, KVM/QEMU-guests, KMS – problems with QXL/Spice after upgrade to Leap 15

Posted on 10. March 2019 by eremo

Many services in my LAN are provided by virtual KVM/QEMU-guests of a dedicated KVM-server-host. More special services are provided by local KVM-guests on Workstations. All my virtualized systems get normally equipped with a qxl/spice-combination to provide a graphical interface – which can be used on the KVM-host or by remote spice clients. A direct graphical access via a spice client is required only seldomly (besides ssh connections) – but in some cases or situations it is useful, if not mandatory.

Recently, I upgraded both the central KVM-Server, its guests and also guests on workstations from Opensuse Leap 42.3 to Leap 15.0. Unfortunately, after the upgrade no graphical access was possible any longer to my guest-systems via spice-clients (as virt-viewer or the graphical spice-console of virt-manager).

After some tests I found out that this was due to missing KMS on the guest systems – present qxl-modules, however, do require KMS. But, if you update/install from an ISO image “KMS” may not be compatible with the graphical SuSE installer. And due to previous configurations “nomodeset” may be a kernel parameter used in the installation before the upgrade. Here is the story …

The problem: Unreadable, freezing interfaces on spice-clients

Normally, I upgrade by a 5-step sequence: 1) Update all packets, 2) reduce repositories to the Update- and OSS-repository, 3) switch to the repositories of the new distribution, 4) “zypper dup –download-only”, 5) “zypper –no-refresh dup” (see e.g. how-to-upgrade-from-opensuse-leap-422-to-423/).

The KVM server-host itself gave me no major problem during its upgrade. Also the KVM-guests – with their server-services – seemed to work well. Most often, I access the KVM-guest-systems via ssh to perform regular administration tasks. So, I did not even notice for a while that something was wrong with the qxl/spice-configuration. But when I used “virt-manager” in an “ssh -X” session from my workstation to the KVM-server and tried to open the graphical console for a guest there, I got an unreadable virtual screen, which froze instantly and did no longer react to any input – special commands sent via “virt-manager” to switch to a non-graphical console terminal were ignored. The same happened with “virt-viewer” and/or when I executed virt-manager directly on the graphical screen of the KVM-server.

Independent test with a new installation of a “Leap 15”-guest-system

To find out more I tested a new installation of Leap 15 on my Leap 15 workstation as a KVM-server. I chose a guest system configuration with standard equipment – among other things qxl/spice-components. The installation was started via the “virt-installer” component of virt-manager. I used an ISO-image of the Leap 15 installation image.

First thing I stumbled across was that I had to use a “No KMS” for the text console setting on the first screen of the Opensuse installer (see the options for the graphical setup there; F3-key). Otherwise the installer froze during the first “udev” checks. I knew this effect already from installations on some physical systems. Note that the choice of “No KMS” leads to an kernel parameter entry “nomodeset” in the command line for the kernel call in the Grub2 configuration (see the file /etc/default/grub).

Such a full new installation lead into a void. SuSE’s graphical installer itself worked perfectly with high resolution. However, after a restart of the freshly installed guest-system the switch to the graphical screen lead to a flickering virtual screen and the graphical display of the SDDM login manager never appeared.

Still and luckily, it was possible to login as root and execute a “init 3” command – which brought me to a working, non-flickering ASCII console interface (TTY1).

I had experienced this
type of behavior before, too, on some real physical systems. I recommend Leap users to be prepared: activate ssh-services during installation and open the firewall for ssh-ports! The SuSE-installer allows for such settings on its summary screen for the installation configuration. This gives you a chance to switch to a working text console (init 3) from a remote SSH-command line – if the graphical console does not allow for any input.

Tests 2: Upgrade to latest KVM / QEMU / libvirt – versions of the “Virtualization” repository

An installation of the cutting edge versions of KVM/QEMU and spice sever and client software did not change anything – neither on my dedicated KVM-server-system and its upgraded guests nor on my workstation with the fresh Leap 15 test-guest.

Repair of the older upgraded guest-systems

The emulated “hardware” of my older (upgraded) guest-systems, which stem from an OS 13.2 era, is a bit different from the equipment of the newest test guest. On these older systems I still had the choice to use a cirrus, vga or vmwvga graphics. Interestingly, these drivers do not provide the performance of qxl – but they worked at least with the virtual spice client displays.

One central question was whether the QXL driver – more precisely the corresponding kernel module “qxl” – was loaded at all. Answer for the guests on the central KVM-server: No, it was not.

So, on the first guest I simply tried “modprobe qxl” – and hey – the module loaded. An “init 5” then gave me the aspired graphical screen.

Later I checked that actually no “nomodeset” parameter was set in these guests. So, something went “wrong” with the system’s startup-configuration during the upgrade procedure. I have no real clue why – as the qxl-module was loaded without problems on the previous Leap 42.3 installations.

For Opensuse Leap the wrapper-script “mkinitrd” transfers a running configuration with its loaded kernel modules via “dracut” into a suitable and permanent initramfs/initrd- and systemd-startup configuration. So, issue “mkinitrd” after a successful test of a qxl/spice-interface.

Repair of the freshly installed Leap 15 guest-system

On the freshly installed Leap 15 guest client on my workstation things were slightly different: The qxl-module did not load there. A “modinfo qxl” shows you parameters you can apply. The right thing to do there was to try

modprobe qxl modeset=1

This worked! Then I eliminated the “nomodeset”-parameter from the “GRUB_CMDLINE_LINUX_DEFAULT”-entry in the file “/etc/default/grub” and started “mkinitrd” to get a stable permanent startup-configuration (via dracut) which booted the guest into graphical mode afterwards.

Adjustment of the TTYs and KDE

As soon as you have a reasonable configuration, you may want to adjust the screen dimensions of the text consoles tty1 to tty6, the sddm-login-screen and the KDE or Gnome screen. These are topics for separate articles. See, however, previous articles in this blog on KVM guests for some hints.

For the text console TTYs try reasonable settings for the following entries in the “/etc/default/grub” – below e.g. for a resolution of “1680×1050”:

GRUB_CMDLINE_LINUX_DEFAULT=” …. OTHER PARAMETERS …… video=1680×1050″
GRUB_GFXMODE=”1680×1050″
GRUB_GFXPAYLOAD=keep

(see https://www.suse.com/de-de/support/kb/doc/?id=7017979)

Do not forget to execute “mkinitrd” again afterwards!

For KDE adjustments a user can use the command “systemsettings5” and then specify screen resolutions in the dialog for “display and monitors”.

Conclusion

The graphical installer of Opensuse, but also upgrade-procedures on working virtual KVM/QEMU guests with qxl/spice can lead to situations where KMS is or
must be deactivated both for physical and virtual systems. As a consequence the “qxl-module” may not be loadable automatically afterwards. This can lead to failures during the start of a graphical qxl/spice-interface for local and remote spice-clients.

The remedy is to remove any “nomodeset”-parameter which may be a part of the entry for “GRUB_CMDLINE_LINUX_DEFAULT” in the file “/etc/default/grub”.

For tests of the qxl-driver try loading the qxl-module with “modprobe qxl modeset=1”. After a successful start of a graphical interface use the command “mkinitrd” (whilst the qxl-module is loaded!) to establish a permanent configuration which loads “qxl” during system start.

KVM/qemu mit QXL – hohe Auflösungen und virtuelle Monitore im Gastsystem definieren und nutzen – III

Posted on 8. August 2017 by Ralph Mönchmeyer

In den ersten beiden Artikeln dieser Serie

hatte ich diskutiert, wie man das QXL-Device von Linux-Gastsystemen eines KVM/QEMU-Hypervisors für den performanten Umgang mit hohen Auflösungen vorbereitet.

Ich hatte zudem gezeigt, wie man mit Hilfe der Tools “xrandr” und “cvt” Auflösungen für Monitore unter einem X-Server einstellt.

Das funktioniert ganz unabhängig von Virtualisierungsaufgaben. So lassen sich u.U. auf Laptops und Workstations Auflösungen “erzwingen”, die trotz gegebener physikalischer Möglichkeiten der Grafikkarte und der angeschlossenen Monitoren nicht automatisch erkannt wurden. “cvt” nutzt man dabei zur Bestimmung der erforderlichen “modelines”.

“xrandr” funktioniert aber auch für X-Server virtualisierter Systeme – u.a. für Linux-Gastsysteme unter KVM/QEMU. Im Verlauf der letzten beiden Artikel hatten wir xrandr dann sowohl auf einem Linux-Virtualisierungs-Host wie auch in einem unter KVM/QEMU virtualisierten Linux-Gastsystem angewendet, um die jeweiligen KDE/Gnome-Desktops in angemessener Auflösung darzustellen.

Als praxisnahes Testobjekt musste dabei ein Laptop unter Opensuse Leap 42.2 herhalten, der mit KVM/QEMU ausgestattet war. Er beherbergte virtualisierte Gastsysteme unter “Debian 9 (Stretch)” und Kali2017. Ein relativ hochauflösender Monitor am HDMI-Ausgang (2560×1440) des Laptops konnte mit Hilfe von xrandr vollständig zur Darstellung der Gastsysteme genutzt werden, obwohl diese Auflösung vom Host nicht erkannt und nicht automatisch unterstützt wurde. Die grafische Darstellung des Gast-Desktops (Gnome/KDE) wurde dabei durch Spice-Clients auf dem Host und QXL-Devices in den virtuellen Maschinen ermöglicht.

Offene Fragen => Themen dieses Artikels

Eine Fragestellung an das bislang besprochene Szenario ist etwa, ob man mit hohen Auflösungen auch dann arbeiten kann, wenn die Spice-Clients auf einem anderen Linux-Host laufen als dem KVM-Virtualisierungshost selbst. Ich werde auf dieses Thema nur kurz und pauschal eingehen. Die Netzwerkkonfiguration von Spice und Libvirt werde ich bei Gelegenheit an anderer Stelle vertiefen.

Ergänzend stellte ein Leser zwischenzeitlich die Frage, ob man im Bedarfsfall eigentlich auch noch höhere Auflösungen für das Gastsystem vorgeben kann als die, die in einem physikalischen Monitor des Betrachter-Hosts unterstützt werden.

Für die Praxis ist zudem folgender Punkt wichtig:
Die bislang beschriebene manuelle Handhabung von QVT und xrandr zur Einstellung von Desktop-Auflösungen ist ziemlich unbequem. Das gilt im Besonderen für den Desktop des Gastsystems im Spice-Fenster. Wer hat schon Lust, jedesmal nach dem Starten eines Gastes “xrandr”-Befehle in ein Terminal-Fenster einzutippen? Das muss doch bequemer gehen! Wie also kann man die gewünschte Auflösung auf dem Betrachter-Host oder im virtualisierten Linux-Gastsystem persistent hinterlegen?

Noch idealer wäre freilich eine Skalierung der Auflösung des Gast-Desktops mit der Größe des Spice-Fensters auf dem Desktop des Anwenders. Lässt sich eine solche automatische Auflösungsanpassung unter Spice bewerkstelligen?

Der nachfolgende Artikel geht deshalb auf folgende Themen ein:

Auflösungen und Vertikalfrequenzen für den Desktop des KVM-Gast, die physikalisch am Host des Betrachters nicht unterstützt
werden.
Persistenz der xrandr-Einstellungen für den Gast-Desktop und den dortigen Display-Manager (bzw. dessen Login-Fenster).
Automatische (!) Auflösungsanpassung des Gast-Desktops an die Rahmengröße des Spice-Client-Fensters.

Zugriff auf virtualisierte Hosts über Netzwerke

Spice und libvirt sind netzwerkfähig! Siehe hierzu etwa http://www.linux-magazin.de/Ausgaben/2012/10/Spice. Das, was wir in den letzten beiden Artikeln bewerkstelligt haben, hätten wir demnach auch erreichen können, wenn wir xrandr nicht auf dem Virtualisierungshost selbst, sondern auf einem beliebigen Remote-Host zur Darstellung des Gast-Desktops in Spice-Fenstern eingesetzt hätten.

In den nachfolgenden Artikeln unterscheiden wir daher etwas genauer als bisher den “Linux-KVM-Host” vom “Host des Betrachters“. Letzteres liefert dem Anwender den “Desktop des Betrachters“, den wir vom “Desktop des virtualisierten Gastsystems” abgrenzen:

Auf dem “Desktop des Betrachters” werden Spice-Client-Fenster aufgerufen, über die der Anwender den Desktop des KVM-Gast-Systems betrachtet. Der “Linux-Host des Betrachters” kann also der KVM-Virtualisierungshost sein, muss es aber nicht. Die physikalisch mögliche Trennung zwischen dem Host, der den “Desktop des Betrachters” anzeigt, vom Linux-Host, auf dem ein Hypervisor das virtualisierte Gastsystem unterstützt, kommt in folgender Skizze zum Ausdruck:

Der Einsatz von Libvirt und Spice über ein Netzwerk erfordert allerdings besondere System-Einstellungen. Ich werde erst in einem späteren Artikel zurückkommen. Die weiteren Ausführungen in diesem Artikel sind im Moment daher vor allem für Anwender interessant, die virtualisierte Systeme unter KVM auf ihrer lokalen Linux-Workstation betreiben. Leser, die unbedingt jetzt schon remote arbeiten wollen oder müssen, seien darauf hingewiesen, dass X2GO nach wie vor eine sehr performante Alternative zu Spice darstellt, die SSH nutzt, einfach zu installieren ist und headless, d.h. ganz ohne QXL, funktioniert.

Auflösungen und Vertikalfrequenzen des Gastdesktops jenseits der Möglichkeiten eines (einzelnen) physikalischen Monitors

Aufmerksame Leser haben am Ende des letzten Artikels sicherlich festgestellt, dass die in den virt-manager integrierte grafische Spice-Konsole Scrollbalken anbietet, wenn die Auflösung des darzustellenden Gast-Desktops die Rahmengröße des Spice-Fensters übersteigt. Das führt zu folgenden Fragen:

Kann man für den Desktop des Gastsystems auch Auflösungen vorgeben, die die physikalischen Grenzen eines am Betrachter-Host angeschlossenen Monitors übersteigen?

Antwort: Ja, man kann für den Gast durchaus höhere Auflösungen vorgeben als die, die ein physikalischer Monitor unterstützt. Das führt logischerweise zu einer pixelmäßig nicht schärfer werdenden Vergrößerung der Desktop-Fläche des Gastes. Man muss dann eben im Spice-Fenster scrollen, wenn man das Spice-Fenster nicht über die Größe des fraglichen physikalischen Monitors ausdehnen kann.

Haben höhere Gast-Auflösungen als die eines physikalischen Monitors überhaupt einen Sinn?

Antwort: Ja – nämlich dann, wenn man am Linux-Host, von dem aus man den Gast-Desktop betrachtet, mehrere Monitore per “xinerama” zu einem von der Pixelfläche her zusammenhängenden Monitor gekoppelt hat!

An einem von mir betreuten System hängen etwa drei Monitore mit je max. 2560×1440 px Auflösung. Nachfolgend seht ihr ein Bild von einem testweise installierten Debian-Gast, für den mittels CVT und xrandr eine Auflösung von 5120×1080 Pixel eingestellt wurde. Das Spice-Fenster auf dieser Linux-Workstation erstreckt sich dann über 2 von 3 physikalischen Monitoren. Siehe die linke Seite der nachfolgenden Abbildung:

Von der grafischen Performance her ist das auf diesem System (Nvidia 960GTX) überhaupt kein Problem; der Gewinn für den Anwender besteht in komfortablem Platz zum Arbeiten auf dem Desktop des Gastsystems! In der Regel bedeutet das nicht mal eine Einschränkung für das Arbeiten mit dem Desktop des Betrachter-Hosts: Man kann unter KDE oder Gnome ja beispielsweise einfach auf eine weitere, alle drei Monitore überstreckende “Arbeitsfläche” des Betrachter-Desktops ausweichen.

U.a. ist es auch möglich, 4K-Auflösungen, also 4096 × 2160 Pixel, für den Desktop des virtualisierten Systems einzustellen. Man hat dann entweder physikalische Monitore am Betrachter-Host verfügbar, die 4K unterstützen, oder genügend Monitore mit geringerer Auflösung zusammengeschlossen – oder man muss, wie gesagt, eben scrollen. Für manche Grafik-Tests mag selbst Letzteres eine interessante Option sein.

Gibt es Grenzen für die einstellbare QXL-Auflösung des virtualisierten Gast-Systems?

Antwort: Ja; momentan unterstützt das QXL-Device maximal 8192×8192 Pixel.

Geht man so hoch, muss man, wie bereits im ersten Artikel beschrieben, aber auch den Video-RAM des QXL-Devices anpassen und ggf. auf den Parameter “vram64” zurückgreifen!

Nachtrag 15.08.2017:

Nutzt man ein Memory/RAM der VM > 2048 MiB, so gibt es zusätzliche Einschränkungen für den maximalen ram-Wert des QXL-Devices. S. hierzu die inzwischen eingefügten Hinweise im ersten Artikel.

Funktionieren bei den Gastsystem-Einstellungen auch andere Vertikalfrequenzen als solche, die vom physikalischen Monitor unterstützt werden?

Antwort: Ja, auch das funktioniert!

Z.B. unterstützt der in den vorhergehenden Artikeln angesprochene Laptop die Auflösung 2560×1440 physikalisch nur mit 44Hz. Dennoch kann ich für den virtualisierten Gast-Desktop auch Modelines für eine Vertikalfrequenz von 60Hz oder 20Hz anfordern. Das macht in der finalen Darstellung auf dem Host des Betrachters nichts aus – die Grafik-Information wird ja lediglich in das dortige Spice-Fenster eingeblendet; die Abfrage von Änderungen am virtuellen Desktop erfolgt von Spice und QEMU (vermutlich) mit eigenen, intern definierten Frequenzen und wird entsprechend zwischen Spice-Server und -Client übertragen. Aber es schadet nicht, bei der Wahl der Vertikalfrequenz für die Video-Modes des Gastsystems einen vernünftigen Wert wie 60Hz oder 50HZ zu wählen.

Persistenz der Auflösungseinstellungen

Es gibt verschiedene Wege, per CVT gefundene Auflösungen und deren Modelines permanent in einem Linux-System zu hinterlegen und diese Modes beim Start einer graphischen Desktop-Sitzung direkt zu aktivieren. Der Erfolg des einen oder anderen Weges ist aber immer auch ein wenig distributions- und desktop-abhängig.

Ich konzentriere mich nachfolgend nur auf ein Debian-Gast-System mit Gnome 3 und gdm3 als Display Manager. Ich diskutiere dafür auch nur 2 mögliche Ansätze. Für KDE5 und SDDM gibt es allerdings ähnliche Lösungen ….

Warnhinweis:

Am Beispiel des bereits diskutierten Laptops sollte klargeworden sein, dass solche
Einstellungen ggf. sowohl im virtualisierten Gastsystem als auch auf dem Linux-Host, an dem die physikalischen Monitore hängen, dauerhaft hinterlegt werden müssen. Bzgl. der physikalisch wirksamen Einstellungen auf dem eBtrachter-Host ist allerdings Vorsicht geboten; man sollte seine Video-Modes und Frequenzen dort unbedingt im Rahmen der unterstützten Monitor- und Grafikartengrenzen wählen.

Variante 1 – rein lokale, userspezifische Lösung: Eine distributions- und desktop-neutrale Variante wäre etwa, die xrandr-Kommandos in einer Datei “~/.profile” für den Login-Vorgang oder (besser!) in einer Autostart-Datei für das Eröffnen der graphischen Desktop-Sitzung zu hinterlegen. Siehe hierzu etwa:
https://askubuntu.com/ questions/ 754231/ how-do-i-save-my-new-resolution-setting-with-xrandr

Der Nachteil dieses Ansatzes ist, dass der User bereits wissen muss, welche Auflösungen man für seinen Monitor per “xrandr” sinnvollerweise einstellen kann und sollte. Beim “.profile”-Ansatz kommt hinzu, dass sich das bei jedem Login auswirkt. Falsche Modes sind auf der physikalischen Host-Seite aber, wie gesagt, problematisch. Es wäre besser, die User nutzten nur vom Admin vordefinierte Auflösungen und dies mit den üblichen Desktop-Tools. Einen entsprechenden Ausweg bietet die nachfolgende Methode.

Variante 2 – zentrale und lokale Festlegungen:
Dieser Weg führt über 2 Schritte; er ist ebenfalls neutral gegenüber diversen Linux-Varianten. Bei diesem Weg wird globale Information mit user-spezifischen Setzungen kombiniert:

Unter Opensuse Leap ist ein zentrales Konfigurationsverzeichnis “/etc/X11/xorg.conf.d/” für X-Sitzungen bereits vorhanden. Man kann dieses Verzeichnis aber auch unter Debian-Systemen manuell anlegen. Dort hinterlegt man dann in einer Datei “10-monitor.conf” Folgendes:

Section "Monitor"
	Identifier "Virtual-0"
	Modeline "2560x1440_44.00"  222.75  2560 2720 2992 3424  1440 1443 1448 1479 -hsync +vsync
	Option "PreferredMode" "2560x1440_44.00"
EndSection

Section "Screen"
	Identifier "Screen0"
	Monitor "Virtual-0"
	DefaultDepth 24
	SubSection "Display"
		Modes "2560x1440_44.00"
	EndSubsection
EndSection

Diese Statements hinterlegen eine definierte Auflösung – hier 2560×1440 bei 44Hz – für unseren virtuellen Schirm “Virtual-0” permanent. Die Modline haben wir, wie in den letzten Artikeln beschrieben, mittels CVT gewonnen. (Die angegebene Werte für die Modline und die Auflösung sind vom Leser natürlich dem eigenen System und den eigenen Wünschen anzupassen.)

Die obigen Festlegungen bedeuten nun aber noch nicht, dass nach einem weiteren Login eine neue Gnome- oder KDE-Sitzung unter Debian bereits die hohe Auflösung produzieren würde. Die “PreferredMode” wird vielmehr ignoriert. Warum ist mir, ehrlich gesagt, nicht klar. Egal: Die Auflösung steht immerhin in den lokalen Konfigurationstools des jeweiligen Desktops zur Auswahl zur Verfügung. Damit kann der Anwender dann die lokalen Auflösungswerte in persistenter Weise festlegen:

Unter “Gnome 3” rufen wir dazu im KVM-Gastsystem etwa das “gnome-control-center” auf:

myself@debian8:~$ gnome-control-center &

Dort wählen wir unter der Rubrik “Hardware” den Punkt “Bildschirme” und stellen die gewünschte Auflösung ein. Die Einstellung landet dann in einer Datei “~/.config/monitors.xml” – und ist X-Session-übergreifend verankert.

Im Falle von “KDE 5” wählen wir dagegen

myself@debian8:~$ systemsettings5 &

und dort dann den Punkt “Hardware >&
gt; Anzeige und Monitor”. Die dort getroffenen Einstellungen werden in einer Datei “~/.local/kscreen/” in einem JSON-ähnlichen Format gespeichert.

Diese 2-te Lösung hat den Vorteil, dass die maximale Auflösung systemweit vorgegeben wird. Der jeweilige User kann jedoch die von ihm gewünschte Einstellung wie gewohnt lokal hinterlegen und dafür die gewohnten Desktop-Tools einsetzen.

Persistenz der Auflösungseinstellungen für den “Display Manager” bzw. den Login-Schirm

Nachdem wir nun die Desktop-Sitzung unter Kontrolle haben, wäre es doch schön, auch das Login-Fenster des Display-Managers dauerhaft auf eine hohe Auflösung setzen zu können. Das geht am einfachsten für “gdm3”. 2 Varianten sind möglich:

Variante 1 – Globale Nutzung der Datei “monitors.xml”:
Die Festlegungen für den Gnome-Desktop wurden in einer Datei “~/.config/monitors.xml” festgehalten. Wir kopieren die “monitors.xml”-Datei nun als User “root” in das Verzeichnis “/var/lib/gdm3/.config/”:

root@debian8:~# cp /home/myself/.config/monitors.xml /var/lib/gdm3/.config/

Dort wird eine Konfigurationsdatei im XML-Format für den gdm3-Schirm ausgewertet. Unter Debian 8/9 hat sich hier allerdings ein Problem eingeschlichen:
gdm3 läuft dort bereits unter Wayland – und dieser X-Server ignoriert leider die getroffenen Einstellungen. Das lässt sich aber leicht beheben, indem man für gdm3 die Nutzung des klassischen X11-Servers erzwingt! In der Datei “/etc/gdm3/daemon.conf” muss dazu folgender Eintrag auskommentiert werden:

[daemon]
WaylandEnable=false

Danach wird dann beim nächsten gdm3-Start auch die “monitors.xml” akzeptiert – und die vorgeschlagene Auflösung übernommen. Leider ist es hier Benutzern ohne Root-Rechte nicht möglich, eigene Einstellungen zu treffen. Als Administrator sollte man hier natürlich zur HW passende Einstellungen wählen.

Links zum Thema “Ignoring monitors.xml in /var/lib/gdm3/.config/”
https://bugzilla.redhat.com/ show_bug.cgi? id=1184617
https://bugzilla.gnome.org/ show_bug.cgi? id=748098
In letzterem ist für Wayland auch ein Workaround beschrieben; ich habe das vorgeschlagene Vorgehen aber nicht getestet.

Variante 2: Nutzung von xrandr-Befehlen in Startup-Scripts des Display Managers
Man kann die “xrandr”-Befehle auch in den Startup-Scripts des jeweiligen Display Managers hinterlegen (xorg-Einstellungen werden leider grundsätzlich ignoriert). Für gdm3 also in der Datei “/etc/gdm3/Init/Default”. Dort kann man die xrandr-Anweisungen etwa am Dateiende anbringe. Siehe hierzu: https://wiki.ubuntu.com/X/ Config/ Resolution#Setting-xrandr-commands-in-kdm.2Fgdm_startup_scripts

Für mich ist das die präferierte Art, fixe Einstellungen für den Desktop-Display/Login-Manager vorzunehmen. Man muss sich allerdings für jeden der populären Manager (gdm3, ssdm, lightdm) kundig machen, in welcher Form Startup-Skripts eingebunden werden können. Leider gibt es dafür keinen Standard.

Nachtrag vom 02.03.2018:
Da “gdm3” im Moment unter aktuellen Debian- wie Kali-Installationen Probleme beim Shutdown macht (hängender Prozess, der von systemd nicht gestoppt werden kann), habe ich auch mal den simplen Login-Manager “lightdm” ausprobiert. Dort findet man Möglichkeiten zum Starten von Skripten in der Datei /etc/lightdm/lightdm.conf”. Siehe dort etwa die Option “display-setup-script”. Dort kann man auf bereits definierte Modes unter “/etc/X11/xorg.conf.d/10-monitor.conf” zurückgreifen – z.B. per “xrandr –output
Virtual-0 –mode 2560x1440_44.00”.

Automatische (!) Auflösungsanpassung des Gast-Desktops an die Größe des Spice-Client-Fensters

Die oben vorgeschlagenen Lösungen funktionieren zwar und mögen für den einen oder anderen Leser durchaus einen gangbaren Weg zur dauerhaften Nutzung hoher Auflösungen (genauer: großer Spice-Fenster-Abmessungen) von KVM/QEMU-Gastsystemen darstellen. Aber das ganze Procedere ist halt immer noch relativ arbeitsintensiv. Leute, die VMware nutzen, kennen dagegen die Möglichkeit, die Auflösung des Gastsystems direkt an die VMware-Fenstergröße anpassen zu lassen. Voraussetzung ist dort die Installation der sog. “VMware Tools” im Gastsystem. Gibt es etwas Korrespondierendes auch unter KVM/QXL/Spice ?

Antwort: Ja, aber …

Eine Voraussetzung ist, dass der QXL-Treiber und der spice-vdagent im Gastsystem installiert und aktiv sind. Eine andere ist aktuell aber auch, dass der jeweilige grafische Desktop des KVM-Gastes (Gnome, KDE, …) mit diesem Duo und den von ihm bereitgestellten Informationen in sinnvoller Weise umgehen kann (s.u.).

Die dynamische Desktop-Anpassung an die Spice-Fenstergröße kann durch KVM-Anwender über die Option

View >> Scale Display >> Auto resize VM with window

aktiviert werden. Die grafische Spice-Konsole (von virt-manager) bietet den entsprechenden Haupt-Menüpunkt in ihrer Menüleiste an.

Nachtrag 02.03.2018:

Es gibt übrigens noch einen zweiten Spice-Client, den man über ein Terminal-Fenster starten kann – nämlich den sog. “Remote-Viewer” (siehe hierzu auch den nächsten Artikel dieser Serie). Je nach Versionsstand bietet der “Remote Viewer” entweder einen ähnlichen Menüpunkt an – oder aber der dargestellte Desktop des KVM-Gastes reagiert bei laufendem vdagent automatisch richtig, wenn im “Remote-Viewer” die Option “Ansicht (View) => Zoom => Normal Size” gewählt wird.

Nun verhält es sich leider so, dass sich das gewünschte Verhalten beim Aktivieren des Menüpunktes in einigen Fällen nicht unmittelbar einstellen mag.

Diesbzgl. sind als erstes 2 wichtige Punkte festzuhalten:

Hinweis 1: Die Funktionalität zur automatischen Auflösungsanpassung ist nicht völlig kompatibel mit den obigen Ansätzen zur Hinterlegung persistenter Auflösungseinstellungen! Im Besonderen muss man die Datei “/etc/X11/xorg.conf.d/10-monitor.conf” zunächst auf ein absolutes Minimum beschränken:

Section "Monitor"
	Identifier "Virtual-0"
	Modeline "2560x1440_44.00"  222.75  2560 2720 2992 3424  1440 1443 1448 1479 -hsync +vsync
EndSection

Oder man muss diese Datei gleich ganz entfernen.

Hinweis 2:
Manchmal passiert nichts, wenn man seine Spice-Screen-Größe schon verändert hat und erst dann die Option zur automatischen Anpassung an die Fenstergröße anklickt. Das irritiert den Anwender womöglich, der eine unmittelbare Reaktion erwartet. Die Informationen des Duos “vdagent/QXL-Treiber” zur Änderung der Größe des Spice-Client-Fensters werden offenbar aber erst dann erstmalig verarbeitet, wenn die Ausdehnung des Spice-Fensters tatsächlich durch den Nutzer geändert wird! Das Anklicken der Option im Menü allein ist also für eine erste Anpassung noch nicht ausreichend. Daher der Rat: Bitte testweise mit der Maus eine erste Größenänderung des Spice-Fensters vornehmen. Danach sollte der Desktop reagieren.

Ich zeige den Effekt in den nachfolgenden Bildern mal für ein “Debian 9”-Gast-System. Ich habe zwischen den Bildern dabei mit der Maus die Breite die Breite des Spice-Fensters auf dem KVM-Host von 1700px auf 1200px reduziert.

Aber auch das Beachten der oben genannten zwei Punkte ist im Moment in vielen Fällen nicht hinreichend. Zur Erläuterung muss man leider ein wenig ausholen. Früher war eine automatische Auflösungsanpassung u.a. Aufgabe des spice-vdagent. Im Moment gelten jedoch folgende Feststellungen:

Politikwechsel: Red Hat hat aus (hoffentlich guten) Gründen die Politik bzgl. der Auflösungsanpassung geändert. Inzwischen nimmt nicht mehr der spice-vdagent die Auflösungsänderung vor, sondern überlässt dies dem aktuell laufenden Desktop (bzw. bzgl. des Login-Screens dem Desktop-Manager). Das Duo aus vdagent und QXL-Treiber übermittelt hierzu nur noch ein Signal samt der notwendigen Auflösungsinformationen an den aktuell laufenden Desktop (genauer an dessen kontrollierendes Programm) und überlässt ihm weitere Maßnahmen. Wobei die zugehörigen Programme vermutlich wiederum xrandr einsetzen. Für diesen Vorgang muss der QXL-Treiber (Kernelmodul!) aber auch geladen sein.
Versionsabhängigkeiten: Eine automatische Auflösungsanpassung funktioniert aufgrund des Umbruchs bzgl. der Verantwortlichkeiten nicht mit allen Host- und Gast-Dristibutionen bzw. Programmständen von libvirt/spice bzw. QXL so wie erwartet.

Unter https://bugzilla.redhat.com/ show_bug.cgi? id=1290586 lesen wir entsprechend:

spice-vdagent used to be doing something like this, but this was racing with desktop environments keeping track of the current resolution/monitors/.., so we are now informing the desktop environment that a resolution change would be desirable, and let it handle it.
… It’s no longer going through spice-vdagent if you use the QXL KMS driver (although it needs spice-vdagent to be started iirc).

Dadurch ergeben sich aber neue Abhängigkeiten – denn wenn der QXL-Treiber und vdagent in einer aktuellen Version geladen sind, aber die jeweilige Desktop-Umgebung das Anliegen von QXL nicht unterstützt, geht halt nix. Mit den QXL-Anforderungen zur Auflösungsskalierung können nur neuere Versionen von Gnome und KDE vernünftig umgehen. Unter LXDE funktioniert im Moment leider überhaupt keine automatische Auflösungsanpassung mehr. Ein Beispiel für die etwas vertrackte Übergangssituation liefert etwa Debian 8:

Unter Debian Jessie mit Kernel 3.16 etwa funktionierte eine automatische Auflösungsanpassung noch – das lag aber damals daran, dass der QXL-Treiber gar nicht geladen werden konnte. Installiert man dagegen Kernel 4.9 unter Debian 9 “Jessie”, dann lässt sich das QXL-Modul laden – aber weder der Gnome-, noch der KDE-, noch ein LXDE-Desktop ziehen dann bzgl. der Auflösungsanpassung mit. Entlädt man das QXL-Treibermodul (mit Performance-Nachteilen) funktioniert die automatische Auflösungsanpassung dagegen wieder (nämlich über die alte Funktionalität des spice-vdagent.

Es ist leider ein wenig chaotisch. Erst unter Debian 9 passt alles wieder zusammen – zumindest unter den dort aktualisierten Gnome3- und KDE5-Versionen.

Die neue Politik abseits des vdagents wird primär durch aktuelle Versionen des QXL-Treiber umgesetzt. Teilweise kann man Probleme mit einer automatischen Auflösungsanpassung deshalb umgehen, indem man das qxl-drm-Kernel-Modul “blacklisten” ließ/lässt. Siehe hierzu:
https://bugs.debian.org/ cgi-bin/ bugreport.cgi? bug=824364
Ein Nichtverwenden des QXL-Treibers hat aber leider auch Performance-Nachteile.

Mit welchen Gastsystemen funktioniert die automatische Auflösungsanpassung?

Unter Debian 8 Jessie mit Kernel 3.16, aber ohne geladenen QXL-Treiber (nicht jedoch mit Kernel 4.9, libvirt und qxl aus den Backports)
Unter Kali2017 mit Gnome 3.
Unter Debian 9 “Stretch” mit Gnome3 und KDE5 – aber nicht mit Mate, nicht mit LXDE.
Unter Opensuse Leap 42.2 mit upgedatetem Gnome3 (nicht aber mit KDE5).

Wenn Sie also mit einer automatischen Auflösungsanpassung an die Spice-Fenstergröße experimentieren wollen, dann sollten Sie am besten mit Debian 9 (Stretch) basierten Gast-Systemen arbeiten oder entsprechend upgraden.

Nachtrag 1 vom 02.03.2018:
Die automatische Auflösungsanpassung funktioniert auch mit Kali 2018.1, aktuellem 4.14-Kernel und Gnome3 in der Version 3.26.

Nachtrag 2 vom 02.03.2018:
Ein leidiger Punkt ist die Frage einer automatischen Auflösungsanpassung der Desktop-Display/Login-Manager an das Fenster der grafischen Spice-Konsole. Hierzu habe ich sehr gemischte Erfahrungen:

Während “gdm3” sich als fähig erweist, mit dem “spice-vdagent” zu kooperieren, gilt dies etwa für “lightdm” nicht. Hinweise aus früheren Zeiten zum vorherigen Start von “spice-vdagent” über ein “Wrapper-Skript” (s. etwa: https://www.spinics.net/lists/spice-devel/msg24986.html) funktionieren dabei wegen der oben beschriebenen Politik-Änderung nicht:
Der Display-Manager muss so programmiert sein, dass er die Dienste des vdagent auch nutzt und Screen-Änderungen kontinuierlich abfragt. So wird die aktuelle Screen-Größe i.d.R. nur genau einmal – nämlich beim Starten des Desktop-Managers übernommen. Danach bleibt die Größe des Greeter-Fensters konstant, egal ob man den Spice-Fenster-Rahmen ändert oder nicht.

Fazit

Wir haben gesehen, dass man Auflösungseinstellungen für die Desktops, die man sich über xrandr auf dem Betrachter-Host bzw. im Gastsystem mühsam zurechtgebastelt hat, auch persistent in den betroffenen Systemen hinterlegen kann. Ein u.U. sehr viel einfachere Methode zur Nutzung hoher Auflösungen – nämlich eine automatische Anpassung der Auflösung des Gast-Desktops an die Fenstergröße des Spice-Fensters funktioniert optimal im Moment nur mit Gastsystemen, die aktuelle Versionen des KDE5- oder des Gnome3-Desktops integriert haben. Dort macht diese Option aber ein mühsames Handtieren mit xrandr-befehlen im Gastsystem weitgehend überflüssig.

Ausblick

Im nächsten Artikel dieser Serie

https://linux-blog.anracom.com/ 2017/08/15/ kvmqemu-mit-qxl-hohe-aufloesungen-und-virtuelle-monitore-im-gastsystem-definieren-und-nutzen-iv/

befasse ich mich mit der Möglichkeit, mehrere virtuelle Desktop-Schirme für die Gastsysteme auf (mehreren) realen Monitoren des Betrachter-Hosts zu nutzen.

KVM/qemu mit QXL – hohe Auflösungen und virtuelle Monitore im Gastsystem definieren und nutzen – I

Posted on 6. July 2017 by Ralph Mönchmeyer

Wer KVM/QEMU ohne Spezialkenntnisse nutzen will, setzt hierfür z.B. “virt-manager” ein und vertraut darauf, dass das Gespann libvirt/qemu darunter schon sauber seine Arbeit verrichten wird. Die graphischen Tools von “virt-manager” unterstützen einen zumindest in Grenzen recht gut bei der Einrichtung und Überwachung der Gastsysteme. Das reicht für kleinere, lokale Virtualisierungsvorhaben in der Regel völlig aus; man muss nicht immer gleich zu Profi-Tools für die Verwaltung virtueller Systeme greifen. Für spezielle Gegebenheiten ist allerdings etwas Handarbeit erforderlich – das trifft u.U. auch auf den Einsatz eines oder mehrerer hochauflösender Monitore zu.

Diese Artikelserie geht auf die Frage ein, wie man mittels Tools von libvirt, QEMU, Spice und X-Windows hohe Monitor-Auflösungen auch beim Arbeiten mit virtualisierten Gastsystemen nutzen kann. Dies ist im besonderen dann von Interesse, wenn das Virtualisierungssystem bestimmte physikalische Möglichkeiten (z.B. externer Monitore) am Host oder in einem Remote-System nicht richtig erkennt und die gewünschte Auflösung deshalb über Standardtools der involvierten Desktop-Umgebungen des Gastes und u.U. auch des Hostes nicht angeboten wird.

Als ebenso spannend erweist sich in der Praxis die Frage, wie man denn für Linux-Gäste mehrere virtuelle Monitore auf hochauflösenden physikalischen Displays des Hostes oder eines Remote Systems nutzen kann. “virt-manager” allein bietet hierfür nämlich keine hinreichenden Konfigurationsoptionen an.

Ich setze nachfolgend voraus, dass der Leser sich schon mal mit “virt-manager” befasst hat und auch schon mal ein Linux-Gastsystem auf einem KVM-Host angelegt hat.

Voraussetzungen: Grafischer Zugriff auf das Gstsystem

Ist eine virtuelle Maschine mittels “virt-manager” unter KVM/QEMU erst einmal konfiguriert, so stellt sich die Frage nach dem Zugriff auf den Gast vom Host oder Remote-Systemen [RS] aus. Dabei sollen komplette grafische Oberflächen/Desktops des Gastes auf den physikalischen Monitoren des Hosts/RS dargestellt werden. Das ist natürlich u.a. mit VNC möglich. Speziell für Linux-Hosts und -Gäste wird ein performantes, verzögerungsfreies und auch bequemes Arbeiten vor allem aber durch die Kombination des Spice-Protokolls mit einer grafischen Spice-Konsole (Display Fenster) und mit einer virtuellen Grafikeinheit vom Typ “QXL” im Gastsystem gewährleistet.

Spice ist dabei für die Kommunikation der virtuellen Maschine mit dem Host/RS und darunter liegender HW verantwortlich. Spice ist als Client/Server-Protokoll konzipiert; auf dem Gastsystem verrichten Spice-Server-Komponenten, auf dem Host/RS dagegen Spice-Client-Komponenten ihre Arbeit. Der Grafik-Output des Gastes wird unter Einsatz von Kompressions- und Caching-Verfahren zum Host/RS transferiert und dort in ein Fenster (grafische Spice-Konsole) des Host/RS-Desktops eingeblendet (ähnlich wie bei VNC oder X2GO; allerdings ist Spice wohl nicht für mehrere parallele Verbindungen gedacht). Es gibt zwei Arten von grafischen Konsolen, die mit Spice kooperieren. “virt-manager” selbst bietet den sog. “virt-viewer” an.

“QXL” spielt dagegen den Part eines virtuellen Grafik-Devices im Gastsystem; ich nenne ein solches Device nachfolgend etwas vereinfacht auch eine “virtuelle Grafikkarte”. Für deren effiziente Nutzung benötigt das Gastsystem einen speziellen qxl-Treiber. Der wird meist über X-Server-Pakete der jeweiligen Linux-Distribution bereitgestellt. (Ich behandle in dieser Artikelserie nicht den virtio-Treiber für die Grafik-Einheiten der Gastsysteme.)

Hinsichtlich der Auflösung des Gast-Desktops unter einer Spice-Konsole auf dem Host/RS unterstützt QXL dann im Normalfall eine breite Palette an Werten. Eine entsprechende Liste, die sich weitgehend an den physikalischen Fähigkeiten des
Hosts/RS orientiert, bietet das Gast-System (!) unter Gnome bzw. KDE typischerweise über die jeweiligen Tools für die Screen/Display-Konfiguration an.

Der User kann dann im laufenden Betrieb die für ihn passende Auflösung wählen und umschalten. “virt-manager” erlaubt ergänzend eine Anpassung des “virt-viewer”-Fensters an die Größe des Gast-Desktops. Das hatte ich in dieser Form auch in einem früheren Artikel
KVM, video QXL und video virtio Treiber – Video-Auflösung des Gnome-Desktops eines Debian 8-Gastystems einstellen
erläutert.

Ist das schon die ganze Wahrheit? Leider nein. Es gibt nämlich eine Reihe von Problemen, die man als normaler User von “virt-manager” nicht oder nicht unmittelbar lösen kann:

Problem 1: Manchmal erweist sich das unter QXL angebotene Auflösungsspektrum nämlich als begrenzter als die physikalischen Möglichkeiten der Host-Monitore. Offenbar werden vermeintlich erkannte physikalische Einschränkungen des Hosts in einigen Fällen an das Gastsystem durchgereicht.
Problem 2: Copy/Paste zwischen Host und Gast funktionieren nicht!
Problem 3: Eine automatische Anpassung der Schirmauflösung des Gastsystems an die Größe des Spice-Viewers funktioniert nicht ohne weiteres!
Problem 4: Ein Multi-Monitor-Betrieb lässt sich für hohe Auflösungen auch für Linux-Gäste nicht ohne Kunstgriffe bewerkstelligen. Obwohl manche Artikel und Youtube Movies im Internet etwas anders versprechen!

Ich werde in den nachfolgenden Artikeln darstellen, dass und wie man dann u.U. “xrandr” nutzen kann, um die Grenzen des angebotenen Auflösungsspektrums im KVM-Gastsystem (genauer dessen graphischer Desktop) zu überschreiten und die Screen-Auflösung des Gastes an oder über die physikalischen Auflösungsmöglichkeiten der Host-Monitore zu treiben. Wobei ein “über” in der Praxis natürlich nur einen begrenzten Sinn hat.

Zudem werfen wir kurz einen Blick auf die Möglichkeit, den Speicher der virtuellen Video-Einheit zu erhöhen. Es liegt ja auf der Hand, dass hohe Auflösungen auch den Speicherbedarf von virtuellen Grafik-Devices erhöhen werden. Das gilt vor allem für einen Multi-Monitor-Betrieb; hierfür reichen die von virt-manger vergebenen Standardwerte nicht aus. Mittels “spice-vdagent” sorgen wir dann für etwas mehr Komfort. Wir beleuchten danach weitere Voraussetzungen zur Nutzung eines KVM-Gastes mit mehreren virtuellen Monitoren.

Problemmeldung eines Lesers

Wiso nehme ich mich hier überhaupt dieses Themas an? Kurz vor dem letzten Wochenende hat mich ein Leser angeschrieben, der an einem Laptop einen hochauflösenden externen Schirm mit einer Auflösung von 2560×1440 betreibt. Da über Display-Port sogar mit einer Vertikalfrequenz von 60Hz. Leider war es ihm nicht möglich, diese Auflösung auch in debian-basierten, virtualisierten Gastsystemen zu erreichen, die er unter KVM/qemu installiert hatte. Seine Frage war, was man da tun könne.

Ich konnte das Verhalten an einem eigenen Laptop weitgehend nachstellen. Es handelt sich bei meinem Laptop um einen älteren Worthmann Terra mit einer Optimus-Kombination aus Nvidia-Grafikkarte und einer CPU-gebundenen Intel HD4000, wobei letztere auch eine HDMI-Schnittstelle versorgt. Leider sind die Fähigkeiten der HD4000/HDMI-Kombination limitiert (auch durch den Hersteller). Das Board versorgt den HDMI-Bus nur mit einer Maximalfrequenz von 225 MHz. Das reicht leider nicht, um Auflösungen jenseits von 2048×1152 bei einer Vertikalfrequenz von 60Hz zu versorgen. Möglich sind aber 2048×1152 bei 60Hz und 2560×1440 bei einer Frequenz von 40 oder 44 Hz. Damit konnte ich das
Problem des Lesers auf meinem Laptop aber nachstellen. Der Laptop wurde dazu als KVM-Host unter Opensuse Leap 42.2 mit KDE-Desktop betrieben:

Die maximale Auflösung, die mir debian-basierte KVM-Gastsysteme (Kali2017 mit Kernel 4.9, Debian 8 mit Kernel 3.16) auf diesem KVM-Host anboten, betrug unter “spice” und “qxl” 1920×1080 Pixel. Das entsprach gerade der Auflösung des integrierten Laptop-Schirms!

Die physikalisch möglichen Auflösungen des externen Monitors von 2048x1152_60.00Hz bzw. 2560x1440_44.00Hz unter HDMI wurden dagegen völlig ignoriert! Warum auch immer … Tja, was kann man in einem solchen Fall tun?

Einsatz von xrandr und CVT auf dem Host als Ausgangspunkt …

Es ist instruktiv, sich zunächst anzusehen, wie ich den Laptop dazu brachte, 2560x1440__44.00Hz auf dem HDMI-Monitor zu unterstützen. KDE’s Tool “systemsettings5 > Anzeige und Monitor” bot mir diese Auflösung für den Desktop des Hosts nämlich keineswegs an; ich nehme an, dass die Ursache dafür auch im Intel i915-Treiber zu suchen ist:

Unter Linux steht (berechtigten Usern) das Werkzeug “xrandr” zur Verfügung, um Auflösungen für verschiedene Monitore zu konfigurieren. xrandr nutzt dazu die RandR-Erweiterung des X-Window-Systems. Siehe die unten angegebenen Links für weitere Infos. Verschiedene Desktops (Gnome, KDE, LXDE) nutzen “xrandr” über eigene integrierte grafische Tools. “xrandr” lässt sich als Kommando jedoch auch direkt an einem Shell-Prompt absetzen; ein Blick in die man-Seiten lohnt sich.

Gibt man etwa xrandr ohne Parameter am Prompt eines Terminalfensters ein, so erhält man Informationen zu den aktuell erkannten Monitoren und deren Auflösung. In meinem Fall etwa:

myself@mytux:~> xrandr
Screen 0: minimum 8 x 8, current 3968 x 1152, maximum 32767 x 32767
LVDS1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 382mm x 215mm
   1920x1080     60.02*+
   1400x1050     59.98  
   1600x900      60.00  
   1280x1024     60.02  
   1280x960      60.00  
   1368x768      60.00  
   1280x720      60.00  
   1024x768      60.00  
   1024x576      60.00  
   960x540       60.00  
   800x600       60.32    56.25  
   864x486       60.00  
   640x480       59.94  
   720x405       60.00  
   640x360       60.00  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 2048x1152+1920+0 (normal left inverted right x axis y axis) 553mm x 311mm
   2048x1152_60.00  59.90  
   2048x1152     60.00* 
   1920x1200     59.95  
   1920x1080     60.00    60.00    50.00    59.94    30.00    25.00    24.00    29.97    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.88  
   1280x1024     75.02    60.02  
   1200x960      59.99  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x576i      50.00  
   720x480       60.00    59.94  
   720x480i      60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Man erkennt, dass für den HDMI1-Monitor als Maximal-Mode 2048×1440 bei 60Hz gelistet ist. Natürlich kann der tatsächlich angeschlossene Dell U2515H aber mehr.

Einsatz von xrandr

Wirft man einen Blick in die man-Seiten zu xrandr, entdeckt man, dass xrandr einem Monitor Video-“Modes” zuordnen kann. Dazu benötigt man aber bestimmte Daten einer sog. “Modline”. Wie erhält man nun eine gültige Modline für neue, vom System nicht erkannte Auflösungen? Unter Linux hilft hier das Tool “CVT”. Es berechnet für gewünschte Auflösungen/Frequenzen die notwendigen Daten. Damit kann man ein wenig rumspielen – Bsp.:

myself@mytux:~> cvt 2560 1440 40
# 2560x1440 39.96 Hz (CVT) hsync: 58.98 kHz; pclk: 201.00 MHz                                                          
Modeline "2560x1440_40.00"  201.00  2560 2720 2984 3408  1440 1443 1448 1476 -hsync +vsync                             

myself@mytux:~> cvt 2560 1440 44
# 2560x1440 43.99 Hz (CVT) hsync: 65.06 kHz; pclk: 222.75 MHz                                                          
Modeline "2560x1440_44.00"  222.75  2560 2720 2992 3424  1440 1443 1448 1479 -hsync +vsync      

myself@mytux:~> cvt 2560 1440 50
# 2560x1440 49.96 Hz (CVT 3.69M9) hsync: 74.15 kHz; pclk: 256.25 MHz                                                   
Modeline "2560x1440_50.00"  256.25  2560 2736 3008 3456  1440 1443 1448 1484 -hsync +vsync

Die erste Zahl nach dem Auflösungsstring gibt jeweils die Taktrate/Frequenz an, mit der die Pixel angesteuert werden (PixelClock). Die nimmt mit Auflösung und Vertikal-Frequenz natürlich zu. In meinem Fall muss sie – wie gesagt – unter 225MHz liegen.

Folgende Sequenz an Befehlen erfasst nun eine neue Mode und ordnet diese dem HDMI1-Monitor zu (ggf. als User root absetzen).

mytux:~ # xrandr --newmode 2560x1440_44 222.75  2560 2720 2992 3424  1440 1443 1448 1479 -hsync +vsync
mytux:~ # xrandr --addmode HDMI1 2560x1440_44
mytux:~ # xrandr --output HDMI1 --mode "2560x1440_44"

Danach bietet mir KDE’s “systemsettings5” diese Auflösung bereits an:

Dort kann man die Auflösung auch aktivieren. Wer für die Aktivierung jedoch die Kommandozeile vorzieht, kann auch den Befehl

mytux:~ # xrandr --output HDMI1 --mode "2560x1440_44"

absetzen. Und schon läuft der externe Schirm mit höherer Auflösung :

myself@mytux:~> xrandr --current
Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 32767 x 32767
LVDS1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 382mm x 215mm
   1920x1080     60.02*+
   ....
   .... 
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 2560x1440+1920+0 (normal left inverted right x axis y axis) 553mm x 311mm
   2560x1440     43.99 +
   2048x1152_60.00  59.90  
   2048x1152     60.00  
   1920x1200     59.95  
   1920x1080     60.00    60.00    50.00    59.94    30.00    25.00    24.00    29.97    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.88  
   1280x1024     75.02    60.02  
   1200x960      59.99  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x576i      50.00  
   720x480       60.00    59.94  
   720x480i      60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
   2560x1440_44  43.99* 
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Um eine Persistenz dieser Auflösungsvorgaben über einen Shutdown und Reboot hinaus zu erreichen, trägt man die gefundene Modline dann in eine Datei “/etc/X11/xorg.conf.d/10-monitor.conf” ein. Dies ist u.a. unter https://wiki.archlinux.org/ index.php/ xrandr beschrieben. Alternativ kann man eine Batchdatei anlegen und diese beim Start des Desktops automatisch ausführen lassen. Eine weitere Möglichkeit ist unter https://wiki.ubuntuusers.de/RandR/ beschrieben. Ich komme darauf in einem Folgeartikel detaillierter zurück; dort aber bei der Anwendung von “xrandr” im KVM-Gastsystem.

Funktioniert xrandr auch innerhalb von KVM/QEMU-Gastsystemen?

Für Neugierige, die schon mal experimentieren wollen: Ja, das geht! Zumindest mit QXL! Ist dabei die Vertikalfrequenz relevant? So, wie ich das verstehe, nicht. Die Video-Information wird ja per Spice in den Speicher der physikalischen Grafikkarte eingeblendet. Dafür sollte nur die Fenster- und Pixel-Info relevant sein. Aber es schadet nicht, sich an vernünftige Limits (60Hz) zu halten.

Es gibt allerdings andere Beschränkungen für ein performantes Verhalten hochauflösender Videomodes. Genauso wie physikalische Karten muss auch die virtuelle Video-Einheit mit hinreichendem Speicher für hohe Auflösungen versorgt werden!

Und Leute, die sich mit VMware auskennen, wissen auch, dass im Gastsystem Zusatzprogramme aktiviert werden müssen – u.a. um Copy/Paste zwischen Host und Gast zu ermöglichen oder eine dynamische Anpassung der Gast-Auflösung an die Fenstergröße zu ereichen. Man vermutet nicht ganz zu Unrecht, das es etwas Korrespondierendes wohl auch unter KVM/qemu geben sollte.

Bevor wir auf dem Client xrandr testen, kümmern wir uns deshalb zunächst um drei wichtige Aspekte der Gast-Ausstattung für Spice/QXL – Vorgaben für den Video-Speicher des QXL-Devices, die Bereitstellung eines Treibers und des sog. “spice-vdagent”. Als erstes müssen wir Spice und QXL überhaupt erstmal für unsere Virtuelle Maschine unter QEMU bereitstellen und aktivieren.

Spice und QXL aktivieren

Spice und QXL lassen sich bereits bei der Konfiguration eines Gastsystems über die entsprechende Oberfläche von “virt-manager” einstellen. Die Video-Konfiguration lässt sich dort aber auch im Nachhinein beeinflussen. Man entfernt dazu die alten Video-HW-Komponenten und ersetzt sie durch folgende:

Man sieht am letzten Fenster bereits, dass die Parameter für die QXL-Karte unter “virt-manager” leider nicht beeinflussbar sind!

Parameter für das Video Memory des QXL-Devices

Hohe 2D-Auflösungen bis 4K (4096 × 2160) erfordern als Minimum 32MiB Speicherkapazität für einen Schirm. Für flüssiges Arbeiten und die dafür notwendige Pufferung von Bildschirminhalten etc. aber deutlich mehr (64MB). Ich rede hier lediglich über 2D-Operationen. Die Standardeinstellung der qxl-Karte ist (zumindest unter Opensuse) für Framebuffer-Memory lediglich 16MB. Das reicht für 2560x1440x32 gerade so. Es schadet aber nichts, für noch höhere Auflösungen, mit denen man ggf. arbeiten will, mehr Video-RAM zu Verfügung zu stellen. Wie macht man das?

Leider gibt es keine Möglichkeit, das direkt mit “virt-manager” (Vers. 1.4) zu erledigen. Man ist vielmehr gezwungen, die unter libvirt erzeugten XML-
Dateien, die die Konfiguration virtueller Maschinen beschreiben, zu editieren. Unter “libvirt” spricht man auch von der Konfigurationsdatei einer virtuellen “Domäne”.

Das Editieren der XML-Domän-Dateien kann man entweder mit “virsh edit” oder aber durch direkten Zugriff mit seinem Lieblingseditor auf die Konfigurationsdateien durchführen. In letzterem Fall muss man selbst dafür sorgen, dass die XML-Struktur in Takt bleibt und alle Tags sauber abgeschlossen werden.

Man findet die Konfigurationsdateien unter “/etc/libvirt/qemu” in der Form “NAME.xml”. NAME steht hier für eine – z.B. über virt-manager angelegte – Virtualisierungs-“Domäne” (s. hierzu die Einleitung in https://libvirt.org/ formatdomain.html# elements .

Für virtuelle qxl-basierte Video-Einheiten gibt es z.Z. mehrere Konfigurationsparameter: ram, vram, vram64, vgamem. Zusätzlich wichtig ist der Parameter “heads”. Der besagt, wieviele virtuelle Monitore angeschlossen werden sollen und kann max. den Wert “4” annehmen. Dieser Wert wird nur in Linux-Gast-Systeme berücksichtigt. (Virtueller Multi-Monitor-Betrieb von Windows-Gastsystemen erfordert mehrere QXL-Einheiten).

Ein typischer Standard-Eintrag für ein QXL-Device hat etwa folgende Form:

    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </video>

Bzgl. der Anzahl, der Bezeichnung und Bedeutung der QXL-Paramter hat sich in den letzten Jahren einiges in schnellem Rhythmus verändert. Ich kann daher nur versuchen, mein aktuelles Verständnis davon wiederzugeben; es beruht auf nachfolgend genannten Artikeln im Internet und eigenen Tests.
Siehe hierzu etwa https://libvirt.org/ formatdomain.html# elementsVideo, siehe aber auch http://www.ovirt.org/documentation/ draft/video-ram/.

Die Angaben unter den beiden Links sind – soweit ich das sehe – nicht ganz kompatibel. Was sagen eigene Tests?

KiB: Die Werte zu diesen Parametern werden in der Konfigurationsdatei in “KiB” angegeben. 512MiB entsprechen daher 524288 KiB und ‘536870912’ Byte, 64MiB = 67108864 Byte. Das ist deshalb interessant, weil diese Werte vom System in anderen Kontexten durchaus in unterschiedlichen Einheiten angegeben werden.
Standardwerte: ram=’65536′, vram=’65536′, vram64=’0′, vgamem=’16384′, ‘heads=1’.
heads:Steht für die Anzahl der Ausgänge der virtuellen qxl-Grafikkarte, d.h. für die Anzahl der virtuellen Monitore, die man in einem Linux-Gastsystem über dasselbe Video-Device bedienen will. Ja, es ist durchaus möglich, ein Gastsystem mit mehreren virtuellen Monitoren auszustatten; s. hierzu eine der kommenden Artikel dieser Serie. Der Maximalwert für “heads” ist z.Z. offenbar 4. [“heads” mit einem Wert > 1 zu versehen, ist übrigens nur für Linux-Gastsysteme sinnvoll. Für Windows-Gastsysteme müssen mehrere Grafik-Devices für virtuelle Multi-Monitor-Konfigurationen angelegt werden.]
vgamem:Minimalwert (entspricht gleichzeit der Framebuffergröße) – dieser Minimalwert muss den Wert der Auflösung x Farbtiefe abdecken. Der Framebuffer-Modus dient auch als Fallback-Modus – etwa, wenn der QXL-Treiber im Gastystem nicht installiert ist. Da 32Bit Farbtiefe 4 Bytes entsprechen, ist die Auflösung Höhe x Breite in Pixel mit einem Faktor 4 zu multiplizieren. Im Falle von Linux-Gastystemen ist als
Faktor noch die Anzahl der Schirme (=Heads) zu berücksichtigen.
ram: Tests zeigen, dass der Parameter offenbar einen limitierten Memory-Bereich wiedergibt (für einen sog. virtuellen Memory-Bar 1; entspricht einem PCI Memory Bar-Bereich). Für diesen primären Memory-“Bar” erhält man nie effektiv wirksame Video-Ram-Werte > 512MiB – auch wenn man etwa ram=’1073741824′ festlegt. Das liegt offenbar an einer 32-Bit Adressierung. Dieser Speicher steht als sog. “IO Pages Memory” zur Verfügung. Er sollte (Pufferung!) mehr als das 4-fache des vgamem-Wertes betragen.
vram:Tests zeigen, dass dieser Parameter offenbar einen weiteren mit 32Bit addressierten Memory-Bereich wiedergibt (Adress-Bar 2; entspricht einem PCI Memory Bar-Bereich). Auch für diesen sekundären Memory-“Bar” erhält man daher nie effektiv wirksame Video-Ram-Werte > 512MiB. Der Speicherbereich steht als sog. Surface-Memory der virtuellen Graka zur Verfügung. Er sollte mindestens so groß sein, wie das Doppelte des vgamem-Wertes.
Dieser Memory-bereich kann bei Bedarf neben Texturen wohl auch IO-Page-Daten aufnehmen.
vram64:Alternative zu vram! Tests zeigen, dass dieser Parameter offenbar einen mit 64Bit adressierten Memory-Bereich wiedergibt (Adress-Bar 2). Der Parameter überschreibt vram; d.h. wenn angegeben, gilt vram64 und vram wird ignoriert. Der zweite Memory-Bar kann unter vram64 somit sehr viele größere Speicherwerte adressieren als unter vram. vram64-Angaben sind daher vor allem interessant, wenn man mit wirklich großen Auflösungen (4K und größer) und mehreren virtuellen Schirmen arbeiten will.

Man kann sich das QXL-Device – also die virtuelle Grafikkarte – etwa wie folgt vorstellen:

Für Linux-Gastsysteme gelten dabei folgende Formeln :

Formeln zur Berechnung des QXL Video RAMs

vgamem >= Breite x Höhe x 4 x Anzahl Heads
ram >= 4 x vgamem (maximal 524288 KiB)
vram >= 2 x vgamem (maximal 524288 KiB)
Hohe Auflösungen : vram64 > 4 x vgamem (beliebig ≤ 2×10^12)

Was bedeutet das in unserem Fall für die Auflösung 2560 x 1440 ?

vgamem >= 2560 x 1440 x 4 x Anzahl Heads
Plant man also mit 4 virtuellen Monitoren zu arbeiten:
vgamem ≥ 14400 x 4; wir runden das auf: 16384 x 4 = 65536 (= 64 MiB)
ram ≥ 262144 (248 MiB)
vram ≥ 131072 (128 MiB)

Rücksichtnahme auf den verfügbaren RAM des Hosts!

Natürlich kann es für Experimente auch mit nur einem virtuellen Monitor sinnvoll sein, bei hohen Auflösungen bzgl. der Video-Speicher-Größe auf die sichere Seite zu gehen. Es gilt aber:

Der insgesamt bereitgestellte Video RAM addiert sich zum festgelegten RAM der virtuellen Maschine dazu; d.h. er wird zusätzlich vom verfügbaren RAM des Hosts für KVM-Gastsysteme abgezweigt.

Das ist dann wichtig, wenn der RAM des Hostes begrenzt ist. In meinem Fall (16G RAM auf dem Laptop, 64G auf Desktops) ist das bei einer oder zwei virtuellen Maschinen nicht so relevant. Aber wenn der Speicher begrenzter ist und/oder mehr virtuelle Maschinen laufen sollen, lohnt es sich schon, den Video RAM auf das Notwendige einzuschränken. Für die Gesamtperformance des Systems kann mehr RAM durchaus viel wichtiger sein als ein zu groß gewählter Video RAM !

Abändern der Parameter in den Domän-Dateien von libvirt

Man kann meines Wissens z.Z. noch keine Einstellungen von Parametern für virtuelle QXL-Devices mittels “virt-manager” vornehmen. Davon lassen wir uns aber nicht abschrecken. Was immer man beim Aufsetzen einer virtuellen Maschine unter KVM/qemu mittels des Tools “virt-manager” vornimmt, landet ja in einer entsprechenden XML-Konfigurationsdatei unter dem Verzeichnis “/etc/libvirt/qemu”. In der dortigen XML-Datei muss man die Zeilen mit <video> suchen und abändern. Valide Einträge, die man mit dem Lieblingseditor seiner Wahl vornimmt, sind in unserem Fall (heads=4) etwa :

    <video>
      <model type='qxl' ram='262144' vram='262144' vgamem='65536' heads='4' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>

Getestet habe ich in den nachfolgenden Artikeln mit den eben genannten Werten.

Mit Maximalwerten für ram, vram sähe das Ganze dagegen so aus:

    <video>
      <model type='qxl' ram='524288' vram='524288' vgamem='65536' heads='4' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>

Testweise kann man sich ja aber auch mal ansehen, was bei folgenden Einstellungen passiert:

    <video>
      <model type='qxl' ram='262144' vram64='2097152' vgamem='65536' heads='4' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    
    <video>
      <model type='qxl' ram='1048576' vram='1048576' vgamem='65536' heads='4' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>

Wichtiger Nachtrag 15.08.2017:

Ich musste gerade feststellen, dass es mit dem theoretischen Maximalwert für ram in Abhängigkeit vom RAM der virtuellen Maschine (“memory”) ein Problem gibt. In einer der Debian-Gastsysteme versuchte ich zwischenzeitlich, den normalen RAM von 2048 MB auf 4096 MB zu erhöhen. vram war auf “524288” gesetzt. Daraufhin blieb der Bildschirm des Gastes beim Starten leider schwarz.

Lösung:

Nach etwas Recherche habe ich dann eine Bugmeldung für Virtual-Box zu einem ähnlichen Fehler gefunden; dort half eine Reduktion des Video Rams. Also habe ich das mal unter QEMU ausprobiert und bin bzgl. QXL zurück auf ram=’262144′. Dann klappt alles auch mit einem Memory der VM ≥ 4096 MB.

Eine Wert vram=’524288′ oder vram64=’2097152′ bereitet dagegen keine Probleme. Dieser Wert ist auch groß genug für die meisten sinnvollen Anwendungen.

Mir ist im Moment nicht klar, warum dieses Problem auftritt. Der geneigte Leser sei hiermit aber vorgewarnt.

Wichtiger Hinweis: Restart des libvirtd.service vornehmen oder “virsh define” ausführen, um die Änderungen an den Domän-Dateien unter virt-manager bekannt zu machen.

Wenn ich solche Eingriffe in einer Domän-XML-Datei vornehme fahre ich die betroffene virtuelle Maschine vorher zur Sicherheit runter. (Den Zustand aller anderen laufenden Gastsysteme kann man zwischenzeitlich dagegen auf die Festplatte speichern und die zugehörigen virtuellen Maschinen selbst pausieren lassen. Siehe hierzu die entsprechende Option “Save” unter virt-manager”). Nach der Durchführung der
Änderungen an der XML-Definitionsdatei zu einer einzelnen virtuellen Maschine ( bzw. “Domäne”) müssen die neuen Einstellungen dem laufenden libvirtd-Dämon oder zugehörigen administrativen Programmen bekannt gemacht werden. Dafür gibt es zwei Möglichkeiten:/p>

Möglichkeit 1: Restart des libvirtd-Dämons und ein neues Connecten zum Dämon unter “virt-manager”. Vorab sollte der Zustand aller laufenden virtuellen Maschinen ge-“saved” werden. Danach als user “root” das Kommando
systemctl restart libvirtd.service
absetzen! Dann sich unter virt-manager wieder mit dem Dämon verbinden und die geänderte Maschine neu hochfahren sowie die suspendierten anderen Systeme erneut starten.

Möglichkeit 2: Nutzen von “virsh” für eine Re-Definition der geänderten libvirt-“Domäne”:

$ virsh --connect qemu:///system
Connecting to uri: qemu:///system
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # define /etc/libvirt/qemu/NAME_der_geanderten_VM.xml

Siehe zur 2-ten Möglichkeit auch: https://help.ubuntu.com/ community/KVM/ Managing.

Überprüfung des angeforderten und des tatsächlich bereitgestellten Video-Speichers

Wie prüfe ich, wie die Daten der XML-Datei beim erneuten Start des Gastsystems umgesetzt werden? Dazu kann man sich zunächst mal den Befehl ansehen, der zum Start der virtuellen Maschine faktisch abgesetzt wurde:

ps aux | grep qemu | grep mem

Im Output finden sich dann Abschnitte wie

    -chardev spicevmc,id=charchannel0,name=vdagent 
    -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 
    -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on 
    -device qxl-vga,id=video0,ram_size=268435456,vram_size=268435456,vram64_size_mb=0,vgamem_mb=64,max_outputs=4,bus=pci.0,addr=0x2

Man erkennt hier unschwer die Umsetzung der Speicheranforderungen. Komischerweise in unterschiedlichen Einheiten (ram_size und vram_size in Bytes und vgamem_mb bzw. vram64_size in MiB! Das soll uns aber nicht weiter stören ….

Im Gastsystem selbst hilft nach dem Start meist ein Absetzen des Kommandos “dmesg | grep drm”.

root@kali2017-1:~# dmesg | grep drm
[    1.668901] [drm] Initialized
[    1.828524] [drm] Device Version 0.0
[    1.828529] [drm] Compression level 0 log level 0
[    1.828530] [drm] Currently using mode #0, list at 0x488
[    1.828530] [drm] 114686 io pages at offset 0x4000000
[    1.828531] [drm] 67108864 byte draw area at offset 0x0
[    1.828531] [drm] RAM header offset: 0x1fffe000
[    1.828532] [drm] rom modes offset 0x488 for 142 modes
[    1.832481] [drm] qxl: 64M of VRAM memory size
[    1.832481] [drm] qxl: 511M of IO pages memory ready (VRAM domain)
[    1.832482] [drm] qxl: 2048M of Surface memory size
[    1.836647] [drm] main mem slot 1 [a0000000,1fffe000]
[    1.836648] [drm] surface mem slot 2 [100000000,80000000]
[    1.836649] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    1.836649] [drm] No driver support for vblank timestamp query.
[    1.837401] [drm] fb mappable at 0xA0000000, size 3145728
[    1.837402] [drm] fb: depth 24, pitch 4096, width 1024, height 768
[    1.838735] fbcon: qxldrmfb (fb0) is primary device
[    1.865428] qxl 0000:00:02.0: fb0: qxldrmfb frame buffer device
[    1.889589] [drm] Initialized 
qxl 0.1.0 20120117 for 0000:00:02.0 on minor 0
[    1.927986] [drm] Device Version 1.0
[    1.927987] [drm] Compression level 0 log level 0
[    1.927988] [drm] Currently using mode #0, list at 0x488
[    1.927989] [drm] 12286 io pages at offset 0x1000000
[    1.927989] [drm] 16777216 byte draw area at offset 0x0
[    1.927990] [drm] RAM header offset: 0x3ffe000
[    1.927990] [drm] rom modes offset 0x488 for 128 modes
[    1.927996] [drm] qxl: 16M of VRAM memory size
[    1.927997] [drm] qxl: 63M of IO pages memory ready (VRAM domain)
[    1.927997] [drm] qxl: 64M of Surface memory size
[    1.932065] [drm] main mem slot 1 [e0000000,3ffe000]
[    1.932067] [drm] surface mem slot 2 [e4000000,4000000]
[    1.932068] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    1.932068] [drm] No driver support for vblank timestamp query.
[    1.933351] [drm] fb mappable at 0xE0000000, size 3145728
[    1.933352] [drm] fb: depth 24, pitch 4096, width 1024, height 768
[    1.933890] qxl 0000:00:0a.0: fb1: qxldrmfb frame buffer device
[    1.933894] [drm] Initialized qxl 0.1.0 20120117 for 0000:00:0a.0 on minor 1
root@kali2017-1:~#

Der aufmerksame Leser hat sicher mitbekommen, dass ich im letzten Beispiel eine virtuelle Maschine mit 2 QXL-Devices dargestellt habe. Das erste QXL-Device hat dabei Werte von ram=’524288′ vram64=’2097152′ vgamem=’65536′ zugeteilt bekommen.

Wenn der Ringpuffer des dmesg-Befehl das obige Ergebnis nicht liefert (kann nach einer Weile im laufenden Betrieb des Gastsystems passieren), der kann sich z.B. das Paket “hwinfo” installieren, damit alle HW-Einstellungen auslesen und dann im Output nach “graphics” suchen (oder die Ergebnisse von vornherein auf Zeilen mit “video” und “Graphic” einschränken.)

Genug für heute! Im Nachfolgeartikel

KVM/qemu mit QXL – hohe Auflösungen und mehrere virtuelle Monitore im Gastsystem definieren und nutzen – II

laden wir den qxl-Treiber im Gastsdystem nach, starten zudem auch den spice-vdagent und wenden schließlich “xrandr” im Gastsystem an.

Links

virt-manager
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Creating_guests_with_virt_manager.html
https://wiki.ubuntuusers.de/virt-manager
https://www.thomas-krenn.com/de/wiki/Virtual_Machine_Manager_-_GUI_zur_Verwaltung_virtueller_Maschinen
https://wiki.libvirt.org/page/CreatingNewVM_in_VirtualMachineManager

Video und Video-RAM
https://www.x.org/wiki/Development/Documentation/HowVideoCardsWork/
http://www.ovirt.org/documentation/draft/video-ram/
http://bart.vanhauwaert.org/hints/installing-win10-on-KVM.html
https://wiki.archlinux.org/index.php/QEMU#qxl
https://lists.freedesktop.org/archives/spice-devel/2015-June/020459.html
https://askubuntu.com/questions/46197/how-to-check-video-memory-size

xrandr
https://wiki.archlinux.org/index.php/xrandr
https://wiki.gentoo.org/wiki/Xrandr
https://pkg-xorg.alioth.debian.org/howto/use-xrandr.html
https://bbs.archlinux.org/viewtopic.php?id=199100
https://unix.stackexchange.com/questions/227876/how-to-set-custom-resolution-using-xrandr-when-the-resolution-is-not-available-i
https://wiki.ubuntuusers.de/RandR/
https://axebase.net/blog/2011/07/27/hinzufuegen-einer-aufloesung-ueber-cvt-und-xrandr/

CVT
http://www.uruk.org/projects/cvt/

Assumptions for test scenarios

Make backups

Basic security considerations

Preparational step 1: Settings in “/etc/libvirt/qemu.conf” and the integration of Spice with Qemu

Preparational step A: A brief look a “/etc/libvirt/libvirtd.conf” – allow a selected standard user to use virt-manger or virsh

Preparational step B: Restart libvirtd or reload its configuration after changes to qemu.conf, livirtd.conf or changes to XML-definition files for VMs

Preparational step C: Configure the VM to use a Spice-console – and some other devices

Preparational step D: Starting the VM – and “Where do I find logs for my VM”?

Method 1: Local access to the Spice console with remote-viewer

Netstat reveals multiple connections corresponding to Spice channels

Testing the “one seat situation” at a Spice console

Restricting access by setting a password

Conclusion

Links

Limitations

Basic preparations of a KVM/Qemu VM: Documentation and guides?

Spice with multiple screens requires a non default configuration of the VM’s QXL device

Spice and libvirt => multiple methods to access exactly one graphical console of a KVM/Qemu based VM

Different access options to the Spice console of a KVM/Qemu-based VM

Option 1: Simple connection with “remote-viewer” via a Spice (network) port

Option 2: Connection with “virt-viewer” or “virt-manager” via libvirtd and a defined TCP port

Option 3: Connection with “virt-viewer” or “virt-manager” via SSH and libvirtd

Conclusion

Links

Further articles in this series

The problem: Unreadable, freezing interfaces on spice-clients

Independent test with a new installation of a “Leap 15”-guest-system

Tests 2: Upgrade to latest KVM / QEMU / libvirt – versions of the “Virtualization” repository

Repair of the older upgraded guest-systems

Repair of the freshly installed Leap 15 guest-system

Adjustment of the TTYs and KDE

Conclusion

Offene Fragen => Themen dieses Artikels

Zugriff auf virtualisierte Hosts über Netzwerke

Auflösungen und Vertikalfrequenzen des Gastdesktops jenseits der Möglichkeiten eines (einzelnen) physikalischen Monitors

Persistenz der Auflösungseinstellungen

Persistenz der Auflösungseinstellungen für den “Display Manager” bzw. den Login-Schirm

Automatische (!) Auflösungsanpassung des Gast-Desktops an die Größe des Spice-Client-Fensters

Mit welchen Gastsystemen funktioniert die automatische Auflösungsanpassung?

Fazit

Ausblick

Voraussetzungen: Grafischer Zugriff auf das Gstsystem

Problemmeldung eines Lesers

Einsatz von xrandr und CVT auf dem Host als Ausgangspunkt …

Einsatz von xrandr

Funktioniert xrandr auch innerhalb von KVM/QEMU-Gastsystemen?

Spice und QXL aktivieren

Parameter für das Video Memory des QXL-Devices

Rücksichtnahme auf den verfügbaren RAM des Hosts!

Abändern der Parameter in den Domän-Dateien von libvirt

Überprüfung des angeforderten und des tatsächlich bereitgestellten Video-Speichers

Further
articles in this series