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

Das Thema der vorhergehenden Artikel dieser Serie

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

war eine allgemeine Diskussion darüber, warum man sich spätestens nach der DSGVO als Freelancer um Schutzmaßnahmen für E-Mails und um entsprechende vertragliche Vereinbarungen kümmern sollte. Eine reine Verschlüsselung von Transportwegen ist meiner Meinung nach nicht hinreichend; eine Lagerung von Mails in verschlüsselten Dateicontainern ist mit zu vielen Gefahrenpunkten verbunden. An einer Verschlüsselung von Volumes oder Partitionen der mail- und datei-verarbeitenden Systeme führt bei der Aufbewahrung von Mails und Anhängen kein Weg vorbei.

Als Freelancer steht man also womöglich vor der Aufgabe, sowohl den eigenen Mail-Server im LAN als auch Clients zur Mail- und Auftragsbearbeitung auf einen Unterbau aus verschlüsselte Partitionen umzustellen. Als Linuxer, die auf effiziente Ressourcennutzung bedacht sind, greifen wir zur Lösung auf virtualisierte Systeme zurück. Sprich: Meine Reaktion auf die von etlichen Kunden an mich gestellten pauschalen DSGVO-Anforderungen ist, die Auftragsverarbeitung für Kunden nur noch über besonders geschützte virtualisierte Systeme auf verschlüsselten Volumes durchzuführen. Der aufmerksame Leser hat sicher bemerkt, dass dieser Gedanke über die Mail-Verarbeitung hinaus weist.

Ich gehe kurz auf die Grenzen eines solchen Vorgehens ein; anschließend kümmern wir uns (endlich) um den Umzug eines bereits virtualisierten Mailservers auf eine verschlüsselte HD/SSD-Plattform.

Ist Volume- und Partitionsverschlüsselung einer Systeminstallation für Datensicherheit hinreichend?

Der Grundgedanke einer Partitions- oder Volume-Verschlüsselung ist: Nur verschlüsselte Daten sollen über verschiedene Zugriffsschichten Plattencontroller und Magnet- wie Flash-Speicher erreichen; eine vollständige Entschlüsselung von Dateien soll ausschließlich im RAM des Betriebssystems [OS] stattfinden. So schön das sein mag - es hilft nicht, wenn sich jemand bereits unbefugt auf dem System eingenistet hat und munter mitliest:

Die Verschlüsselung von Datenträgern, Partitionen oder Volumes bietet keinen Schutz auf gehackten Systemen. Sie bietet "nur" Schutz gegen unbefugten Zugriff im nicht-entschlüsseltem und/oder nicht-gemountetem Zustand der Volumes also z.B. im heruntergefahrenen Zustand des Systems.

Volume-Verschlüsselung ist also nur eine - wenn auch eine wichtige Maßnahme - zur Ausschaltung bestimmter Risiken. Auch das sollte aus meiner Sicht in einem Vertrag mit einem Auftraggeber festgehalten werden. Natürlich muss man sich u.a. auch um die Integrität der Virtualisierungshosts selbst kümmern - wir reden da aber über Systeme mit einer sehr begrenzten Anzahl an OS-Komponenten, die selbst keine direkte Verbindung zum Internet aufnehmen müssen.

Man erkennt, dass ein vernünftiger DSGVO-bezogener Vertrag zum Schutz personenbezogener und anderer geheim zu haltender Daten im Endeffekt wesentlich mehr beinhalten muss als nur Hinweise auf die Mailbehandlung und zugehörige Krypto-Verfahren für Transport und Lagerung. U.a. wird man eine Begrenzung ein- und aus-gehender Kommunikation von (virtualisierten) Servern und Clients, die bei der Auftragsbearbeitung eingesetzt werden, auf nur sehr wenige erlaubte Adressen im Internet umsetzen müssen. Z.B. gilt: Völlig offene HTTP(S)- / SMTP(S) - / IMAP(S)- oder gar UDP-basierte Kanäle nach außen zu beliebigen Zieladressen sind im Zeitalter von strafbewehrten DSGVO-Verträgen überhaupt keine gute Idee! Zumindest nicht auf denjenigen Server- und Client-Systemen, auf denen man mit geheim zu haltenden Informationen operiert.

Virtuelle KVM/QEMU-Systeme auf verschlüsselten Volumes

Will man aus anderen grundlegenden Risikoerwägungen heraus nicht gleich alle "Volumes" auf allen Systemen im Haus-/Firmen-Netz verschlüsseln, bleibt nur der Weg über virtuelle Maschinen. Das betrifft dann Server- wie Client-Systeme gleichermaßen.

Im Besonderen Linux-E-Mail-Server sind dabei recht komplexe Systeme; eine Neuinstallation der vielen Einzel-Komponenten auf verschlüsselten Platten/Partitionen mag man sich daher wirklich ersparen. Es geht somit um System-Migration. Nachfolgend betrachte ich deshalb den Umzug eines (virtuellen) (E-Mail-) Servers auf einem KVM/QEMU-Host von unverschlüsselten Partitionen/Volumes auf verschlüsselte Volumes.

Ich gebe einige wichtige Befehle am Beispiel eines KVM/QEMU-Hosts unter Opensuse an. Das ist insofern nützlich, weil man hierfür mit YaST allein nicht auskommt und auf die Kommandozeile runter muss. Für einen Umzug voll ausgestatteter virtueller Clients (KVM/QEMU-Linux-Gastsysteme) zur Mail- und Auftragsbearbeitung gelten die Ausführungen dann analog.

Übrigens: Durch voll-virtualisierte KVM/QEMU-Systeme (für Mailserver und Clients),

  • die netzwerktechnisch weitgehend abgeschottet sind,
  • über die kein freier Internetzugang mit Browsern erlaubt ist
  • und die auch nur spezielle Mail-Accounts bedienen

kann man auch Hackern das Eindringen ein wenig erschweren!

Umzug eines physikalischen Linux-E-Mail-Servers in eine Virtualisierungsumgebung?

Das erste Problem besteht für manchen Leidensgenossen ggf. darin, einen schon vorhandenen physikalischen Server in eine Virtualisierungsumgebung zu bringen. Ehrlich gesagt, habe ich das noch nie selbst gemacht - und leider auch keine Zeit, das mal testweise auszuprobieren. Server für spezielle Aufgaben sind in meinem begrenzten Netz schon seit langem aus guten Gründen virtualisiert 🙂 .

Ich verweise für diese Aufgabe unter Linux deshalb auf sog. "P2V-Tools" (physical to virtual) und entsprechende Literatur. Die ganz unten aufgeführten Links geben hierzu Hinweise und Anleitungen. Für die nachfolgenden Schritte setze ich voraus, dass es bereits einen unter KVM/QEMU virtualisierten Server gibt - allerdings auf unverschlüsselten Partitionen/Volumes.

Vorüberlegung A: Wie sieht es mit der Performance und der Flexibilität auf verschlüsselten Plattformen aus?

Kann man sich auf seinen Systemen eigentlich eine Verschlüsselungsschicht zusätzlich zur Virtualisierung leisten? Das ist eine gute Frage, die man pauschal schlecht beantworten kann. Unter Linux kommt meist eine Kombination aus dm-crypt und LUKS zum Einsatz. Für Systeme mit Prozessoren der letzten 5 Jahre sieht es dabei hinsichtlich der reinen Krypto-Performance recht gut aus. Bei Virtualisierungshosts im Heim-Bereich (also eher mit begrenzten Ressourcen) sind aber ein paar zusätzliche Punkte zu beachten:

Schichtung
Hat man als Plattenunterbau Raid-Systeme im Einsatz, so stellt sich etwa die Frage der Schichtung der verschiedenen Zugriffsverfahren. Aus meiner Sicht ist folgende Reihenfolge für virtualisierte Serversysteme sinnvoll:

  • Plattenpartitionen für Raid   >>  
  • Raid 10   >>  
  • LVM   >>  
  • Volumes für KVM-Host-OS   >>  
  • dm-crypt/Luks für ein LVM-Raw-Volume   >>  
  • KVM/QEMU- und Gastsystem mit Zugriff auf das Raw-Volume als virtuelle Platte   >>  
  • LVM /Volumes (oder Partitionen) im Gastsystem   >>  
  • ext4-Filesysteme im Gastsystem

Verschlüsselung vor Raid scheint mir aus naheliegenden Gründen wenig performance-optimierend zu sein. Bzgl. der Reihenfolge "LVM <> dm-crypt/Luks" kann man streiten. Für die eine oder andere Wahl ist aus meiner Sicht dabei nicht die Performance sondern die Flexibilität ausschlaggebend. Bei der von mir gewählten Vorgehensweise verschlüsseln wir LVM-Raw-Volumes und nicht die sie tragenden Platten-Partitionen. Das erlaubt den Einsatz unterschiedlicher Krypto-Algorithmen und individueller Passphrases für die zu verschlüsselnden Volumes. Ein Nachteil ist, dass Größenänderungen der Volumes und Filesysteme danach nicht im Online-Betrieb möglich sind. Das stört im semi-professionellen Umfeld aber weniger (s.u.).
Siehe auch:
https://superuser.com/questions/1193290/best-order-of-raid-lvm-and-luks

Einsatz von virtio-Treiber
Für optimale Performance setze ich auf dem KVM-Host für die Vermittlung des Zugriffs des KVM-Gast-Systems auf die als virtuelle HDs bereitgestellten Volumes den QEMU-eigenen "VirtIO"-Treiber ein. Das sieht im "virt-manager" dann etwa so aus:

Übernahme der Verschlüsselung durch den Virtualisierungs-Host!
Man erkennt an der oben angegebenen Schichtung, dass ich die Verschlüsselung vollkommen dem Virtualisierungs-Host überlasse. Das erscheint mir sinnvoll, da ihm normalerweise mehr CPU-Cores als dem Gastsystem zur Verfügung stehen.

Ich kann jedenfalls mit diesem Setup auf einem schon sehr betagten Host mit einem KVM-Gast-Mail-Server, der nur um die 10 Mails pro Minute verarbeiten muss, sehr gut leben. (Der Host beherbergt dabei noch mehr aktive virtualisierte Systeme!) Der Unterschied zur Situation ohne Verschlüsselung ist gefühlt klein. Soviel zum Mail-Server und Performance.

Vorüberlegung B: Verschlüsselung eines (LVM-) "Raw"-Devices? Verzicht auf "qcow2"?

Gem. der oben propagierten Schichtung möchte ich das Gastsystem für meinen E-Mail-Server offenbar auf einem "Raw-Volume" der LVM-Schicht betreiben - also direkt auf einem LVM-Volume, das vom Gast-System aus formatiert wurde, und nicht auf einem "qcow2"-Loopback-File eines übergeordneten Filesystems des Hosts. Was spricht gegen ein Vorgehen mit "qcow2"-Dateien auf einem KVM-Host für einen virtualisierten Server?

"qcow2"-Dateien - mit internem Filesystem für den Gast - sind zwar hochflexibel einsetzbar - der Zugriff des Gastes auf seine virtuelle Platte erfolgt dabei aber immer über die Filesystem-Schicht des KVM/QEMU-Hosts UND über die Filesystem-Schicht des KVM-Gastes; das kostet Performance!

Der entsprechende Overhead ist nicht unerheblich - vor allem dann nicht, wenn der Server ggf. von mehreren Clients gleichzeitig genutzt werden soll. Die QEMU-Leute haben deshalb schon immer vorgesorgt und erlauben den direkten Zugriff eines Gastes auch auf nicht gemountete Volumes oder Partitionen des Hosts.

Der zweite Grund entspringt ein wenig Sicherheitsüberlegungen.

Auf eine "qcow2"-Datei muss vom Gast-System über ein Mount-Verzeichnis des Host-Dateisystems aus zugegriffen werden. Die Datei liegt dann also bereits in einem unverschlüsselten Dateisystem, das auf einem Verzeichnis des Hosts gemountet ist, vor. Damit besteht aber auch - je nach Rechtesetzungen - die potentielle Gefahr, dass ihr Inhalt im laufenden Betrieb auch anderweitig ausgelesen werden kann (z.B. mit qemu-mount).

Die Situation ist im Fall von Raw-Devices komplexer. Das LVM-Volume wird nach einer Entsperrung des Verschlüsselungsverfahrens (s.u.) zwar wie eine Platte als Device unter "/dev/mapper" bereitgestellt. Aber dieses Device ist auch bei laufendem Gastsystem nicht direkt im Verzeichnisbaum des laufenden Host-Systems verankert. Ein evtl. durchgeführter Mountvorgang auf dem Host ist aber gar nicht so einfach zu verschleiern. Er wäre unnötig und würde bei entsprechender Protokollierung Alarmglocken auslösen.

Dennoch gilt:

Verschlüsselung von LVM-Volumes und Einsatz von qcow2 müssen bei hinreichenden Performance-Reserven kein Widerspruch sein.

Eine Schichtung

Raid 10   >>   LVM   >>   dm-crypt/Luks-Volume mit ext4   >>   Gemountetes LUKS/ext4-Volume mit qcow2-Datei auf dem KVM/QEMU-Host   >>   KVM/QEMU-Gast mit Zugriff auf qcow2-Loopback-Device   >>   LVM-Volumes des Gastsystems auf qcow2-Device   >>   ext4-Gast-Filesystem auf LVM-Volumes des Loop-Devices

funktioniert auf schnellen Hosts auch gut und bietet Verschlüsselung samt qcow2-Flexibilität. Ich nutze diese Variante u.a. auf Linux-Workstations für virtualisierte Clients.

Ich verfolge nachfolgend für unseren geplanten (Server-) Umzug aber die Variante ohne qcow2-Loopback-Device. Auch unser bisheriger virtualisierter (Mail-) Server mag bereits direkt auf einem unverschlüsselten Volume des Hosts verankert sein.

Vorüberlegung C: Größe des neuen kryptierten Raw-Volumes für den Umzug?

Wir können nun z.B. über den LVM-Volume-Manager von YaST oder über LVM-CLI-Kommandos (vgcreate, lvcreate) ein Raw-Volume kreieren, das nach seiner Verschlüsselung eine Kopie des alten Systems aufnehmen soll. Wie groß muss dieses logische Volume sein?

Naiverweise könnte man davon ausgehen, dass genau die Größe des alten Volumes (oder der alten Partition) in GiB hinreichend ist. Das wäre falsch. LUKS hinterlegt Informationen zum verschlüsselten Plattenplatz und zu 8 möglichen Passphrase-Keys in einem sog. "Verschlüsselungsheader". Dieser Header benötigt zusätzlichen Platz jenseits der verschlüsselten Nutzlast. Der Platzbedarf ist zwar nicht groß (ca. 2 MB) - aber er ist eben zu berücksichtigen. Man muss dem neuen Volume etwas mehr Platz als dem alten spendieren. Ich vergebe meist gleich 1 GB extra.

Verschlüsselung des Raw-Volumes

In unserem Beispiel heiße das neue logische LVM-Volume für das virtuelle Plattendevice des KVM-Gastes "lvimap_hd0" und sei Teil einer LVM-Volume-Group "volgrp4". Als Device erscheint dieses Volume dann unter "/dev/mapper" als "volgrp4-lvimap_hd0".

myserv:~ # la /dev/mapper 
...
lrwxrwxrwx  1 root root       8 Jun 10 09:40 volgrp4-lvimap_hd0 -> ../dm-14
...

Der zugehörige Link verweist im Beispiel dann ebenso wie "/dev/volgrp4/lvimap_hd0" auf "/dev/dm-14".

Wir setzen zur Kryptierung "dm-crypt" ein. "dm-crypt" nutzt LUKS über gut integrierte Module.

Die Aufgabe, ein (LVM-basiertes) "Raw-"-Device mit dmcrypt/LUKS zu verschlüsseln, lässt sich unter Opensuse Leap (42.2/42.3) entgegen jeder Erwartung mit YaST leider nicht erfolgreich durchführen. YaST wickelt die Anlage eines verschlüsselten Volumes nur dann korrekt ab, wenn das Filesystem bereits vorgegeben wird - also NICHT bei der Verschlüsselung für Raw-Devices innerhalb der Reihenfolge :

Partition   >>   LVM-Group   >>   Raw LVM-Volume   >>   dm-crypt/LUKS   >>   KVM-guest   >>   LVM im Gast   >>   Filesystem

Das ist bereits von anderen beklagt worden; siehe etwa:
https://forums.opensuse.org/showthread.php/528938-installation-with-LUKS-cryptsetup-installer-gives-error-code-3034

Man muss also auf der Kommandozeile arbeiten und das Kommando "cryptsetup" bemühen. Für unser Beispiel-Volume "lvimap_hd0" (erste virt. Platte des künftigen E-Mail-Servers) lautet ein mögliches Kommando zur Verschlüsselung dann:

myserv:~ # cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/volgrp4/lvimap_hd0

Für Details zu den verfügbaren Verschlüsselungs- und Hash-Verfahren werfe man einen Blick in die man-Seiten zum Kommando. Man muss die künftige Passphrase zweimal eingeben. Damit ist die Verschlüsselung aktiv. Ein anschließender Blick auf das Volume mit dem YaST-Partitioner zeigt entsprechend ein Verschlüsselungssymbol an.

Altes KVM-Gast-System mit "dd" kopieren oder mit "virt-manager" klonen?

Bzgl. des geplanten Umzugs unseres unter KVM/QEMU virtualisierten (Mail-) Servers auf das neue Krypto-Device stellt sich nun die Frage, wie wir das am besten bewerkstelligen:

Sollen wir "dd" einsetzen? Das ist zwar möglich, erfordert anschließend aber wegen kopierter UUIDs, MAC-Adressen etc. etliche manuelle Nacharbeiten im geklonten System und auf dem Host.

Besser ist deshalb aus meiner Sicht ein Cloning mit Hilfe von virt-manager! Dabei ist folgende Schrittfolge einzuhalten:

  • Schritt 1 : Öffnen des neuen dm-crypt-Devices unter einem verständlichen Namen
     
    myserv:~ # cryptsetup open /dev/mapper/volgrp4-lv_imap_hd0  cr_imap_encr

    Dabei muss natürlich die bereits gesetzte Passphrase für das Crypto-Device eingegeben werden. "cr_imap_encr" steht dann als ansprechbares Device unter "/dev/mapper/" bereit

  • Schritt 2 : virt-manager öffnen und in der Liste der Gäste mit der rechten Maustaste auf den zu klonenden Gast klicken. Dann die Option "Clone ..." wählen. Das führt uns dann zu einer Maske, die in etwa so aussieht und die zu klonende virtuelle Platte (vm2_hd1) des vorhandenen Gastes anbietet:
     

    Bzgl. der zu klonenden Disk öffnet man die Drop-Down Box und wählt "Details" :

  • Schritt 3 : In der sich neu öffnenden Maske trägt man den Pfad zum geöffneten "dm-crypt"-Decvice ein:
     

    Dann in der aktuellen Maske den "OK"-Button und anschließend in der Ausgangsmaske den Button "Clone" drücken.

Je nach Größe unseres virtuellen Servers und der Schnelligkeit der Plattensysteme wie des Prozessors dauert das etwas. Anschließend erhalten wir allerdings einen Clone, den man sofort booten kann. (Vorher den ursprünglichen Mail-Server natürlich runterfahren, um IP-Konflikte zu vermeiden. Das geklonte System hat immer noch die gleiche IP-Adresse wie das alte! )

Das war es im Wesentlichen schon. Wir haben erfolgreich ein virtualisiertes Server-System auf einen verschlüsselten LVM-Volume-Unterbau umgezogen!

Wie schließt man das verschlüsselte System manuell?

Unsere manuelle Vorgehensweise hat dazu geführt, dass das verschlüsselte Volume nicht in Systemdateien eingetragen wurde. Es steht daher nach einem Boot-Vorgang des Hosts nicht automatisch zu Verfügung. Auch das Passwort für die Entschlüsselung wird im Bootvorgang nicht automatsich abgefragt.

Ein aktivierter "libvirtd"-Service kann daher nach seinem Start im Zuge eines Bootens des Hosts auch nicht auf das Volume für den umgezogenen Gast zugreifen. Ein automatisches Hochfahren des Gastes über libvirt-Einstellungen ist somit ebenfalls nicht möglich. Das sind Probleme, um die wir uns in nachfolgenden Artikeln kümmern müssen.

An dieser Stelle möchte ich aber wenigstens den notwendigen manuellen Befehl für das Schließen des Crypto-Devices im Zuge eines Herunterfahrens angeben:

  • Schritt 1 - Herunterfahren des Gastsystems: Dies geschieht entweder über Standard-Befehle im Gast selbst oder z.B über virt-manager.
  • Schritt 2 - Schließen des Crypto-Devices :
     
    myserv:~ # cryptsetup close cr_imap_encr

Ausblick

In folgenden Artikeln möchte ich im Nachgang zu unserem "Umzug" ein wenig auf das Thema eingehen, wie man das Hochfahren des KVM-Hosts mit Gastsystemen auf verschlüsselten Volumes gestalten kann. Zudem wollen wir den "Verschlüsselungsheader" sichern und uns mit den Themen Backup und "fstrim" für SSDs als Basis der beschriebenen Schichtung befassen. Sinnvoll ist auch ein Blick auf (Mail-) Client-Systeme: Von irgendwo aus muss ja auch mal grafisch auf die virtualisierten Systeme zugegriffen werden. Dann werden z.B. Spice oder X2GO-Clients samt zugehörigen Protokollen zu einem Sicherheitsthema auf dem System, von dem aus wir auf virtualisierte Clients für die Auftragsbearbeitung zugreifen. Verschieben wir mit der Virtualisierung im Client-Umfeld also nur die Sicherheitsebene?

Links

P2V-Tools
http://manuel.kiessling.net/2013/03/19/converting-a-running-physical-machine-to-a-kvm-virtual-machine/
http://libguestfs.org/virt-p2v.1.html
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/v2v_guide/chap-v2v_guide-p2v_migration_converting_physical_machines_to_virtual_machines
http://events17.linuxfoundation.org/sites/events/files/slides/virt-v2v-rjones-backup-slides.pdf
http://qemu-buch.de/de/index.php?title=QEMU-KVM-Buch/_Speichermedien/_Physical-to-Virtualp2v_migration_converting_physical_machines_to_virtual_machines
https://access.redhat.com/articles/1351473

dm-crypt/Luks und die Reihenfolge von Zugriffsschichten
https://superuser.com/questions/1193290/best-order-of-raid-lvm-and-luks
https://blog.raptor2101.de/2009/09/23/verschlusselung-von-raids/
http://www.andreas-janssen.de/cryptodisk.html
http://linux-club.de/wiki/opensuse/Verschluesselung:_dm-crypt/luks_unter_openSUSE
https://wiki.archlinux.org/index.php/Dm-crypt/Specialties

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.

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

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.