DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – II

Im letzten Artikel dieser Serie

DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – I

hatte ich festgestellt, dass ein regelmäßiger Mailaustausch mit Kunden zu einem DSGVO-Thema werden kann. Die Herausforderung für einen Freelancer ist dabei, dass Datenschutz auf seiner Seite auch in Maßnahmen zur Datensicherheit für Mailinhalte münden muss. Diese Maßnahmen muss der Auftraggeber kennen (s. Art. 28 und Art. 32 der DSGVO).

Datensicherheit von E-Mails – im Besonderen im Sinne der Vertraulichkeit – erstreckt sich natürlicherweise auf die Absicherung des Transports und der Lagerung. Der alleinige Zugriff durch den Berechtigten (Adressaten) ist zu gewährleisten. Das ist nicht so viel anders als bei Dateien auch. Akzeptiert man erst einmal, dass E-Mails eine Personenbezug aufweisen, muss man sich um dieses Thema im Sinne DSGVO kümmern – und zwar von vornherein in Kooperation mit seinem Auftraggeber (s. Art. 28).

Ich möchte in diesem Artikel nochmals auf meine Motivation zu vertraglichen Regelungen eingehen, obwohl das für den einen oder anderen technisch interessierten Leser womöglich langweilig sein mag. Der Grund für diesen Einschub ist, dass ich in einigen Diskussionen, die ich seit dem letzten Artikel geführt habe, immer wieder von Kollegen darauf hingewiesen wurde, dass ein solcher Aufwand bei Kleinst-Unternehmen (mit einer Mitarbeiterzahl < 250) womöglich gar nicht nicht nötig sei.

Wirklich nicht ?

DSGVO und vertragliche Vereinbarungen auch für KMU?

Ja, es gibt in der DSGVO den Hinweis auf Unternehmen mit weniger als 250 Mitarbeitern. Primär in Art. 30. In Art. 40 wird ferner darauf hingewiesen, dass die EU-Mitgliedsländer “Verhaltensregeln” erarbeiten sollen, die auf die besonderen Bedürfnisse von Kleinst- und Kleinunternehmen Rücksicht nehmen. Tja, kennt die Regeln für Deutschland jemand? Ich nicht ….

In Art. 30 geht es aber “nur” um eine mögliche Befreiung von der Pflicht zum Führen eines “Verzeichnisses von Verarbeitungstätigkeiten” (für personenbezogene Daten). Dies ersetzt jedoch nicht Art. 28 – und der verlangt eindeutig eine Verarbeitung zu schützender personenbezogener Daten auf Basis eines Vertrages. Das ist meine erste Motivation für vertragliche Regelungen in puncto E-Mail-Austausch.

Nun könnte man ins Feld führen, dass der Zugriff auf E-Mails, die einem ein Kunde (freiwillig) schickt, keine echte Weiterverarbeitung von persönlichen Daten darstelle. Der Kunde willige durch das Senden ja in eine potentiell unsichere Form der Verarbeitung ein. Das mag im Einzelfall vielleicht so sein. In größeren Projekten hat man es aber mit einer Vielzahl von Mails verschiedener Personen zu tun, die sich systematisch mit Sachverhalten auseinandersetzen. In den Mails befinden sich im Abspann meist weitere persönliche Kontaktdaten; damit ist ein Personenbezug gegeben. In den vielen Mail-Texten befinden sich zudem ggf. Inhalte vertraulicher Natur über den Absender oder Dritte oder aber das Projekt. Im Zuge eines Projekts werden Aufgaben, Verhalten, Arbeitsweise, Probleme und ggf. Meinungen der verschiedenen Absender meist deutlich aus dem Mailverkehr ersichtlich. Ist man ehrlich, so wird man zugeben: In projektbezogenen Mails stecken in Summe erhebliche Mengen an direkt oder indirekt personenbezogenen Informationen. Das ist meine zweite Motivation.

Hinzu kommt: In Projekten ist ein solcher Informationsfluss auch an externe Freelancer sehr regelmäßiger Natur. Und Mails werden ebenso regelmäßig von selbigen Externen gespeichert – auch um im Bedarfsfall nachweisen zu können, was man wann und warum für den Auftraggeber geleistet hat. Mach ich
auch genau so. Deswegen scheinen mir hier dann die Einschränkungen von Art 30. Punkt 5 der DSGVO zu greifen: Da ist die Verpflichtung zum Tätigkeitsverzeichnis nur bei nicht regelmäßigem Datenaustausch ausgenommen. Ich meine aber ganz generell, dass im Kontext des regelmäßigen Mailaustauschs in Projekten ein Nachdenken über Datenschutz gefragt ist. Das ist meine dritte Motivation für vertragliche Vereinbarungen.

In Projektmails werden zudem oft Dateien als Anhänge transportiert, die Informationen über Projektinhalte enthalten. Mit irgendwas muss der externe Freelancer ja arbeiten! Nun wird jeder vernünftige Arbeits- oder auch Berater-Vertrag den Freelancer zur Geheimhaltung solcher Informationen verpflichten und dazu auch technische Maßnahmen auf der Höhe der Zeit einfordern. Es geht dann also um eine direkte Anforderung des Auftraggebers, elektronisch übermittelte Informationen des Auftraggebers zu schützen. Hierfür gelten Datenschutzgesetze ganz generell und auch ganz unabhängig von der DSGVO – brisant wird der Informationsaustausch über Mail im Sinne der DSGVO aber zusätzlich durch die Kopplung an einen identifizierbaren Absender. Das ist meine vierte Motivation für vertragliche Regelungen.

Ein weiterer Beweggrund ist folgender: Man sollte sich auch als Kleinst-Auftragnehmer sehr klar darüber werden, welches Schutzniveau man als Einzelperson zu vertraulichen Daten (hier: Mails) überhaupt mit welchen Maßnahmen anbieten kann – und welche Restrisiken verbleiben.

Eine letzte starke Motivation für eine vertragliche Fixierung von Maßnahmen ist sozusagen die “Mithaftung” des Auftraggebers: Ich denke, es ist für einen Auftragnehmer immer besser, wenn er im Schadensfall nachweisen kann, dass der Auftraggeber über die Maßnahmen und Risiken bei der Daten-/Informations-Vrarbeitung durch den Auftragnehmer – also durch den Freelancer – volle Kenntnis hatte. Und dies gilt eben auch bzgl. der Mail-Verarbeitung.

Aus all diesen Gründen sollte man wegen der DSGVO (aber nicht nur wegen ihr) verschiedene Punkte zur Mailverarbeitung mit dem Auftraggeber in einem Vertrag hinterlegen. Die Grundlage für solche Vereinbarungen bieten wie gesagt Art. 28 und auch 32 der DSGVO – auch für Unternehmen mit weniger als 250 Mitarbeitern.

Kritische Punkte bzgl. des Mailschutzes

Die Liste der Hauptkapitel in einem Katalog an Verarbeitungstätigkeiten bzgl. Mails ist im Prinzip recht einfach:

Empfang, Versand, Einhaltung von Transport-Verfahren und Transportwegen, Lagerung, Löschung, Umgang mit Anhängen.

Zu den kritischen Punkten zählt dabei vor allem der Umgang mit nicht oder nicht mehr verschlüsselten Mails an Stationen, an denen Vertraulichkeit potentiell gefährdet ist. Das betrifft u.a. Postfächer beim Provider als auch die Mailhandhabung in Postfächern auf eigenen Server- und Client-Systemen.

Wie sichert man also E-Mails dauerhaft, etwa im Sinne der Vertraulichkeit? Die vernünftigste Antwort darauf hatten wir schon im letzten Artikel angesprochen:
Ende-zu-Ende-Verschlüsselung mit OpenPGP – insbesondere dann, wenn neben personenbezogenen auch wirtschaftlich relevante Geheimnisse ausgetauscht werden. Die Option zur OpenPGP-Verschlüsselung bietet deswegen u.a. auch DE-Mail an.

Was, wenn sich der Auftraggeber darauf aber nicht einlässt? Im Einzelfall besteht dann zwar noch die Option, Zip-Anhänge mit AES zu verschlüsseln und sich die Passwörter über einen anderen Kanal mitzuteilen. Bei hoher Mailfrequenz wird dieser Weg aber schnell unpraktisch. Es bleibt die Verschlüsselung des Transportwegs; die Mails selbst landen hingegen unverschlüsselt in Postfächern.

E-Mail-Lagerung beim Provider?

Typischerweise passieren Mails in Richtung auf einen eigenen Server oder Client des Freelancers zunächst einen Provider. Aus Sicht des Kunden und der DSGVO ist also ein Unterauftragnehmer involviert. Gemäß der DSGVO gilt es für den
Freelancer also, mit seinem Internet und/oder Mail-Provider einen Auftrags-Daten-Verarbeitungsvertrag abzuschließen.

Man ist als Freelancer versucht, Mails z.T. sowohl in Postfächern beim Provider als auch auf eigenen Servern zu halten. Motive sind : Mobilität und eine Art “Backup”-Politik. Die Frage ist, ob das deinem Auftraggeber so überhaupt recht ist. Ggf. traut dein Auftraggeber deinem Provider ja noch weniger als dir …

Wird ein deutscher Provider mit Servern in Deutschland und ggf. ISO 27001-Zertifizierung für eine Lagerung von E-Mails auch vom Auftraggeber als hinreichend sicher akzeptiert, sollte man dies in jedem Fall als gemeinsame Vereinbarung in einem Vertrag festhalten.

Im anderen Fall wird dein Auftraggeber den Mailserver des Providers höchstens als Durchgangsstation akzeptieren. Deshalb sollte man die Risiken, die mit einer temporären Zwischenlagerung beim Provider verbunden sind, nennen und vom Auftraggeber akzeptieren lassen. Dazu gehört potentiell auch, dass der Provider ggf. an gesetzliche Vorgaben bzgl. einer Datenvorratshaltung gebunden ist und bestimmte Mail-Daten ggf. auch an Sicherheitsbehörden weitergibt.

Spam-Filterung auf Servern von Drittanbietern?

Eine weitere Station, die eine Mail ggf. auf dem Weg zum eigenen IMAP-Server passiert, mag ein Spam-Filter auf einem Server im Internet sein. Mails passieren bei mir zunächst Amavis, werden auf Viren geprüft und an Spamassassin mit Bayes-Filter weitergereicht. Danach wird für Mails unbekannter Absender aber auch ein Spam-Server im Internet – nämlich ein Razor-Server – für die Spam-Filterung eingebunden.

Hier ist die Frage, was genau passiert: Wird die gesamte Mail für einen Check übermittelt – oder werden wie im Fall von “Razor” nur Prüfsummen übermittelt? Und in welchem Land genau stehen die Spamfilter-Server und welcher Rechtsprechung unterliegen sie?

Auch hier ist eine Vereinbarung mit dem Auftraggeber gefragt, was er denn so zulassen möchte. In der Regel wird eine Übermittlung des Volltextes ausgeschlossen werden müssen. Das erfordert ggf., dass man Mails, die on bestimmten Absendern oder aus bestimmten Postfächern beim Provider stammen, auf eigenen Mail-Gateways absenderspezifischen Filter- und Verarbeitungsregeln unterwerfen muss.

E-Mail-Lagerung auf eigenen Systemen und Verschlüsselung

Irgendwann landen die Mails aber auf eigenen Systemen. Dort gilt meiner Meinung nach vor allem eins:

Die Mails dürfen nicht unverschlüsselt gelagert werden!

Es besteht sonst die Gefahr des Datenklaus bei Einbrüchen oder anderen unerlaubten Systemzugängen – auch im heruntergefahrenen Zustand. Das gilt nicht nur für Laptops; es betrifft auch Desktop- und Server-Systeme im Heim- oder Firmennetz. Denn normalerweise kann ein Freelancer keinen hinreichenden Zugangsschutz zu seinen Systemen gewährleisten. Die schöne Klausel

gemäß oder unter Berücksichtigung des “Stands der Technik”,

die im Zusammenhang mit Datenschutz und der DSGVO immer wieder auftaucht, schließt heute wohl Verschlüsselungslösungen als Standard ein. Deren Einsatz beträfe dann eigene Mail-Server und Mail-Client-Systeme gleichermaßen.

Übrigens: Das gilt nicht nur für Mails sondern im Grunde für jede Art vertraulich zu behandelnder Dateien.

Reichen Verschlüsselungscontainer etwa auf Basis von Veracrypt?

OK, E-Mail-Lagerung in verschlüsselter Form. Damit sind wir schon beim nächsten Problem:

Reine Datei-Container allein sind für eine verschlüsselte Lagerung unzureichend, da Programme, mit denen man E-Mails oder deren Anhänge öffnet und verarbeitet, ggf. Backups- oder Kopien in unverschlüsselten Bereichen der Systemplatten ablegen. Typisch sind etwa “bak”-Dateien von Office-Programmen oder Editoren.

nVerschlimmert wird die Situation zudem noch durch den Einsatz von SSDs mit Wear Leveling. In die SSD integrierte Controller schaufeln ggf. unverschlüsselte Daten in SSD-Bereiche, die vom OS aus nicht ohne Spezialtools zugänglich sind. Ein Hautpentwickler von Veracrypt warnt etwa explizit vor dem Einsatz des Veracrypt-Containers auf (unverschlüsselten) SSDs.

Um Leckagen über solche Seitenkanäle zu vermeiden, sind deshalb verschlüsselte Partitionen oder verschlüsselte “Volumes” erforderlich, auf denen das Betriebssystem [OS] und seine Applikationen in Gänze arbeiten.

In der Größe flexibel anpassbare “Volumes” werden unter Linux typischerweise über einen LVM-Layer oberhalb von Partition der Festplatten genutzt. Unter Linux muss man sich also auch Gedanken über das Zusammenspiel von LVM und Verschlüsselung machen.

Mehr dazu im nächsten Artikel: DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – III

 

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

Will man auf einer Linux-Workstation den Desktop eines virtualisierten KVM/QEMU-Gastsystems [VM] nutzen, so wird man typischerweise auf die Kombination QXL und Spice-Client-Fenster setzen. Der Desktop des virtualisierten Gastsystems wird dann im Spice-Fenster auf dem normalen Desktop der Workstation dargestellt. In den letzten Artikeln dieser Serie hatten wir uns mit Konfigurationsmöglichkeiten zur Nutzung hoher Auflösungen auseinandergesetzt. Der erste Artikel

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

befasste sich mit Konfigurationsmöglichkeiten des QXL-Devices (memory, heads), die sich nicht direkt über das Tool “virt-manager” beeinflussen lassen. Ich hatte u.a. für die Memory-Dimensionierung Formeln angegeben; die resultierenden Daten kann man in die Konfigurationsdateien der virtuellen “Domäne” (also der VM) einbringen. Im zweiten Artikel

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

hatte ich dann den Einsatz von “xrandr” für hohe Auflösungen des “Desktops auf dem Betrachtersystem” und des darzustellenden “Desktops des QEMU-Gastes” vertieft. Dabei waren wir auch auf den QXL-Treiber und die Bedeutung des “spice-vdagents” (bzw. des zugehörigen Services) im Gastsystem eingegangen. Der letzte Artikel

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

zeigte dann, dass man für den Desktop des QEMU-Gastes auch Auflösungen und Vertikalfrequenzen anfordern kann, die durch den Monitor auf dem Betrachtersystem mit seinen Spice-Clients physikalisch nicht unterstützt werden. Anschließend wurden Möglichkeiten diskutiert, gewünschte Modline- und xrandr-Einstellungen im jeweiligen Linux-System persistent zu verankern.

Wir hatten ferner gesehen, dass man Spice-Fenster auch mit einer speziellen Option „Auto resize VM with window“ benutzen kann. Diese Option sorgt dafür, dass sich die Auflösung des Gast-Desktops automatisch an die Größe des Spice-Fensters anpasst. Das ist u.a. nützlich für den Einsatz von ausgedehnten Spice-Clients auf einem Multi-Monitor-System des Betrachters. Voraussetzung ist für sehr hohe Auflösungen eine hinreichende Ausstattung des QXL-Devices mit Video RAM.

Gibt es Defizite für die Praxis? Ja …

Der Desktop des virtualisierten Systems lässt sich nämlich mit den bisher diskutierten Verfahren nicht angemessen in mehrere Darstellungsflächen unterteilen. Natürlich stehen unter dem Desktop des Linux-Gastes alle Optionen für virtuelle Arbeitsflächen und Aktivitäten innerhalb dieses Desktops zur Verfügung. Aber:

Man kann das Spice-Fenster in der bisher benutzten grafischen “spice-console” des “virt-managers” nicht in mehrere unabhängig positionierbare Fenster auf dem Desktop des Betrachters unterteilen.

So ist es mit der Spice-Konsole nicht möglich, z.B. 2 verschiedene Applikationen des virtualisierten Systems unabhängig voneinander und jede in einer bestimmten Fenstergröße auf dem Desktop des Betrachters (z.B. auf der Workstation) anzuordnen. Wäre das möglich, dann könnte man als Nutzer gleichzeitig etwas in Richtung einer sog. “seamless integration” unternehmen.

Hinweis: Einen echten “Seamless Mode” wie ihn etwa VMware oder Virtual Box anbieten, gibt es zur Zeit nicht. Aber man arbeitet wohl daran: https://www.spinics.net/lists/spice-devel/msg30180.html

Jedenfalls ist es aus prinzipiellen Gründen und wegen einer verbesserten Ergonomie im Umgang mit virtualisierten Systemen interessant, sich den Desktop eines QEMU-Gastes unter Spice und QXL mal mit mehreren “virtuellen Monitoren” anzusehen. In der Spice-Terminologie ist hier von virtuellen “Displays” die Rede. Die sind Thema dieses Artikels.

Voraussetzung 1 der Nutzung mehrere virtueller Displays: Mehrere Heads, hinreichender Speicher des QXL-Devices und aktiver vdagent-Service

Als ich das erste Mal versucht habe, mehrere virtuelle Monitore auszuprobieren, funktionierte überhaupt nichts. Ursache:

Die Standardeinstellungen für das QXL-Device sind so, dass nur 1 Head aktiv ist. Zudem sind die Standardeinstellungen für den QXCL Video RAM unzureichend.

Beides ist zu ändern. Wir hatten die entsprechenden Einstellungen und Formeln für das QXL-Memory bereits im ersten Beitrag der Serie diskutiert. “virt-manager” bietet entsprechende Einstellungsoptionen zum QXL-Device aber nicht an. Man muss also zuerst mal die Domän-Datei “NAME.xml” im Verzeichnis “etc/libvirt/qemu” anpassen. “NAME” ist dabei der Name der virtuellen Maschine [VM]. Typische Memory-Werte für 4 Heads hatte ich bereits im ersten Artikel angegeben; s. dort für die notwendigen Schritte.

Das Gute an Linux-Gastsystemen ist, dass man danach außer der Aktivierung des QXL-Treibers und des “vdagents” (bzw. des zugehörigen Services) nichts anderes tun muss, um eine Unterstützung von bis zu 4 virtuellen Displays unter KVM/QEMU/Spice zu bekommen.

In gewisser Weise und im Gegensatz zu Tools wie X2GO arbeitet das Gastsystem hier keineswegs “headless”. Der Treiber des virtuellen QXL-Devices gaukelt dem Linux-System des Gastes vielmehr vor, dass das dortige QXL-Grafik-Device tatsächlich mehrere Ausgänge besitzt, die ein geeigneter Spice-Client dann (in Kooperation mit dem vdagent und dem QXL-Treiber) dynamisch mit angeschlossenen “Displays” belegt. Für deren Inhalt ist die Desktop-Umgebung des Gastes selbst verantwortlich. Spice übernimmt “nur” den Datenaustausch mit fenstern zur Darstellung dieses Desktops im Betrachtersystem.

Ich setze nachfolgend voraus, dass die QXL-Einstellungen entsprechend den Vorgaben des ersten Artikels für 4 Heads des QXL-Devices vorgenommen wurden. Getestet habe ich konkret mit folgenden QXL-Einstellungen:

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

 
Dem “Debian 9-Gastsystem” selbst hatte ich großzügigerweise 4GB RAM (Hauptspeicher) spendiert.

Voraussetzung 2 für mehrere virtuelle Displays: Nutzung des “remote-viewers”

Die grafische “spice-console” des “virt-managers” unterstützt meines Wissens keine Darstellung des Gastdesktops in mehreren “Displays”. Ein passender Client hierfür ist dagegen der sog. “remote-viewer“.

Man kann den “remote-viewer” von einem Terminalfesnter starten, nachdem man die virtuelle Maschine per “virt-manager” gestartet hat. Wir betrachten hier den Aufruf auf einer Linux-Workstation, die gleichzeitig als KVM-Host dient (Aufrufe über Netz werden Thema eines eigenen Artikels):

myself@mytux:~> remote-viewer spice://localhost:5900 &

Die Portnummer muss man ggf. anpassen, wenn man hierfür eine abweichende Einstellungen vorgenommen hat.

Hinweis: Unter Opensuse und Debian muss man ggf. Mitglied der Gruppe “libvirt” sein, um den remote-viewer erfolgreich ausführen
zu können; unter Ubuntu Mitglied der Gruppe “libvirtd”.

Sollte man vorher bereits einen anderen Spice-Client zur Darstellung des Gast-Desktops gestartet haben, wird diese frühere Spice-Sitzung unvermittelt und ohne Warnung abgebrochen.

Aktivierung zusätzlicher Bildschirme

Ein Blick auf die verfügbaren Menüpunkte zeigt schnell Unterschiede zur “spice-console”. So bietet der Menüpunkt “Ansicht >> Displays” Checkboxen für 4 Monitore (entsprechend den 4 Heads unseres QXL-Devices).

Man sieht, dass ich hier drei (virtuelle) “Displays” aktiviert habe. Der nachfolgende Screenshot zeigt diese “Displays” für die Darstellung des Desktops eines Debian 9-Gast-Systems auf einem von 3 physikalischen Monitoren einer Linux-Workstation, auf der selbst ein KDE-Desktop aktiv ist.

Zusätzliche virtuelle Displays erst nach dem Login aktivieren!

Der nächste Hinweis hat vielleicht nur Gültigkeit für einen Debian-Gast mit gdm3, aber mindestens mal da erweist sich der Tipp als nützlich:

Öffnet man im “remote-viewer” mehrere Displays, wenn noch die primäre Login-Maske von gdm3 angezeigt wird, so verschwindet die bei mir dann nach dem Aktivieren weiterer Displays – bzw. passte sich nicht mehr automatisch an den Fensterrahmen des ersten Displays an. Das ist wirklich unangenehm, weil man sich dann nicht mehr so ohne weiteres einloggen kann und zwischenzeitlich wieder auf die Spice-Konsole von virt-manager ausweichen muss. Also:

Erst einloggen, dann weitere virtuelle Displays aktivieren.

Automatische Auflösungsanpassung an die Größe der virtuellen Displays

Im “remote-viewer” gibt es keinen Menüpunkt zum Aktivieren/Deaktivieren einer automatischen Auflösungsanpassung an die Größe der aktivierten Displays. Das wird automatisch gemacht – unabhängig davon, was man vorher ggf. in der spice-console von virt-manager eingestellt haben sollte. Bei mir führte eine Veränderung der Größe irgendeines der geöffneten Displays zu einem Flackern aller virtuellen Displays, bis sich die neue Desktop-Darstellung aufgebaut hatte. Aber immerhin – die Anpassung funktioniert. Dabei gilt:

Die Spice-Fenster für die virtuellen Displays können völlig unterschiedliche Größen haben. Der Desktop des Gastes passt sich daran an!

Nahtloser Übergang zwischen den Displays

Es ist möglich, Applikationen nahtlos zwischen den verschiedenen Displays hin und her zu schieben. Dabei legt Spice in Abhängigkeit von verschiedenen Faktoren in sehr sinnvoller Weise fest, welches Display sich links oder rechts vom aktuellen Display befindet. Relevant ist dabei zum einen die Positionierung, die bei der letzten Größenänderung eines der Displays gegeben war:

Befand sich etwa “Display 3” bei der letzten links vom “Display 1”, so kann man eine Anwendung nach links aus dem “Display 1” in das “Display 3” bewegen – egal wo Display drei gerade ist.

Ein weiterer Faktor ist aber auch die Position der Maus – kommt die beim Ziehen in ein anderes Display (desselben Gastes), bewegt sich auch die Applikation dorthin.

Quasi-seamless Mode?

Wie gesagt, einen echten “Seamless Mode” bietet Spice noch nicht an. Aber: Wir können zumindest bis zu 4 Applikationen den Rahmen jeweils eines der 4 möglichen virtuellen Displays vollständig
füllen lassen – und auf dem Desktop der Workstation verteilen.

Das Schöne ist: Bei einer Größenänderung des jeweiligen virtuellen Displays passt sich die dort enthaltene Applikation dann automatisch an die Rahmengröße an.

Das nachfolgende Bild zeigt hoffentlich, was ich meine:

Hier sieht man von links nach rechts:

  • 1 virtuelles QXL/Spice-Display eines KVM/QEMU-Debian 9-Gastes mit Gnome, in dem VLC eine aktuelle ARD-Sendung abspielt.
  • 2 Clementine-Fenster, die dem KDE-Desktop der Workstation originär zugehören.
  • 1 virtuelles QXL/Spice-Display des KVM/QEMU-Debian 9-Gastes, in dem Libreoffice Draw geöffnet ist.
  • 1 Libreoffice Draw-Fenster, dass originär im KDE-Desktop der Workstation gestartet wurden.

Auf den ersten Blick sind die verschiedenen “Fenster” aber nicht als originale Fenster des KDE-Desktops der Workstation oder als Spice-Displays für die Darstellung des Gastdesktops einzuordnen. Das ist fast seamless und damit kann ich gut leben …

Multi-Monitor-Support im Gnome-Desktop des Gastes

Obwohl spezifisch für Gäste mit Gnome3-Desktop, hier ein kleiner Hinweis zur Multimonitor-Unterstützung: Man sollte sich hierfür unedingt ein paar aktuelle “Gnome-Extensions” installieren.

Die aktuellste Version von “Dash to dock” etwa erlaubt etwa die Auswahl des Spice-Displays, auf dem das Dock-Panel angezeigt werden soll. Und dann gibt es auch noch die sehr nützliche Erweiterung “Multi-Monitors AddOn”; sie erlaubt es verschiedene Informationsleisten etc. auf allen Displays anzeigen zu lassen:

Off-Topic: Was ist eigentlich mit Sound?

Nachdem ich oben in einer Abbildung einen Fernsehstream in einem Linux-Gast laufen ließ: Ist eigentlich eine Übertragung von Sound aus dem virtualisierten Gast in die Workstation möglich? Ich gehe auf diesen Punkt nur kurz ein, da dieser eigentlich nicht Thema dieser Artikelserie ist. Mir sind zudem auch noch nicht alle Zusammenhänge für den Soundtransfer klar. Es scheint jedoch so zu sein, dass das weniger ein Spice- als vielmehr ein QEMU-Thema ist.

Tja, und dann stolpern wir bei Internet-Recherchen erwartungsgemäß mal wieder über das Thema “Pulseaudio“. Vermutlich muss QEMU nämlich das Sound-Backend des KVM-Hosts unterstützen. Die Unterstützung verschiedener Soundsysteme ist aber etwas, was man bereits bei der Kompilierung von QEMU einstellen muss. In den meisten Distributionen (hier Opensuse) ist das QEMU-Paket aber lediglich mit Pulseaudio- und nicht mit reiner Alsa/Gstreamer-Unterstützung erstellt worden. Ergebnis:

Mit dem Standardpaket von QEMU unter Opensuse habe ich auf einem KVM-Host nur eine problemfreie Soundübertragung hinbekommen, wenn sowohl im Gastsystem als auch im Hostsystem Pulseaudio aktiv waren. Pures Alsa auf einer Linux-Workstation und KVM/QEMU-Virtualisierung sind zusammen wohl nicht ohne experimentellen Aufwand zu haben.

Mit Pulseaudio klappt die Soundübertragung aber gut – soweit Pulseaudio halt selbst mit den Gegebenheiten der Arbeitsstation (Soundkarten, Anwendungen) vernünftig umgehen kann. Und da gibt es nach wie vor Zipperleins. Immerhin kann man den Sound der virtuellen Maschine über Spice dann auch durch den systemweiten Ladspa-Equalizer von PA auf dem Betrachtersystem – hier also der Workstation
selbst – jagen. Das sieht dann etwa so aus:

Man beachte den “Remote Viewer”-Kanal im Lautstärke-Regler und dessen Verlinkung mit dem Ladspa-Equalizer! Das Bild dient nur der Illustration – Clementine würde ich normalerweise direkt auf das Device “Simultaneous Output” abbilden und den in Clementine eingebauten Equalizer nutzen. Der ist nämlich für mein Gefühl in den Übergängen zwischen den verschiedenen Frequenzbereichen besser und sanfter abgestimmt.

Aber PA ist ja ein Thema für sich – auch wenn sich langsam das eine oder andere bessert und die Zahl der Ungereimtheiten im praktischen Betrieb wenigstens ein wenig zurück gegangen ist.

Ausblick

Es gibt zwei Themen, die bisher nur stiefmütterlich behandelt wurden:

  • Die Netzwerkfähigkeit von libvirt und Spice.
  • Der “virtio”-Grafiktreiber, der alternativ zum qxl-Treiber auf Workstations benutzt werden kann, die gleichzeitig als KVM-Host und Client zur Nutzung der VM dienen.

Beide Punkte werde ich in kommenden Artikeln behandeln, sobald ich Zeit dazu finde. In der Zwischenzeit wünsche ich dem Leser viel Spaß beim Einsatz von KVM, QXL, Spice und virtuellen Displays.

Links

Spice-Clients
http://www.datacenter-insider.de/die-besten-spice-clients-zur-erhoehung-der-netzwerk-und-festplatten-performance-a-468322/

virt-viewer
https://access.redhat.com/ documentation/ en-US/ Red_Hat-_Enterprise-_Linux/6/html/Virtualization-_Administration-_Guide/chap-virt-tools.html#sect-virt-viewer

remote-viewer
https://access.redhat.com/ documentation/ en-US/ Red_Hat-_Enterprise-_Linux/6/html/ Virtualization-_Administration-_Guide/sect-Graphic-_User-_Interface-_tools-_for-_guest-_virtual-_machine-_management–remote_viewer.html

In die Links wurden Minus-Zeichen eingefügt, um einen Umbruch zu erreichen. Die korrekte URL muss man sich über einen Rechtsklick besorgen.

 

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

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.