Tag Archives: QXL

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

Posted on by

In den ersten beiden Artikeln dieser Serie

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

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 – II

Posted on by

Diese Artikelserie befasst sich mit der Möglichkeit, hohe Monitor-Auflösungen auch beim Arbeiten mit Linux-Gastsystemen unter einem KVM/QEMU-Hypervisor zu nutzen. Dabei sollen das Spice-Protokoll und ein QXL-Device als virtuelle Grafikkarte des Gastsystems genutzt werden.

Wenn man mit einem virtualisierten System arbeitet, kann der Zugriff auf dessen Desktop entweder am KVM-Host selbst oder aber von einem Remote-System aus erfolgen. Bis auf weiteres konzentrieren wir uns auf das erstere Szenario, d.h. wir greifen unter einem Desktop des KVM-Hostes auf den Desktop des Gastes zu. Wir betrachten also den Fall mehrerer am Host selbst angeschlossener, hochauflösender Monitore, auf dem die Desktop-Umgebung des virtualisierten Gastsystems in einem oder mehreren Fenstern dargestellt werden soll. In einem solchen Szenario ist der durch Netzwerkprotokolle entstehende zusätzliche Komplexitätsgrad irrelevant.

Ausgangspunkt unserer Überlegungen des ersten Artikels war die Feststellung, dass nicht immer alle Möglichkeiten der physikalischen Monitore automatisch und richtig erkannt werden. Und selbst wenn das geschehen sollte, wird die Information nicht unbedingt korrekt an das Gastsystem weitergegeben. Dies gilt u.a. für externe Monitore. Dann ist Handarbeit angesagt. Besondere Vorkehrungen sind i.d.R. auch erforderlich, wenn man ggf. mehrere virtuelle Monitore eines Gastsystems nutzen und auf die physikalischen Schirme des Hosts verteilen will.

Im letzten Beitrag

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

hatte ich das Universaltool xrandr zur Konfiguration von Auflösung und Orientierung von Bildschirmen unter X-Window vorgestellt und bereits auf einem exemplarischen KVM-Host (Laptop mit Opensuse) eingesetzt. Danach hatten wir uns dem mittels “virt-manager” und QEMU virtualisierten Gastsystem zugewandt und uns ein wenig damit befasst, wie denn eine virtuelle Grafikkarte vom Typ QXL aussieht und wie man den dortigen Video RAM für hohe Auflösungen konfiguriert.

Wir gehen nun auf die Frage ein, welche Vorkehrungen im Gastsystems noch erforderlich sind, um einen oder mehrere hochauflösende virtuelle Monitore performant nutzen zu können. Abschließend wenden wir dann “xrandr” im Gastsystem an.

Zusammenspiel benötigter Komponenten

Wie greifen eigentlich die in unserem Szenario benötigten Komponenten Spice, virt-manager, libvirt, Qemu, QXL ineinander? Ich habe mal versucht, das in einer Skizze zu verdeutlichen:

Die Skizze stellt die Situation für einen Virtualisierungshost dar, an dem 3 physikalische Monitore angeschlossen sind. Ein auf diesem KVM-Host angemeldeter User greift mittels Spice-Clients auf das dort installierte Gastsystem zu. (Das ist ein typisches Szenario für Entwickler-Laptops oder Linux-Workstations, in dem man mittels Virtualisierung Eigenschaften eines Zielsystems darstellt.) Das Gast-OS läuft in einer virtualisierten Umgebung, die durch QEMU im Zusammenspiel mit KVM bereitgestellt wird; das virtualisierte System (also der “Gast”) wurde in der Skizze als QEMU VM (Virtual Machine) bezeichnet.

Die Spice-Komponenten sind gelblich dargestellt. “virt-viewer” und “remote-viewer” sind verschiedene Spice-Clients, die mit dem Spice-Server kommunizieren können. Diese Clients ermöglichen die Darstellung des grafischen Outputs des Gastsystems in einem Fenster. Ähnliches leistet auch die in “virt-
manager” integrierte “grafische Spice-Konsole“.

Ich habe versucht, in der Skizze anzudeuten, dass der Spice-Client “remote-viewer” ganz unabhängig von libvirt-Komponenten funktioniert (s. hierzu etwa Red Hat Virtualization Guide für RHEL 6, Kap. 17.2 .

Eine Skizze zur genaueren Struktur des QXL-Devices der QEMU VM mit bis zu vier “heads” für vier virtuelle Monitore von Linux-Gastsystemen hatte ich bereits im vorhergehenden Artikel geliefert. In der hiesigen Skizze habe ich die Situation für 2 “heads” angedeutet; 2 virtuelle Monitore des Gastes werden auf zwei physikalischen Monitoren in Spice-Client-Fenstern angezeigt.

Anmerkungen zur Client-Server-Struktur

Aus der Skizze geht die Client/Server-Struktur der Komponenten nicht so recht hervor, da im dargestellten Fall ja alles auf dem Virtualisierungshost abläuft. Aber sowohl Spice als auch libvirt/qemu sind netzwerkfähig und somit als Client/Server-Systeme ausgelegt. Der “Spice-Server” wie auch der Dämon “libvirtd” sind dabei immer auf dem Virtualisierungs-Server (also dem KVM-Host) zu installieren. Zur Konfiguration der Protokoll-Einstellungen auf einem Linux-Remote-System, von dem aus die Spice-Clients “Spice Console des virt-managers” bzw. der stand-alone Spice-Client “remote-viewer” über ein Netz mit ihren Gegenparts auf dem Virtualisierungshost kommunizieren sollen, siehe
https://www.spice-space.org/spice-user-manual.html
bzw.
https://libvirt.org/docs.html
https://wiki.ubuntuusers.de/virt-manager/.
Virtualization-Administration-Guide von Red Hat für RHEL 6

Im virt-manager bietet der Punkt “File” > Add new connection” Felder zur Konfiguration einer Verbindung an. Spice kann über SSH getunnelt werden; für virt-manager wird eh’ qemu+ssh angeboten.

Wie einleitend festgestellt, werden uns in dieser Artikelserie zunächst mit einer Konfiguration, wie sie auf der Skizze dargestellt ist, begnügen. Spezielle Netzwerk-Einstellungen entfallen dann.

QXL-Treiber und spice-vdagent

Auf der rechten Seite der obigen Skizze erkennt man das virtuelle QXL-Device. Die Skizze deutet hier an, dass im Betriebssystem [OS] des Gastes zwei Komponenten erforderlich sind, um die notwendige Unterstützung zu liefern – ein Treiber und ein sogenannter “spice-vdagent”. Wir müssen uns nun mit deren Bereitstellung im Gastsystem befassen. Es gilt:

  • Der qxl-Treiber ist, wie Video-Treiber für reale Karten auch, ein drm-fähiges Kernelmodul. “drm” steht dabei für “direct rendering manager”; https://de.wikipedia.org/ wiki/ Direct_Rendering_Manager).
  • Der spice-vdagent wird dagegen als Dämon bereitgestellt und ist als Service zu aktivieren.

Versionsabhängigkeiten und Test-Setup

Leider muss ich vor weiteren Details vorausschicken, dass sowohl das Laden des qxl-Kernel-Moduls als auch die faktische Wirkungsweise von qxl-Treiber und spice-vdagent stark von der Art/Version des Linux-Gastsystems, dessen Kernel und zu allem Überfluss auch noch von der dortigen Desktop-Version abhängen. Ich nehme als Beispiel mal Debian 8 “Jessie”:

Unter dem ursprünglichen Kernel 3.16 von Jessie lässt sich das qxl-Modul nicht ohne weiteres laden. Es verlangt einen mir
unbekannten Parameter. In Installationen, die Debian-Backport-Pakete nutzen, wird ab Kernelversion 4.2 das qxl-Modul dagegen automatisch geladen. Ferner hat das Laden des qxl-Moduls – je nach Kernelversion und Desktop-Version unterschiedliche Auswirkungen auf automatische Auflösungsanpassungen. Ich komme darauf in einem weiteren Artikel zurück.

Wer die nachfolgend beschriebenen Punkte in einer konsistenten Weise nachvollziehen will, sollte bzgl. der Gastsysteme deshalb auf ein aktuelles Debian 9 (“Stretch”) (mit Gnome, KDE 5) oder aber ein Kali 2017 (mit Gnome) zurückgreifen. Diese Systeme bilden im Moment aus meiner Sicht den Sollzustand am besten ab.

Wählt man dagegen Opensuse Leap 42.2, so bitte mit Gnome. Mit debian-8-basierten Systemen, neueren Kernel-Versionen, unterschiedlichen libvirt/spice-Versionen aus Backport Repositories sowie mit dem offiziellen Plasma5-KDE5/KDE4-Mix unter Opensuse 42.1/42.2 kann es dagegen abweichende Resultate geben. “Red Hat”-Gastsysteme habe ich bislang nicht getestet.

Test-Setup

  • KVM-Gast: Debian 9 “Stretch” (mit Gnome und KDE5) / Kali2017 (Gnome). Virtuelles Grafik-Device: QXL mit maximaler ram/vram-Bestückung.
  • KVM-Host: Linux-Systeme mit Opensuse Leap 42.2 und dem dortigen KDE5/Plasma5/KDE4-Mix; darunter auch der im letzten Artikel angesprochene Laptop mit einem externen HDMI-Schirm.
  • Grafischer Spice-Client für einen virtuellen Monitor: die “grafische Spice Konsole”, die in virt-manager integriert ist.
  • Grafischer Spice-Client für mehrere virtuelle Monitore: “remote-viewer” (muss ggf. über das Paket “virt-viewer” nachinstalliert werden).

Bereitstellung QXL-Treiber im Gastsystem

Die Kapazitäten und die Performance einer Grafikkarte können nur mit einem geeigneten Treiber vollständig genutzt werden. Das ist für virtuelle Grafik-Devices wie das QXL-Device nicht anders.

Für einen KVM-Gast kann man in einem Spice-Client in jedem Fall Auflösungen bis zu 1024×768 erreichbar – auch wenn der device-spezifische QXL-Treiber im Gastystem gar nicht installiert ist. (Dies wird durch einen Fallback auf einen “standard vga”-Treiber bzw. ein VESA Framebuffer-Device ermöglicht.) Will man dagegen mit höheren Auflösungen arbeiten, so kann dies ggf. auch ohne QXL-Treiber funktonieren; allein aus Performancegründen lohnt es sich aber zu überprüfen, ob der QXL-Treiber im Gastsystem geladen ist: 

root@deb11:~# lsmod | grep -iE "(video|qxl|drm)"
qxl                    69632  3
ttm                    98304  1 qxl
drm_kms_helper        155648  1 qxl
drm                   360448  6 qxl,ttm,drm_kms_helper

 
Falls das nicht der Fall sein sollte, muss man ggf. SW-Pakete nachinstallieren. Das Kernelmodul wird unter Debian über das Paket “xserver-xorg-video-qxl” bereitgestellt; unter Opensuse ist dagegen das Paket “xf86-video-qxl” erforderlich. (Zudem sollte “qemu-vgabios” installiert sein).

U.a. unter Opensuse Leap 42.2 lädt das Gastsystem den QXL-Treiber dann aber immer noch nicht zwingend automatisch. Das Modul ist in solchen Fällen also von Hand über “modprobe qxl” zu laden; den X-Server muss man dann neu starten. Ferner muss man sich darum kümmern, in welcher Weise man in seinem (Gast-) Betriebssystem dafür sorgen kann, dass Kernelmodule bereits beim Booten geladen werden:

Automatisches Laden des qxl-Kernelmoduls unter Opensuse Leap
Unter Opensuse kann man etwa “dracut -f” oder “mkinit” bemühen, nachdem man einer Datei “/etc/dracut.conf.d/01-dist.conf” einen Eintrag
force_drivers+=”qxl”
hinterlassen hat. Dabei wird das initramfs bemüht.
 
Alternativ und soweit systemd aktiv ist:
Im Verzeichnis “/etc/modules-load.d/” eine Datei “qxl.conf” anlegen und dort einfach “qxl” eintragen.
 
Als weitere Möglichkeit, die ich aber nicht getestet habe, legt man unter “/etc/X11/xorg.conf.d/50-device.conf” einen Eintrag der Form

Section "Device"
 Identifier "device0"
 Driver "qxl"
EndSection

an.

Automatisches Laden des qxl-Kernelmoduls unter Debian
Unter Debian-Systemen nimmt man dagegen einfach einen Eintrag in der Datei “etc/modules” vor. Debian 9 lädt das qxl-Modul aber eh’ schon automatisch, wenn es erkennt, dass es unter KVM/QEMU virtualisiert läuft und ein QXL-Device vorhanden ist .

OS-unabhängig über einen systemd-Service
Persönlich finde ich eigentlich ein kleines eigenes Skript, das man mit einer Service-Datei (qxl.service) versieht, am besten. Dort kann man nämlich z.B. über “lspci” vorab analysieren, ob überhaupt ein QXL Device zur Verfügung steht. Ich gehe auf diese Lösung aus Platzgründen aber nicht weiter ein.

Für alle Varianten gilt: Der Treiber sollte jedenfalls geladen sein, bevor der X- oder Wayland-Server gestartet wurde.

Bedeutung und Aktivierung des spice-vdagent

Der sog. “spice-vdagent” hat/hatte mehrere wichtige Aufgaben; ich stelle sie mal nach meinem Verständnis dar:

  • Kommunikations- und Event-Support: Der vdagent triggert und optimiert die Kommunikation zwischen dem Gast OS über den Spice-Server mit dem (remote) Spice-Client auf dem KVM-Host oder auf einem Remote-Host. U.a. werden Mouse-Positionen zwischen KVM-Gastsystem und Host abgeglichen und interpretiert – das ermöglicht u.a. ein nahtloses Verlassen von Spice-Fenstern auf dem Host.
  • Copy/Paste: Der vdagent ermöglicht beidseitiges Copy/Paste zwischen Applikationen des (Remote-) Host-Systems, auf dem das Spice-Fenster zur Ansicht des Gast-Desktops läuft, und Applikationen des KVM-Gast-Systems.
  • Multi-Monitor-Support: Er unterstützt im Zusammenspiel mit dem qxl-Treiber Gast-Systeme mit mehreren virtuellen Monitoren, deren Output in mehreren Spice-Remote-Viewer-Fenstern dargestellt werden kann. U.a. übernimmt er dabei das korrekte Mouse-Handling auf der Gast- wie der (Remote-) Host-Seite.
  • Auflösungsanpassung: Er ermöglichte eine automatische Anpassung der Auflösung des Gast-Desktops an die gewählte Größe des Spice-Client-Fensters auf dem (Remote-) Host.
    Hinweis: Das wird in aktuelleren Linux-Systemen aber wohl anders gemacht; s. hierzu den nächsten Artikel.
  • File-Transfer: Freigabe eines Zugriff des Gastsystems auf bestimmte Verzeichnisse des (Remote-) Hostes; File-Transfer mittels Drag & Drop

Man sieht: Der spice-vdagent hat etwa solche Aufgaben wie die “VMmware-Tools”, die in einem VMware-Gastsystem zu installieren sind.

Einen detaillierteren Überblick verschaffen die Web-Seiten https://www.spice-space.org/spice-user-manual.html#agent und https://www.spice-space.org/features.html
Die Platzierung des Agents im KVM-Gast und in der Kommunikationsstruktur entnimmt man der Skizze auf der Seite https://www.spice-space.org/index.html.

Die Nutzung des spice-vdagent erfordert bestimmte Voraussetzungen:

Vorbereitung der QEMU VM auf dem KVM-Host
Der Einsatz des spice-vdagents erfordert bestimmte Features der virtuellen Maschine und zugehörige Startoptionen für die QEMU VM. So muss ein bestimmtes Serial-Device vorhanden sein (s. die Skizze oben) und ein Kommunikationskanal für den Spice-Agent reserviert werden (https://wiki.archlinux.org/ index.php/ QEMU#SPICE). Man kann sich einige händische Arbeit durch das Anlegen der virtuellen Maschinen (“Domänen” im QEMU-Slang) mittels “virt-manager” ersparen:
“virt-manager” gibt die notwendigen Features automatisch vor und konfiguriert die zugehörigen QEMU-Optionen für den Start der virtuellen Maschine.

Maßnahmen im Gast-OS
Der spice-vdagent ist als systemd-Service ausgelegt und kann als solcher im KVM-Gastsystem enabled (über den nächsten Reboot hinaus) und gestartet werden.

root@guest:~#  systemctl enable spice-vdagentd.service
root@guest:~#  systemctl start spice-vdagentd.service

 
(Nachtrag 22.02.2018: Natürlich muss man den Agent erstmal installieren; hierzu nutzt man das Paket-Management des Gastsystems; unter Debian mittels “apt-get install spice-vdagent”. Um nach dem “Enablen” des zugehörigen Service z.B. Copy/Paste in beide (!) Richtungen zwischen Spiece-Konsole und der Umgebung ausführen zu können, muss man zudem die virtuelle Maschine und deren Konsole neu starten.)

Damit haben wir alles erledigt, was zur Performance-Optimierung, einer vernünftigen Mouse-Steuerung etc. notwendig war.

Einsatz von xrandr für unerkannte Auflösungsmodes im Gastsystem

Wir kommen nun wieder auf unser Laptop-Problem mit einer unerkannten Auflösung von 2560x1440_44Hz aus dem letzten Artikel zurück. Dort hatten wir bereits beschrieben, wie man den KVM-Host vorbereitet und die dort bislang unerkannte Auflösung auf einem externen HDMI1-Monitor mittels xrandr aktiviert. Wird dann die für den Host-Desktop bereitgestellte Auflösung auch auf dem Gastsystem automatisch erkannt?

Wir starten über “virt-manager” z.B. einen “Kali2017”-Gast und betrachten ihn über die grafische Spice-Konsole des virt-managers auf dem HDMI-Monitor; dabei unterbinden wir zunächst eine automatische Skalierung der Gastauflösung (darauf kommen wir später zurück):

Leider bieten dann weder ein Kali2017- noch ein Debian-Stretch-Gast die maximal mögliche Auflösung an:

Der Einsatz des QXL-Treibers und des vdagents hat in dieser Hinsicht also nichts verbessert. Dass beide SW-Komponenten samt QXL-Device im Gastsystem vorhanden sind, belegt folgender Output: 

root@kali2017-1:~# lsmod | grep qxl
qxl                    69632  3
ttm                    98304  1 qxl
drm_kms_helper        155648  1 qxl
drm                   360448  6 qxl,ttm,drm_kms_helper
root@kali2017-1:~# 

root@kali2017-1:~# systemctl status spice-vdagentd.service
● spice-vdagentd.service - Agent daemon for Spice guests
   Loaded: loaded (/lib/systemd/system/spice-vdagentd.service; enabled; vendor p
   
Active: active (running) since Thu 2017-07-13 09:49:54 CEST; 5min ago
  Process: 397 ExecStart=/usr/sbin/spice-vdagentd $SPICE_VDAGENTD_EXTRA_ARGS (co
  Process: 390 ExecStartPre=/bin/rm -f /var/run/spice-vdagentd/spice-vdagent-soc
 Main PID: 427 (spice-vdagentd)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/spice-vdagentd.service
           └─427 /usr/sbin/spice-vdagentd

root@kali2017-1:~# dmesg | grep drm
[    2.272876] [drm] Initialized
[    2.391864] [drm] Device Version 0.0
[    2.391865] [drm] Compression level 0 log level 0
[    2.391866] [drm] Currently using mode #0, list at 0x488
[    2.391866] [drm] 114686 io pages at offset 0x4000000
[    2.391867] [drm] 67108864 byte draw area at offset 0x0
[    2.391867] [drm] RAM header offset: 0x1fffe000
[    2.391868] [drm] rom modes offset 0x488 for 142 modes
[    2.391916] [drm] qxl: 64M of VRAM memory size
[    2.391917] [drm] qxl: 511M of IO pages memory ready (VRAM domain)
[    2.391917] [drm] qxl: 512M of Surface memory size
[    2.392479] [drm] main mem slot 1 [a0000000,1fffe000]
[    2.392479] [drm] surface mem slot 2 [c0000000,20000000]
[    2.392481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.392482] [drm] No driver support for vblank timestamp query.
[    2.392739] [drm] fb mappable at 0xA0000000, size 3145728
[    2.392740] [drm] fb: depth 24, pitch 4096, width 1024, height 768
[    2.392772] fbcon: qxldrmfb (fb0) is primary device
[    2.405136] qxl 0000:00:02.0: fb0: qxldrmfb frame buffer device
[    2.418839] [drm] Initialized qxl 0.1.0 20120117 for 0000:00:02.0 on minor 0

 
Hinweis:

Ob der spice-vdagent tatsächlich seinen Job tut, verifiziert man am einfachsten dadurch, indem man Copy/Paste-Übertragungen von Text zwischen Host- und Gast-System ausprobiert.

Einsatz von xrandr

Wir greifen im Gast nun zum gleichen Trick wie auf dem Host. Ein Absetzen des Befehls xrandr zeigt, dass der relevante (virtuelle) Monitor des Gastsystems “Virtual_0” heißt:

root@kali2017-1:~# xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
Virtual-0 connected primary 1024x768+0+0 0mm x 0mm
   1024x768      59.92*+
   1920x1200     59.88  
   1920x1080     59.96  
   1600x1200     59.87  
   1680x1050     59.95  
   1400x1050     59.98  
   1280x1024     59.89  
   1440x900      59.89  
   1280x960      59.94  
   1280x854      59.89  
   1280x800      59.81  
   1280x720      59.86  
   1152x768      59.78  
   800x600       59.86  
   848x480       59.66  
   720x480       59.71  
   640x480       59.38  
Virtual-1 disconnected
Virtual-2 disconnected
Virtual-3 disconnected

 
Also: 

root@kali2017-1:~# 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

root@kali2017-1:~# xrandr --newmode 2560x1440_44  222.75  2560 2720 2992 3424  1440 1443 1448 1479 -hsync +vsync
root@kali2017-1:~# xrandr --addmode Virtual-0 2560x1440_44
root@kali2017-1:~# xrandr --output Virtual-0 --mode 2560x1440_44

 

Und schon ist unsere gewünschte hohe Auflösung nach ein wenig Flackern im Spice-Fenster aktiv : 

root@kali2017-1:~# xrandr --current
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 8192 x 8192
Virtual-0 connected primary 2560x1440+0+0 0mm x 0mm
   1024x768      59.92 +
   1920x1200  
   59.88  
   1920x1080     59.96  
   1600x1200     59.87  
   1680x1050     59.95  
   1400x1050     59.98  
   1280x1024     59.89  
   1440x900      59.89  
   1280x960      59.94  
   1280x854      59.89  
   1280x800      59.81  
   1280x720      59.86  
   1152x768      59.78  
   800x600       59.86  
   848x480       59.66  
   720x480       59.71  
   640x480       59.38  
   2560x1440_44  43.99* 
Virtual-1 disconnected
Virtual-2 disconnected
Virtual-3 disconnected

 

Das im Bildausschnitt erkennbare farbige Hintergrundsbild außerhalb der Spice-Konsole stammt vom KDE-Desktop des Opensuse-Hosts; es wurde für den HDMI-Schirm festgelegt. Man erkennt, dass das Fenster der grafischen Spice-Konsole Scrollbalken anbietet, wenn der aktuelle Fensterrahmen zu klein für die Auflösung des Gast-Desktops ist. Wegen meines GTK-Themes werden die Scrollbalken nur angezeigt, wenn die Maus dem jeweiligen Fensterrand nahe kommt. Deshalb ist im Bild nur der vertikale Balken sichtbar.

Natürlich kann man das Spice-Fenster auf dem externen HDMI-Monitor auch im Vollbild-Modus betreiben. Am einfachsten geht das, indem man die Fenstergröße an die Gastauflösung anpassen lässt; die Spice-Konsole bietet aber unter “View” zudem einen eigenen Menüpunkt zum Wechsel in den Vollbild-Modus an:

Mein HDMI-Schirm mit 2560×1440 zeigt dann folgendes Bild:

Genau das war aber unser erstes Ziel:

Wir können die hohe Auflösung eines physikalischen Host-Monitors, auf dem ein Spice-Client-Fenster im Vollbild-Modus läuft, nun für die Darstellung des Desktops eines unter KVM/QEMU virtualisierten Gastsystems nutzen.

Anzumerken bleibt auch, dass die Spice/QXL-Performance selbst mit der relativ schwachbrüstigen Intel HD4000, die in der Laptop-CPU integriert ist, völlig annehmbar ist. Zu verdanken ist das vor allem dem Einsatz des QXL-Treibers.

Ausblick

Im nächsten Artikel

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

befassen wir uns damit, wie man die mit CVT und xrandr gefundenen bzw. definierten Modes persistent im Gast-System hinterlegt, so dass sie auch einen Boot-Vorgang überstehen. Zudem wollen wir die Auflösung auch für den Display-Manager (etwa gdm3) hinterlegen. Danach wenden wir uns der Frage zu, ob und wie eine automatische Auflösungsanpassung an den Fensterrahmen der Spice-Clients möglich ist.

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

Posted on by

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/