Monthly Archives: August 2017

Veracrypt, SSHFS und kryptierte Datenhaltung auf gehosteten Servern – I

Posted on by

Ich kenne einige Kleinstunternehmen und Freiberufler, die Kunden- oder gar Patientendaten bei einem Provider lagern wollen. Zu Backup-Zwecken oder gar für einen Remote-Zugriff. Für mich stellt sich da die Frage:

Wie weit kann und darf man seinem Provider für gehostete Server oder Cloud-Dienste eigentlich trauen?

Administratoren haben bei Internet-Providern ja nicht nur theoretisch, sondern je nach Berechtigungsstufe faktischen, d.h. administrativ-digitalen oder womöglich gar physikalischen Zugriff auf die gehosteten Systeme und angebundene Datenhaltungssysteme. Der potentielle Zugriff ist in vielen Hosting-Szenarien (Container-Technologie etc.) inhärent gegeben und für den ordnungsgemäßen Betrieb z.T. sogar notwendig; unabhängig davon, ob sich Administratoren für die gelagerten Inhalte interessieren oder nicht. Einen potentiellen Zugriff von IT-Verantwortlichen auf die Inhalte von Daten oder Datenströme auf gehosteten Systemen verhindert auch eine ISO 27001-Zertifizierung des Providers (z.B. von Strato) nicht zwingend. Gesetzliche Datenschutz- und Geheimhaltungsvorgaben – insbesondere für Patientendaten – sind in simplen Hosting-Szenarien deshalb nur schwer einzuhalten. Hinzu kommt das Risiko potentieller Schwachstellen in der Technik zur Isolation gehosteter Dienste oder virtualisierter Server gegeneinander – insbesondere bei Einsatz von Container-Technologien.

Für Daten, die im eigenen oder – oft noch wichtiger – im Kundeninteresse zwingend geheimzuhalten sind, ist daher folgende Regel angebracht: “Im Internet und in der “Cloud” gibt es keine Freunde”.

Sichere Ablage von privaten Dateien oder Kunden-Daten auf gehosteten Systemen?

Was also tun, wenn man oft unterwegs ist und eine Art sicheren, privaten Cloud-Dienst benötigt, der es einem bei Bedarf erlaubt, z.B. vom Notebook aus zumindest auf einzelne, wichtige Dateien zuzugreifen? Die aber niemand anderes einsehen soll?

Aufwand und Kosten für Betrieb und Absicherung eines eigenen, im Internet exponierten Servers sind für kleine Firmen und Freiberufler durchaus ein Thema … Dann will man einerseits gerne auf Hosting-Angebote zurückgreifen, andererseits aber auch seine Geheimhaltungspflichten nicht verletzen … Und was tun, wenn der gewünschte Datenzugriff gar für mehrere Personen (in begrenzter Anzahl) ermöglicht werden soll?

Oftmals reichen in einem Szenario mit Remote-Zugang rein lesende Zugriffe auf die zentral gelagerten Daten aus. Zu ändernde Inhalte synchronisiert man ggf. rollierend in einem speziellen organisatorischen Prozess über einen definierten administrativen User.

Ein anderes, einfacheres Szenario ist die sichere Lagerung von verschlüsselten Daten als Backup bei einem Cloud-Dienst. Da will ein beauftragter Admin bei Gelegenheit ggf. nur einige Files oder Verzeichnisse austauschen oder zum aktuellen Bestand hinzufügen – und nicht alle zu sichernden Daten komplett neu hinterlegen. Umgekehrt will er bei Bedarf nur bestimmte Versionen von einigen Dateien aus dem verschlüsselten Archiv zurückholen. Andere Benutzer haben zum Backup jedoch keinen Zugang.

Unter diesen Voraussetzungen beginnt man sich als Linux-Anwender dafür zu interessieren, ob und wie man verschlüsselte Container-Files auf einem Server nutzen und bei Bedarf auf einem Client sicher über das Internet öffnen oder mounten kann. Geht so was? Wenn ja, ist das auch hinreichend schnell?

Ich bespreche nachfolgend einen Ansatz, der auf einem gehosteten Linux-Server, Linux-Endgeräten und Veracrypt aufbaut. Ich gehe davon aus, dass die geheimzuhaltenden Daten auf dem gehosteten Server in einem Veracrypt-“Container” lagern. Ich setze den Umgang mit und Wissen über Veracrypt [VC] voraus. Unter https://www.veracrypt.fr/ en/ Documentation.html findet man u.a ein Tutorial.
Das grafische VC-Interface macht das Erstellen und Mounten von Container-Dateien zu einer relativ einfachen Übung.

Das jeweilige (mobile) Endgerät, das auf den gehosteten Server zugreifen soll, bezeichne ich nachfolgend schlicht als “Client”. Es geht in diesem Artikel primär um die sichere Lagerung der Daten auf dem Server; dennoch halte ich ein einem zweiten ergänzenden Artikel auch ein paar grundsätzliche Anmerkungen zur Sicherheit der Daten auf den Clients für angebracht.

Einschränkung:
Ich behaupte und impliziere mit diesem Artikel keineswegs, dass die Nutzung von verschlüsselten Containern eine Maßnahme ist, die für sich schon Datenschutzvorschriften und Gesetzen, die die Geheimhaltung von Daten regeln, genügen würde. Das nachfolgende Diskutierte kann höchstens ein mögliches Element in einer ganzen Kette von Sicherheitsmaßnahmen sein. Genaueres muss man in jedem Fall mit seinem Datenschutzbeauftragten und auch Anwälten klären.

Verschlüsselung

Die dauerhafte Lagerung der Daten soll bei einem Provider oder Cloud-Dienst erfolgen. Aus der Einschränkung, dass Fremde und das Personal beim Provider die Daten in keinem Fall einsehen dürfen, ergibt sich:

Die geheimzuhaltenden Daten dürfen nur auf dem eigenen Endgerät bzw. den Endgeräten der eigenen Mitarbeiter in eine unverschlüsselte Form gebracht werden – und auch dort nur temporär.

Wesentlich ist einerseits also eine (hochwertige) Verschlüsselung auf allen relevanten Ebenen des Zugriffs und der Lagerung. Anderseits sind Vorkehrungen zu treffen, dass eine Entschlüsselung nur auf bestimmten Geräten abseits des Servers stattfindet:

  1. Anforderung 1: Ausschließlich verschlüsselte Ablage der Daten auf dem gehosteten Linux-Server. Das bedeutet aber auch: Auf dem Server dürfen keine unverschlüsselten Daten/Dateien/Dateifragmente im Speicher oder gar den Datenhaltungssystemen auftreten und verbleiben.
  2. Anforderung 2: Verschlüsselung des Transportwegs zum und vom Server.
  3. Anforderung 3: Entschlüsselung der Daten nur auf dem Client.
  4. Anforderung 4: Verschlüsselung bearbeiteter Dateien auf dem Client vor dem Rücktransfer zum Server.

Ein paar ergänzende Hinweise sind aus meiner Sicht angebracht:

Hinweis 1:

Da ein Betriebssystem, Linux-Desktop-Systeme und nicht zuletzt Anwendungen Daten in allen möglichen Verzeichnissen puffern und/oder im Hinhtergrund Sicherungskopien erstellen, bedeuten die Anforderungen 1 und 3, dass wir das Container-File nie (!) auf dem Server mounten und dort auch nie auf dessen Inhalte zugreifen dürfen. Würde man das tun, stünden die geheimzuhaltenden Daten dort ja irgendwo unkontrolliert im Klartext bereit. Besonders kritisch sind in diesem Zusammenhang übrigens SSDs mit Wear Leveling zu sehen (s. den kommenden 2-ten Artikel dieser Miniserie). Heute sind solche SSDs aber fast immer Teil von Hosting-Angeboten. Also:

Ein Szenario, bei dem Anwender über das Internet auf einen auf dem Server gemounteten und entschlüsselten VC-Container zugreifen, der für externe Nutzung (z.B. über NFS) freigegeben wurde, verbietet sich in unserem Szenario von vornherein.

Das ist eine ziemlich massive Einschränkung! Klassische VPN-Ansätze sind somit ohne weitere Maßnahmen unzureichend. Und auch der “Multiuser”-Zugriff auf per NFS bereitgestellte Containerinhalte fällt flach. Um erst gar nicht in Versuchung zu kommen, installiert man das Tool Veracrypt auf dem Server am besten überhaupt nicht. (Es wird dort auch nicht benötigt.)

Hinweis 2:

Die meisten Hosting-/Cloud-Angebote bzgl. Speicherplatz – u.a. auch Stratos HiDrive – verschlüsseln zwar den Transportweg, erfüllen aber nicht die Bedingung einer verschlüsselten Lagerung der Dateien im technisch meist unspezifizierten “Cloud”-Speicher. Tatsächlich empfiehlt z.B. Strato für die sichere Lagerung von Daten eine “Synchronisation” – genauer ein Up- und Downloaden – von verschlüsselten Containerdateien.

Obwohl nicht primäres Thema dieses Artikels wollen wir bereits erste Bedingungen bzgl. der Sicherheit der Daten auf dem Client formulieren. Schließlich will man Dateien, die man aus dem Server-Archiv kopiert hat, ja auch auf seinem eigenen Endgerät vor der Einsichtname durch Fremde schützen – z.B. für den Fall eines Verlusts des Laptops/Notebooks. Eine vollständige Sicherheitskette muss deshalb u.a. auch folgenden Anforderungen gerecht werden:

  • Anforderung C1: Haltung/Lagerung von Dateien, die aus dem zentralen VC-Container auf den Client (Notebook/Laptop) kopiert wurden, nur in verschlüsselter Form.
  • Anforderung C2: Vermeidung der Ablage von Dateien/Dateifragmenten, die durch das Öffnen von Dateien aus dem Container auf dem Client in unverschlüsselter Form entstehen und ggf. an verschiedenen Stellen des Verzeichnisbaums gespeichert werden.

Hinweis 3:
Vielen Anwendern ist nicht klar, dass die eigentliche Herausforderung bzgl. einer durchgehenden Datensicherheit in der Anforderung C2 besteht. Siehe hierzu die Anmerkungen und Hinweise im zweiten Artikel dieser Serie.

Einsatz von verschlüsselten Veracrypt-Containern

Würde man nur lokal arbeiten, könnte man zur Erfüllung der Anforderungen 1 und 3 auf Tools zur Erstellung verschlüsselter Container-Dateien zurückgreifen, die dann (als Loop-Device) im Dateisystem des Clients unter gleichzeitiger Dekryptierung gemounted werden. Entsprechende Anwendungen erledigen die Ver- und Entschlüsselung quasi “en passant”.

In Frage kommen hierfür unter Linux etwa LUKS, aber eben auch Veracrypt. Letzteres betrachten viele als verbesserten Nachfolger von Truecrypt.

Der Hauptentwickler von Veracrypt ist übrigens Franzose. Vive la France! Die Entwickler haben VC mit Hilfe von Sponsoren im Jahr 2016 einem Sicherheitsaudit unterziehen lassen. Das weckt Vertrauen. [Der Vollständigkeit halber sei darauf hingewiesen, dass meines Wissens aber noch nicht alle Mängel aus dem Sicherheitsaudit von 2016 behoben sind – sehr wohl aber die wichtigsten (s. die entsprechenden Links am Ende des Artikels)]. Für uns relevant ist hier aber folgende Aussage der Entwickler:

Note that VeraCrypt never saves any decrypted data to a disk – it only stores them temporarily in RAM (memory). Even when the volume is mounted, data stored in the volume is still encrypted.

Zitiert nach “https://www.veracrypt.fr/ en/ Beginner%27s%20 Tutorial.html“. (Hervorhebung von mir.)

So wie das geschrieben ist, sollte das also auch gelten, wenn das Verzeichnis, auf dem die Veracrypt-Container-Datei liegt, mit einem geeignetem Tool auf einem Remote-System gemounted wird. Der Container auf dem Server enthält und erhält auch dann nur kryptierte Daten.

1-User-Szenario mit Veracrypt

Wir betrachten zunächst ein 1-User-Szenario. Der User habe auf dem Server den Usernamen “smy” und auf dem Client “myself“.

Ich gehe davon aus, dass der Anwender mit Hilfe von Veracrypt bereits ein verschlüsseltes Container-File angelegt und dieses über SFTP oder SCP auf dem gehosteten Server hinterlegt hat. (Der Anwender hat es dort aber wegen der oben angeführten Gründe nie geöffnet!)

Das
Container-File selbst sei auf dem Server als Datei “/mydirs/conts/vc_cont_srv” gespeichert, also im Verzeichnis “/mydirs/conts”.

Weiter gehe ich davon aus, dass der Anwender auch lokal (auf dem Client) einen verschlüsselten Veracrypt-Container angelegt hat, um dort Dateien (evtl. Datei-Kopien vom Server-Container) verschlüsselt abzulegen. Der lokale Veracrypt-Container sei in Form der Datei “/home/myself/mycont/vc_cont_cli” gespeichert.

Auf dem Client seien mehrere Mount-Punkte für Remote-Verzeichnisse und VC-Container vorgesehen.

Mount-Punkte auf dem Client:

  • “/home/myself/mnt_remote” für das Mounten eines beliebigen Remote-Verzeichnisses (hier etwa von “conts”).
  • “/home/myself/mnt_vc_srv” für das Mounten des Veracrypt-Containers vom Server (“vc_cont_srv”).
  • “/home/myself/mnt_vc_cli” für das Mounten des lokalen Veracrypt-Containers (“vc_cont_cli”).

Zielsetzung: Zweistufiges Mounten statt Hin- und Herschieben kompletter Containerfiles

Wir möchten in unserem Szenario nicht größere Containerfiles vom Server zum Client kopieren, dort lokal mounten, damit arbeiten und danach wieder das geänderte Veracrypt-Containerfile vollständig auf den Server zurückschieben. Das ist unbequem und kostet bei großen Containern in Abhängigkeit von der Bandbreite der Internet-Anbindung des Clients natürlich Zeit – besonders beim Upload.

Unser Lösungsansatz besteht vielmehr darin, das Verzeichnis des Servers, das den VC-Container enthält, remote auf dem Client zu mounten. Anschließend hängen wir das Containerfile mit Hilfe von Veracrypt in den lokalen Verzeichnisbaum des Clients ein. In der obigen Skizze sind beide sukzessiven Schritte des Mountens angedeutet.

Die Dekryptierung und bei Änderungen auch die Kryptierung von Container-Inhalten (neue oder geänderte Files/Verzeichnisse) würde im Zuge eines solchen Verfahrens allein im RAM des Clients vor sich gehen.

Nun ist Mounten ein Prozess, bei dem nicht das gesamte Filesystem durchforstet werden muss, und der deshalb schnell ist. Unsere Hoffnung ist also, dass dies auch für das Mounten des VC-Containers aus einem remote gemounteten Verzeichnis gilt. Falls das so funktionieren würde, läge der wünschenswerte Unterschied gegenüber einem Hin- und Her-Kopieren des gesamten Container-Files vor allem darin, dass bei Zugriffen auf Container-Inhalte nur diejenigen (verschlüsselten) Datenbereiche über Inodes addressiert und transferiert würden, die am Client tatsächlich benötigt werden.

Zunächst (beim Mounten) vor allem Veracrypt-Header und Verzeichnisstrukturinformationen. Blöcke, die zu einzelnen Dateien gehören, welche anschließend dem Client mit lokalen Instrumenten wie Editoren geöffnet werden, müssten allerdings vollständig übertragen werden (soweit es sich nicht um streambare Dateien handelt) – aber eben nur die Blöcke der zu bearbeitenden Dateien. Und nicht der komplette Container. Ein vollständiger Datei-Transfer ist ggf. auch für Schritte zum (Zwischen-) Speichern geänderter Dateien zu erwarten (s.u.). Deshalb arbeiten wir auf dem Client evtl. effizienter mit Kopien (s.u.), die wir nach Abschluss der Arbeiten wieder in den gemounteten Container laden.

Einsatz von SSH für die Verschlüsselung des Transportweges

Um der Anforderung 2 nachzukommen, können wir unter Linux z.B. auf SSH (genauer: OpenSSH mit Key-Authentication) setzen. Ansonsten müssten wir uns mit einer aufwändigen Kerberos- und NFS4- Konfiguration herumschlagen,
um eine hinreichende Verschlüsselung zu erreichen. SSH bringt zugegebenermaßen Latenzprobleme mit sich – aber bei aDSL/vDSL-Verbindungen mit begrenzten Upload-Geschwindigkeiten ist das vermutlich nicht mal das primäre Problem, über das es sich nachzudenken lohnt.

Wie man SSH für eine schlüsselbasierte Authentifizierung konfiguriert, habe ich in diesem Blog schon mehrfach an anderer Stelle besprochen. Ich gehe daher davon aus, dass für den SSH-Zugang zum gehosteten Server auf dem Client ein (passwortgeschütztes) Keyfile etwa unter “~/.ssh/KEYFILE” bereitsteht.

Zu weiteren Maßnahmen für eine Absicherung der SSH-Verbindung gegenüber Angriffen siehe etwa https://stribika.github.io/ 2015/01/04/ secure-secure-shell.html. In Sinne des genannten Artikels hat man sich natürlich um aktuelle OpenSSH-Versionen zu kümmern. Vor allem aber sollte man die einzusetzenden asymmetrischen SSH-KEX-Algorithmen, symm. Verschlüsselungs- und Hash-Algorithmen auf noch als sicher geltende Verfahren einschränken!

Einsatz von SSHFS

SSH erlaubt zunächst nur eine verschlüsselte Verbindung. Wir wollen in unserem Szenario ja aber das Verzeichnis “conts” vom Server mounten. Dafür haben wir mehrere Möglichkeiten, u.a.

  • CIFS über einen SSH-Tunnel,
  • NFS3/4 über einen SSH-Tunnel.
  • NFS4 mit Kerberos
  • SSHFS.

Vermutlich ist NFS4 die performanteste und skalierbarste unter den genannten Alternativen. NFS4 erfordert jedoch Einiges an grundsätzlicher Konfigurationsarbeit – im Besonderen bzgl. der Benutzerberechtigungen. Hinzu kommt die Einrichtung der SSH-Tunnel. Will man SSH-bedingte Latenzprobleme vermeiden, führt kein Weg an NFS4 und Kerberos vorbei. Damit sind manche User evtl. überfordert.

Ich greife in diesem Artikel daher mal zu SSHFS; das kombiniert mir den Einsatz von FUSE bei gleichzeitiger Verschlüsselung der Verbindung: FUSE erlaubt es, Filesysteme auf einfache Weise im Userspace zu mounten. SSHFS erlaubt das Mounten von Remote-Verzeichnissen über FUSE und unter SSH. Dabei werden u.a. Fähigkeiten von SFTP genutzt. Letzteres ist bei OpenSSH dabei. Voraussetzung der Nutzung ist die Installation der Distributionspakete zu FUSE und SSHFS. Auf dem Server muss OpenSSH natürlich hinreichend eingerichtet sein. Der zugehörige Port muss in der Firewall geöffnet sein. Zugangsberechtigungen sollten auf User-, Gruppen-Ebene und Host-Ebene geregelt sein.

Es ist – wie bei SFTP auch – möglich, bestimmte SSHFS-Benutzer auf das Mounten definierter Verzeichnisse unterhalb eines CHROOT-Verzeichnis einzuschränken. Dafür nimmt man als Admin normale SFTP-Einstellungen für User- und Gruppen-Zugriffe auf ein definiertes CHROOT-Directory vor. Siehe hierzu etwa
https://wiki.archlinux.org/ index.php/SSHFS
https://wiki.archlinux.org/ index.php/ SCP_and_SFTP
SFTP mit Key-Authentication auf (gehosteten) Linux-Servern für Web-Entwickler mit unterschiedlichen Privilegien – II

Performance von SSHFS?

Man sollte sich bei Gelegenheit mit den Parametern von SSHFS zum Caching, zur Komprimierung etc. befassen. Das Schöne ist, dass man bei etwas Optimierung in einigen Anwendungsfällen sehr wohl an die Performance von NFS herankommt – mit Ausnahme von Random Read-Operationen (max. 60% der NFS-Performance ohne SSH-Tunnel). Siehe für Benchmark-Daten und Optimierungshinweise:

http://www.admin-magazine.com/ HPC/ Articles/ Sharing-Data-with-SSHFS
https://www.smork.info/ blog/ 2013/04/24/ entry130424-163842.html
http://www.linux-magazine.com/ Issues/ 2014/165/ SSHFS-MUX
http://homepages.warwick.ac.uk/ staff/ E.J.Brambley/ sshspeedtest.php
Kritik: http://julio.meroh.net/ 2016/02/ sshfs-performance-analysis-for-builds.html

Tip: Bei langsamen Leitungen sollte man unbedingt auch Performance-Vergleiche für Zugriffe mit oder ohne Kompression anstellen.

Mounten des Server-Verzeichnisses mit SSHFS

Ich gehe mal davon aus, dass auf dem Client (Laptop/Notebook/PC) zu einem bestimmten Zeitpunkt nur ein User – hier “myself” – arbeitet. Wie mounted der nun konkret ein Verzeichnis vom Server unter Beachtung des Key-Files mit SSHFS?

Der Server habe beispielsweise die Adresse “h1234567.stratoserver.net”. Der SSH-Zugang sei dort in der Firewall z.B. unter dem Port 57888 geöffnet. Der notwendige Befehl zum Mounten des oben angegebenen Remote-Verzeichnis wäre dann: 

myself@mytux:~> sshfs -p 57888 -o "IdentityFile=/home/myself/.ssh/KEYFILE"  smy@h1234567.stratoserver.net:/mydirs/conts/ ~/my_mnt -o idmap=user -o uid=$(id -u) -o gid=$(id -g) 
Enter passphrase for key '/home/myself/.ssh/KEYFILE':

 
Durch die Optionen “-o uid=$(id -u) -o gid=$(id -g)” wird eine Abbildung der UID und GID des lokalen Users “myself” auf den Remote-User “smy” und dessen Rechte geleistet! Das ist eine sicherheitsrelevanter Punkt, den man bei Konfigurationen für mehrere User im Auge haben muss.

Hinweis: Man kann die Optionen übrigens auch nur nach einem “-o”, dann aber kommasepariert angeben.

Man wird zur Eingabe des Passworts aufgefordert. Danach steht einem der Inhalt des gemounteten Verzeichnisses bereits zur Verfügung: 

myself@mytux:~> la my_mnt
insgesamt 573448
drwx------  1 myself users      4096 19. Aug 14:58 .
drwxr-xr-x 83 myself users      4096 20. Aug 15:38 ..
-rw-------  1 myself users 524288000 19. Aug 15:29 vc_cont_srv
myself@mytux:~>

Mounten des Veracrypt-Containers auf dem Client – Fehlermeldung ???

Funktioniert nun bereits der zweite Schritt, nämlich ein lokales Mounten des Containers “vc_cont_srv”, der uns auf dem Client ja nun unter “/home/myself/my_mnt/vc_cont_srv” zur Verfügung steht? Leider Nein!

Versucht man wie gewohnt, den Container mit Veracrypt auf das Zielverzeichnis “/home/myself/mnt_vc_srv” zu mounten, so erhält man eine Fehlermeldung der Art:

Keine Berechtigung:
/home/myself/my_mnt/vc_cont_srv

VeraCrypt::File::Open:232

Was ist die Ursache und wie kann man damit umgehen?

Rechteproblem beim lokalen Mounten eines Veracrypt-Containers aus einem SSHFS/Fuse-Verzeichnis heraus

Die Fehlermeldung deutet an, dass bereits der Zugriff auf das Containerfile selbst nicht klappt! Man könnte dabei auf ein Problem mit SSHFS-Rechten tippen; ggf. mit der UID und GID-Abbildung. Führt man aber einen Zugriff auf andere Dateien mit gleicher User-Berechtigung durch, so geht das einwandfrei! Also muss das Rechteproblem am Zusammenspiel von Veracrypt mit FUSE liegen. Ein wenig Recherche im Internet zeigt, dass Veracrypt den Mount-Prozess mit “root”-Rechten abwickelt. Nächste Frage: Darf “root” denn nicht auf die Inhalte des gemounteten FUSE-Filesystems zugreifen? Ein Versuch zeigt tatsächlich: 

mytux:~ # cd /home/myself/my_mnt
-bash: cd: /home/myself/my_mnt: Permission denied
mytux:~ # cd /home/myself/
mytux:/
home/myself #

Es handelt sich hier um eine (sehr sinnvolle) Sicherheitssperre unter FUSE! Die ist vor allem auf Multiuser-Systemen wichtig! Interessanterweise kommen dabei andere und mehr Gründe als nur die Sorge um reine Zugangsberechtigungen ins Spiel. Siehe hierzu: https://www.kernel.org/ doc/ Documentation/ filesystems/ fuse.txt

Kann man diese Sperre für unsere Situation umgehen? Antwort: Ja, wenn das von “root” auf dem Client erlaubt wird oder wurde! Es geht dabei um eine grundlegende FUSE-Sicherheits-Einstellung, die man in der dortigen Datei “/etc/fuse.conf” vornehmen muss. Siehe hierzu:
http://man7.org/linux/man-pages/man8/mount.fuse.8.html
https://wiki.ubuntuusers.de/ FUSE/

Auf einem Client-System unter Debian sieht diese Datei etwa wie folgt aus: 

root@deb:~# cat /etc/fuse.conf 
# /etc/fuse.conf - Configuration file for Filesystem in Userspace (FUSE)

# Set the maximum number of FUSE mounts allowed to non-root users.
# The default is 1000.
#mount_max = 1000

# Allow non-root users to specify the allow_other or allow_root mount options.
#user_allow_other
root@deb:~#

In unserem Fall, in dem der User “myself” allein dem Laptop nutzt, finde ich es akzeptabel, die Option

user_allow_other

zu setzen – also das Kommentarzeichen “#” zu entfernen.

Hinweis:
In einigen Linux-Distributionen (Opensuse Leap, Ubuntu) ist die Konfigurationsdatei “/etc/fuse.conf” aber nicht mal vorhanden. Macht nichts: Man kann sie einfach anlegen; sie wird dann ausgelesen.

Unser User “myself” hat nach dieser grundlegenden Systemänderung dann zwei Optionen, zwischen denen er unter SSHFS wählen kann: “allow_root” und “allow_other”. Für unsere Zwecke genügt “allow_root”. Wir müssen unseren SSHFS-Befehl noch wie folgt anpassen: 

myself@mytux:~> sshfs -p 57888 -o "IdentityFile=/home/myself/.ssh/KEYFILE"  smy@h1234567.stratoserver.net:/private-backup/private-backups/conts/ ~/my_mnt -o idmap=user -o uid=$(id -u) -o gid=$(id -g) -o allow_root   
Enter passphrase for key '/home/myself/.ssh/KEYFILE':

 
Die erforderlichen Kommandos wird man als Admin des Clients natürlich in adäquater Weise in Scripts einbauen, die man dem User bereitstellt.

Jedenfalls klappt es danach auch mit Veracrypt: Der User “myself” kann das File endlich in seinen Verzeichnisbaum einhängen. Hat man im Veracrypt-Dialog den Slot 4 gewählt und den vorgesehenen Mount-Point “/home/myself/mnt_vc_srv” explizit unter “Options” eingetragen, so sieht das Ergebnis wie folgt aus: 

myself@mytux:~> mount
smy@h1234567.stratoserver.net:/mydirs/conts/ on /home/myself/my_mnt type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1029,group_id=100,allow_other)
veracrypt on /tmp/.veracrypt_aux_mnt1 type fuse.veracrypt (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
/dev/mapper/veracrypt4 on /home/myself/mnt_vc_srv type ext4 (rw,relatime,data=ordered)

 
In meinem Testfall kontrolliere ich noch, ob der Inhalt des Containers auch angezeigt wird: 

myself@mytux:~> la ~/mnt_vc_srv
insgesamt 76127
drwxr-xr-x  3 myself  users     1024 19. Aug 16:14 .
drwxr-xr-x 83 myself  users     4096 20. Aug 15:50 ..
-rwxrwxrwx  1 myself  users 19580917 18. Nov 2011  ajax.pdf
-rw-r--r--  1 root root   3544281  6. Jan 2017  blktrace_sdb6_kernel44.zip
drwx------  2 root 
root     12288 19. Aug 15:29 lost+found
-rw-r--r--  1 myself  users 31498557  4. Jan 2017  Reiher-848x480-13064.mp4
-rw-r--r--  1 myself  users  1159382  4. Jan 2017  Reiher-848x480-600kb.mp4
-rw-r--r--  1 root root   9963112  6. Jan 2017  sdb6.blktrace.0
-rw-r--r--  1 root root   5791834  6. Jan 2017  sdb6.blktrace.1
-rw-r--r--  1 root root   3864342  6. Jan 2017  sdb6.blktrace.2
-rw-------  1 root root   2529586  6. Jan 2017  sdb6.blktrace.3
myself@mytux:~>

 
Das sind offenbar keine besonders gheimnisvollen Daten. Ist ja nur ein Test. Man sieht, dass auch der User “root” hier mal was abgelegt hat. Obwohl ich (“myself”) gemountet habe, werden die Zugriffsrechte aber natürlich nicht umgangen: 

myself@mytux:~> cat mnt_vc_srv/sdb6.blktrace.3
cat: mnt_vc_srv/sdb6.blktrace.3: Keine Berechtigung
myself@mytux:~>

Man kann nun auf dem Verzeichnis unter “/home/myself/mnt_vc_srv” nach Bedarf arbeiten. Z.B. Libreoffice-Dateien anlegen und bearbeiten.

Wie lange dauert das Mount des VC-Containers?

Das Mounten des Verzeichnisses “conts” mit SSHFS geht sehr schnell von statten. Das anschließende Mounten
eines 1GB großen Containers, der mit 500 MByte an Dateien in einem recht verzweigten Baum gefüllt war, dauerte bei Tests mit einer aDSL-Verbindung [16MBit/s] nur zwischen ca. 4 und 5 Sekunden.

Das ist akzeptabel. Es ist offensichtlich, dass hierfür (wie erwartet) nicht das gesamte Container-File transportiert wird. VC genügt offenbar der Zugriff auf Header Informationen aus dem File und den Filesysteminformationen für das Loop-Device.

Arbeiten mit größeren Files – z.B. unter LibreOffice Writer

Ich habe testweise mal ein 2,4 MByte großes odt-File unter LO-Writer editiert und zwischendrin immer wieder abgespeichert. Da sieht es dann so aus, dass das gesamte File zur Ablage über das Netz transferiert wird. Reguläres Speichern im Hintergrund gibt es unter LO ja leider nach wie vor nicht …

Das ist bei einer langsamen Verbindung natürlich nicht prickelnd – LO Writer ist während des Speicherns bei einer ADSL-Uploadgeschwindigkeit von 2.4MBit zw. ca. 7 – 8 Sek. nicht benutzbar.

Das Speichern von Wiederherstellungsinformation passiert dagegen ja lokal am Client und geht schnell. Aber reguläres Speichern eben nicht. Dafür benötigt man eine hinreichend schnelle Verbindung.

Alternativ arbeitet man jedoch am besten mit einer lokalen Kopie der Datei und lädt die dann “hoch”, indem man sie in das gemountete Verzeichnis unter dem Vercrypt-Mountpunkt /home/myself/mnt_vc_srv” des Servercontainers kopiert. Immerhin muss man so nur einzelne Dateien kopieren und nicht den ganzen Container!

Unmount?

Hat man seine Arbeiten beendet, so muss man zwei Unmounts in folgender Reihenfolge vornehmen:

  1. Unmounten des Veracrypt-Containers vom Verzeichnis “/home/myself/mnt_vc_srv”. Dies macht man am besten über das VC-Interface.
  2. Unmounten des SSHFS Remote-Verzeichnisses vom Verzeichnis “/home/myself/my_mnt”

Für Letzteres ist der Befehl “fusermount -u” heranzuziehen:

myself@mytux:~> fusermount -u my_mnt

Weiter oben hatte ich ja auf Parameter von SSHFS für eine Optimierung (Cahcing etc.) hingewiesen. Das Caching sorgt bei viel RAM auf dem Client in vielen Situationen übrigens für einen falschen Eindruck beim Dateitransfer. Kopiert man etwa mittels eines Dateimanagers wie Dolphin größere Dateien in Richtung Server, so signalisieren Dolphin bzw. KDE einem ein sehr schnelles Ende des Transfers; das findet aber nur im lokalen Puffer statt. Der echte Transfer über Netz hat dann bei langsamen Upload-Verbindungen gerade erst begonnen.

Man sollte bei größeren Dateitransfers also den
ausgehenden Netzverkehr im Auge haben, bevor man mit dem Unmounten beginnt. Oftmals ist noch nicht alles zum Server transferiert worden, was da hin muss.

Verbindungsabbruch und Folgen

Was ich im Vorfeld dieses Artikels nicht getestet habe, sind Folgen einer Verbindungsunterbrechung. Dennoch kann man dazu was sagen. Ein Verbindungsabbruch hat potentiell Konsequenzen für die Konsistenz des Container-Files, aber auch des umgebenden Filesystems auf dem Server. Probleme mit letzterem sind mit Hilfe von “fsck” auf dem Server relativ einfach zu beheben. Zumindest, wenn man das Verzeichnis auf dem Server mit einem eigenen Filesystem unterlegt hatte – wozu ich ausdrücklich rate, falls dies denn im Rahmen des Hosting-Paketes möglich ist!

Schwieriger sieht es mit der internen Konsistenz des Container-Files selbst aus. Hier muss man auf dem Client (!) eine Dekryptierung ohne Mounten vornehmen. Danach kann man dann fsck auf das dekryptierte Filesystem anwenden. Informationen, wie man das mit Truecrypt zu machen hatte, findet man hier. Angeblich gelten die Anweisungen auch für Veracrypt in analoger Weise.

http://john.wesorick.com/2012/03/running-fsck-on-truecrypt-volume.html
Siehe auch:
https://serverfault.com/ questions/ 83601/ how-to-fsck-ext3-a-truecrypt-volume
http://sebsauvage.net/ links/ ?GsfKdw

Das dauert je nach Größe des Container-Files natürlich unangenehm lange, da dabei über Netz gearbeitet werden muss. Regelmäßige Backups des Vercrypt-Containers sind in unserem Szenario nicht nur aus diesem Grunde Pflicht. Darauf weise ich ausdrücklich hin.

Größeren Schäden vorbeugen kann man auch durch reine Read-Only-Mounts. Und falls Schreiben/Änderungen an Container-Inhalten absolut erforderlich sind: Arbeiten auf Datei- oder Verzeichnis-Kopien und nur kurzzeitiges RW-Mounten zum Upload der geänderten Datei.

Gleichzeitiger Zugriff mehrer Personen? Einsatz für Firmen?

Wie sieht es nun mit Szenarien aus, bei denen mehrere User zugreifen müssen? Hierzu sind mehrere Punkte anzuführen:

Skalierung: Ich habe das nicht getestet – aber vermutlich gilt: SSHFS skaliert nicht so gut wie NFS. Ab einer durch Tests zu bestimmenden Useranzahl lohnt sich vermutlich der Umstieg auf NFS.

Read Only: Auch unter NFS können nicht mehrere User unabhängig voneinander einen VC-Container bei sich lokal zum Lesen und Schreiben auf dem jeweiligen Client mounten. Das führt unweigerlich in die Katastrophe! Die Konsistenz des VC-Containers kann am Server unter diesen Bedingungen nicht aufrechterhalten werden!

Die Vercrypt-Entwickler haben zu diesem Thema eine entsprechende Empfehlung abgegeben, die schon für Truecrypt-Container galt:

  • Für schreibende Zugriffe durch mehrere Personene muss der Container bereits am Server gemounted und dann einem Sharing-Verfahren (z.B. über NFS oder SSHFS) unterworfen werden.
  • Ansonsten darf der Container nur dann auf mehreren Endgeräten gleichzeitig gemounted werden, wenn dies ausschließlich lesend erfolgt. Dies bedeutet im Klartext, dass bereits das umgebende Verzeichnis (hier: ) nur ReadOnly gemounted wird.

Siehe: https://www.veracrypt.fr/ en/ Sharing%20over%20Network.html

Die erste Variante fällt für unseren gehosteten Server – wie oben begründet – flach. Das bedeutet:

Multiuser-Szenarien auf gehosteten Servern sind nur im rein lesenden Modus möglich, nicht aber für Schreibzugriffe.

r

Würde man den Container andererseits indirekt über einen eigenen Server in der Firma mounten und dort freigeben, stellt sich die Frage, warum man nicht gleich über diesen Server arbeitet.

Ausweg bzgl. notwendiger Änderungen:
Leider nur in Kombination mit organisatorischen Maßnahmen. So könnten Mitarbeiter inhaltliche Änderungen lokal vornehmen und in GIT-/SVN-Repositories einchecken, die spätestens beim nächsten Aufenthalt in der Firma abgeglichen werden. Das Ergebnis des Abgleichs wird dann wieder für alle sichtbar in eine Containerdatei ausgespielt, die auf den Clients der mobilen Mitarbeiter nur lesend gemounted werden darf und kann.

Ich finde, das ist für viele Anwendungsfälle keine massive Einschränkung.

Ein Mehrbenutzerszenario, bei dem User auf dem Server grundsätzlich nicht nur lesende Operationen durchführen dürfen, ist von Haus mit sekundären Sicherheits-Problemen verbunden. Man muss etwa verhindern, dass die User geheimzuhaltende Daten eigenhändig und abseits des Containers auf den Server transferieren können. Alles andere als einfach …

Hochsicherheit am Server?

Man kann für manche Dateien, deren Inhalte (z.B. Passwörter) besondere Sicherheitsvorkehrungen erfordern, das Spielchen noch etwas weiter treiben:

Man erlaubt nur RO-Zugriffe – und hinterlegt diese Dateien innerhalb des VC-Containers nochmals verschlüsselt. Am besten mit GnuPGP – das gilt noch als sicheres Verfahren. Das PGP-File oder den PGP-Container kopiert und entschlüsselt man dann mit Tools wie Kleopatra oder KGpg auf dem Client.

Ein Angreifer, der es irgendwie schafft, den VC-Container oder den Datenverkehr vom/zum Client zu knacken, sieht sich dann immer noch mit dem PGP-File/Container konfrontiert. Wohlgemerkt: Das erhöht zwar die Sicherheit auf dem gehosteten Server. Aber es verschiebt die Sicherheitsthematik ganz genau wie die VC-Entschlüsselung auf den Client.

Weitere Schwachstellen?

Sind wir nun nach menschlichem Ermessen sicher? Nun ja, jedes System kann gehackt werden. Und sicher hat auch ein böswilliger Admin beim Provider die Möglichkeit dazu. Eine manupulierte Implementierung von SSH wäre in unserem Szenario z.B. ein Ansatzpunkt für einen Angriff. Ein Minimum an weiteren Vorsichtsmaßnahmen muss daher sein, dass wir Systempakete selbst installieren (soweit möglich) – und deren Integrität mit IDS-Tools überwachen. Für einzelne Komponenten wie SSH ggf. mit Tripwire.

Man kann die Integritätsbetrachtung aber natürlich beliebig ausdehnen – bis hin zum Host-Kernel, auf den man oft keinen Einfluss hat. Das führt zur Frage des Einsatzes von Root-Servern, die man absichern muss. Die Frage ist dann: Wann hat man gesetzlichen Vorgaben auf dem Stand der Technik Genüge getan?
Wir nähern uns erneut Domäne von Vorgaben durch Datenschutzbeauftragte und Anwälten. Und das sprengt diesen Artikel. Aber es macht erneut klar: Echte Sicherheit endet nicht bei der verschlüsselten Ablage von Daten.

Ausblick

Wir haben gesehen, dass es bei einer bzw. wenigen Personen durchaus möglich ist, Veracrypt-Container auf einem Server zu nutzen, ohne jemals eine Entschlüsselung auf dem Server selbst vornehmen zu müssen. Eine einfache Möglichkeit des Zugriffs ergibt sich dabei über SSHFS und eine anschließendes Mounten des VC-Containers auf dem Client.

Szenarien für Lese- und Schreibzugriffe mehrerer Anwender sind ohne Gefährdung der Sicherheit nicht möglich. Hier ist auf ReadOnly-Szenarien und organisatorische Maßnahmen auszuweichen.

Für Einzelanwender geht dagegen sogar Lesen und Schreiben. U.a. LibreOffice erfordert aber hohe Upload-Raten der Verbindung, da das Zwischenspeichern zum Transfer der gesamten geöffneten Datei führt.
Alternativ arbeitet man mit lokalen Kopien am Client. Ein Hin- und Her-Kopieren des gesamten Containers erscheint jedoch überflüssig. Bitte
korrigiert mich, wenn ich etwas übersehen haben sollte.

Im nächsten und letzten Artikel dieser Serie

Veracrypt, SSHFS und sichere Datenhaltung auf gehosteten Servern – II – die Client-Seite …

stelle ich einige Hinweise zur Sicherheit der Daten auf unserem Client zusammen. Denn es gilt: Wir handhaben dort entschlüsselte Daten und haben damit die Sicherheitsthematik auf das Endgerät des Benutzers verschoben.

Links

Veracrypt
https://en.wikipedia.org/ wiki/ VeraCrypt
http://www.deutschlandfunk.de/ verschluesselungssoftware-veracrypt-unabhaengige.684.de.html?dram:article_id=369309
https://www.computerbase.de/ 2016-10/ truecrypt-alternative-veracrypt-audit/
http://www.linux-magazine.com/ Online/ Features/ VeraCrypt

Audit Report zu Veracrypt
https://ostif.org/ wp-content/ uploads/ 2016/10/ VeraCrypt-Audit-Final-for-Public-Release.pdf
https://www.golem.de/ news/ truecrypt-nachfolger-veracrypt-audit-findet-schwerwiegende-sicherheitsluecken-1610-123893.html

LUKS
https://wiki.ubuntuusers.de/ LUKS/ Containerdatei/

SSH mit Key Files
https://www.digitalocean.com/ community/ tutorials/ how-to-configure-ssh-key-based-authentication-on-a-linux-server
https://stribika.github.io/ 2015/01/04/ secure-secure-shell.html
https://wiki.mozilla.org/ Security/ Guidelines/ OpenSSH

FUSE
https://de.wikipedia.org/ wiki/ Filesystem_in_Userspace

SSHFS
https://wiki.archlinux.de/ title/ Sshfs
https://wiki.archlinux.org/ index.php/ SSHFS
https://www.heise.de/ ct/ artikel/ Toolbox-Dateizugriffe-mit-sshfs-1646679.html
https://www.linode.com/ docs/ networking/ ssh/ using-sshfs-on-linux

SSHFS mit Identityfile
https://unix.stackexchange.com/ questions/ 61567/ sshfs-specify-key
https://stackoverflow.com/ questions/ 22393502/ how-do-i-specify-the-key-file-for-sshfs

Cloud-Definition
https://www.cloud.fraunhofer.de/ de/ faq/ publicprivatehybrid.html

Strato HiDrive
http://cloudlist.de/ dienst/ strato-hidrive-test/
https://strato.de/ blog/ 3-truecrypt-alternativen-fuer-
hidrive/

Opensuse Leap 42.2, Android, KDE, Dolphin – Dateitransfer mit MTP – Probleme und mögliche Ursachen

Posted on by

Vor einiger Zeit habe ich auf einigen Geräten ein Upgrade auf Leap 42.2 vorgenommen. Das lief alles ganz OK. Nun wollte ich von einem der betroffenen Laptops Dateien auf ein Smartphone übertragen. Dabei stolperte ich bei Einsatz von “MTP” und dem zugehörigen kio-Slave “kio_mtp” unter KDE in ähnliche Probleme, wie sie unter den folgenden Links beschrieben sind:

http://linux-club.de/forum/viewtopic.php?t=121313
https://forums.opensuse.org/showthread.php/526021-Erneute-Probleme-beim-Zugriff-auf-Android-Smartphone-via-MTP
https://forums.oneplus.net/threads/zugriff-auf-daten-ueber-computer.598702/

Ich weiß nicht, ob meine Problem die gleichen Ursachen hatten, wie bei meinen Leidensgenossen – aber die nachfolgenden Punkte sind jedenfalls der Beachtung wert.

Typischer fehlerhafter Verlauf beim Einsatz von “mtp” unter KDE

Fehler 1: Zugriff auf das erkannte Smartphone führt zu keiner Verzeichnisanzeige unter Dolphin

Man schließt das Smartphone an; es kommt zuerst eine Freigabeaufforderung auf dem Smartphone. Danach öffnet man Dolphin – und dann kommt da erneut eine Warnhinweis, dass man das Smartphone freigeben/entsperren müsse; tatsächlich erscheint am Phone eine neue Aufforderung. Die bestätigt man und schließt danach das Popup in Dolphin. Anschließend lädt und lädt Dolphin den Ordnerinhalt angeblich – es passiert aber weiter nichts und zur Anzeige der Speichermedien des Smartphones und deren Inhalte kommt es nie.

Fehler 2: Dolphin kann aus dem Gerätemanager heraus nicht gestartet werden

Ein weiterer ärgerlicher Punkt war in meinem Fall der, dass unter der Geräteüberwachung zwar Dolphin-Icons als Optionen für “Aktionen” angezeigt wurden; ein Klick darauf führte aber jedesmal zu einer Fehlermeldung, die man wegklicken muss. Dolphin öffnet sich dann aber nicht.

Ein solches Verhalten macht einen wahnsinnig; im besonderen, wenn man unter Zeitdruck steht und man weiß, dass früher alles schon mal funktioniert hat. In meinem Fall halfen mir “kde-connect” und die zugehörige App auf dem Smartphone aus der unmittelbaren Patsche heraus, weil beide Geräte (Laptop, Smartphone) sich zufällig im selben WLAN befanden. In unserer Firma gibt es aber Geräte, die aus Sicherheitsgründen in anderen WLAN-Netzen als die Smartphones hängen. Da hilft KDE-Connect nichts. Nun kann man auf SSH-/FTPS-Verbindungen ausweichen. MTP wäre aber doch so einfach … warum sollte das unter Leap nicht gehen?

Ein paar Experimente

Ich habe dann in meinem Ärger ein wenig rumexperimentiert. Als erster Schritt zur Analyse hilft in einem solchen Fall oft, das Ganze mal mit einem frisch angelegten User oder als User “root” auszuprobieren; Letzteres, um evtl. Rechteprobleme festzustellen.

In meinem Fall reichte schon der erste Schritt: Mit frisch angelegten UserIDs gab es kein größeres Problem mit MTP und einer USB-Kabelverbindung zu unseren verschiedenen Smartphones (LG 2, Samsung Note, Samsung 6). Da lief alles wie erwartet: Anschließen des USB-Kabels an die Linux Workstation, Dolphin öffnen, Android Phone wählen, auf dem Phone die angeforderte MTP-Verbindung freigeben, kurz warten, in Dolphin mit F5 die Ansicht aktualisieren und schließlich durch die Datenträger des Smartphones browsen und Dateien zwischen den Geräten hin und her kopieren.

Workaround

Das brachte mich zu einem ersten Workaround, den ich hier aufliste, weil er vielleicht beim einen oder anderen auch helfen mag. Auf die tatsächlichen
Ursachen der Fehler in meiner Konfiguration gehe ich weiter unten ein.

Man lösche – soweit vorhanden – die Dateien “~/.config/dolphinrc”, “~/.kde4/share/config/dolphinrc” und das Verzeichnis “~/.local/share/dolphin”. Danach funktionierte folgender Workaround relativ zuverlässig:

  • Schritt 1: Anschluss des Smartphone per USB-Kabel an das OS Leap 42.2-Gerät.
    • Schritt 2: I.d.R. kommt keine Freigabeaufforderung auf dem Handy – falls doch: bestätigen.
  • Schritt 3: Geräteüberwachung im Systemtray (Systembereich der Kontrollleiste) öffnen.
  • Schritt 4: Optionen für Android-Gerät anzeigen lassen und auf erstes Dolphin-Symbol klicken.
  • Schritt 5: Fehlermeldung wegklicken und ggf. auftauchende Freigabeaufforderung auf dem Handy positiv beantworten.
  • Schritt 6: Erneut Geräteüberwachung öffnen.
  • Schritt 7: Diesmal auf das 2-te Dolphin-Symbol klicken.
  • Schritt 8: Erneut Fehlermeldung wegdrücken und ggf. Freigabeaufforderung auf dem Handy bestätigen.
  • Schritt 9: Dolphin unabhängig auf dem Desktop öffnen => dort das unter “Geräte” angezeigte > Android-Phone anklicken.
  • Schritt 10: Es werden die auf dem Smartphone verfügbaren Speicherbereiche (Standard “Phone” und (SD-) “Card” angezeigt.

Bei mir tauchte entweder bei Schritt 5 oder bei Schritt 6 eine Freigabeaufforderung auf. Nicht aber zweimal. Die oben beschriebene Schrittfolge ist die einzige, die bei mir zuverlässige Ergebnisse vor den weiter unten geschilderten Maßnahmen produzierte. Der Workaround beseitigte jedoch nicht das Problem des Fehlers beim Klick auf die Dolphin-Symbole in der Geräteüberwachung.

Dieser Zustand ist aus meiner Sicht absurd. Offenbar funktioniert die MTP-Verbindung im Prinzip – aber irgendetwas in der initialen Dialogführung zwischen kio_mtp, Dolphin und dem Android-Phone stimmte einfach nicht.

Lösung 1: Amarok’s MTP-Modul muss abgeschaltet werden!

Ich stelle auf einigen meienr Geräten entweder Amarok und Clementine beim KDE-Start zur Verfügung. Sowohl auf dem Laptop als auch auf der Workstation waren nach dem Start von KDE Amarok aktiv. (Auf er Arbeitstation übrigens, weil ich mich gerade mal wieder mit Pulseaudiio herunmschlage. Dazu mehr in einem kommenden Beitrag.)

Es hat mich eine Weile gekostet herauszufinden, dass Amarok standardmäßig das Modul “MTP-Sammlung” aktiviert. Nun stammt Amarok aus KDE4-Zeiten. Das Modul ist offenbar nicht mehr mit der aktuellen KDE5-Umgebung kompatibel oder interferiert in unzulässigerweise mit über “udev” festgelegten Reaktionen auf MTP-Ereignisse.

Also unbedingt im Dialog “Amarok >> Einstellungen >> Amarok Einrichten >> Module” das Modul “MTP-Sammlung” deaktivieren !

Dass dieses Modul wirklich Ungutes tut, kann man dadurch ausprobieren, dass man bei aktiver MTP-Verbindung das Modul mal wieder aktiviert! Viel Glück …

Lösung 2: KDE-Einstellung unter Standardanwendungen überprüfen

Mein zweiter Fehler hatte damit zu tun, dass ich irgendwann mal “PCManFM” als Dateimanager installiert hatte. Der hatte sich dann selbst in den KDE-Einstellungen als primärer Manager für die Dateiverwaltung hinterlegt. Das funktioniert aber nicht mit der KDE-Geräteüberwachung. Also unter
“systemsettings5 >> Anwendungen >> Standardanwendungen >> Dateiverwaltung” Dolphin als Standard-Dateimanager festlegen.

Schließe ich nun eines unseres Android Smartphones an die Linux-Geräte an, auf denen das erlaubt ist, so funktioniert MTP wieder schnell und flüssig – egal ob an einem USB2.0 oder 3.0-
Anschluss.

Fazit

Plugins oder Module von Applikationen, die MTP-Ereignisse erkennen und auf die dahinter liegenden Geräte zugreifen wollen, kommen als potentielle Ursachen von Problemen mit MTP-Verbindungen unter KDE und Dolphin in Frage. Unter Opensuse Leap 42.2 gilt das auf jeden Fall für das MTP-Modul von Amarok. Es ist aber gut vorstellbar, dass auch andere Anwendungen ähnliche Probleme, wie oben diskutiert, zeitigen können. In Frage kommen vor allem Multimedia-Anwendungen. Der KDE-User sollte hierauf eine Auge haben und nach der Installation solcher Anwendungen Tests zu MTP-Verbindungen durchführen.

Viel Spaß weiterhin mit Dateitransfers zu Smartphones – macht das aber bitte nur auf Geräten, auf denen die impliziten Sicherheitsrisiken einer Smartphone-Anbindung kontrollierbar sind, und nur für User mit minimalen Rechten …

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

Posted on by

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