Archiv der Kategorie: Administration

Teil 3: Virtualisierung mit Libvirt

In Teil 3 dieser Serie soll die Bibliothek Libvirt betrachtet werden.

Was ist überhaupt Libvirt

In Teil 2 habe ich über Xen gesprochen. Es dürfte deutlich geworden sein, dass Xen eine eigene Virtualisierungstechnologie ist. Dies ist bei Libvirt nicht der Fall. Libvirt ist lediglich eine Bibliothek, welche in der Lage ist, verschiedene Virtualisierer auszuführen. Libvirt unterstützt derzeit folgende Hypervisor:

In diesem Beitrag wird auf die Verwendung von KVM unter Libvirt eingegangen. Andere Technologien sollten aber unter ähnlichen Umständen administrierbar sein – genau das ist ja der Vorteil von Libvirt: man kann unterschiedliche Hypervisor in ein und derselben Oberfläche verwalten.

Für Libvirt gibt es zur Verwaltung verschiedene Frontends:

  • Die Virsh-Shell: diese ist fester Bestandteil von Libvirt und wird mit den entsprechenden Paketen direkt mitgeliefert.
  • Virtual Machine Manager (Virt-Manager): Ein grafisches Frontend zur Verwaltung der virtuellen Maschinen.
  • Ovirt: Web-Interface zur Verwaltung kompletter virtualisierter Umgebungen.

OVirt ist für größere Umgebungen gedacht, in denen virtuelle Maschinen auf verschiedenen Clusters laufen sollen und dort auch dynamisch verschoben, aktiviert, deaktiviert, etc. werden können. Für kleinere Umgebungen ist OVirt viel zu mächtig. Leider ist das Web-Interface auch nicht sinnvoll mit ScreenReadern zu verwenden. Das grafische Programm Virt-Manager lässt sich unter Linux mit dem Desktop Gnome und dem ScreenReader Orca durchaus verwenden. Die Virsh-Shell ist jedoch am einfachsten zu benutzen, da alle Funktionen als Befehle direkt eingegeben werden können.

Konfiguration und Einrichtung der virtuellen Maschinen

Die gesamte Konfiguration von Libvirt wird in XML-Dateien unterhalb von /etc/libvirt vorgenommen. Für kleinere schnelle Änderungen bietet sich daher das Editieren dieser Dateien direkt an. Für diese Aufgabe gibt es den Befehl virsh edit:

Virsh edit VM

Wobei VM der Name der virtuellen Maschine ist, die editiert werden soll.

Auch andere Einstellungen, wie die kompletten Netzwerkeinstellungen, storage- und Teile der Firewall-Konfigurationen können in XML-Dateien direkt in Libvirt hinterlegt werden. Der Vorteil an den XML-Konfigurationen ist, dass diese auch bei einer Migration von VMs mit auf das neue System übertragen werden können, bzw. auf dem neuen System eine gleiche Konfiguration einfacher garantiert werden kann. Ein weiterer Vorteil ist, dass nach dem Editieren der Konfiguration beim Beenden des Editors eine Überprüfung durchgeführt wird, eventuelle Tippfehler werden so direkt angezeigt.

Um neue virtuelle Maschinen zu erstellen, kann man entweder eine entsprechende XML-Datei unterhalb von /etc/libvirt/qemu ablegen, oder das Programm virt-install aus dem Paket virtinst bemühen. Der Vorteil des Programms virt-install ist, dass man mit Parametern und Optionen genau angeben kann, wie die virtuelle Maschine ausgestattet werden soll. Eine Befehlszeile kann beispielsweise so aussehen:

Virt-install –serial pty –hvm –virt-type kvm –w bridge=vmbr0,mac=52:00:00:12:34:35,model=virtio –k=de –os-type=Linux –disk vol=storage/vm.img,bus=virtio –c cdimage.iso –name vm –memory 2048

Mit dieser Befehlszeile wird eine virtuelle Maschine namens vm, 2 GB RAM, in dem Volume storage mit der Image-Datei vm.img erstellt. Die Netzwerkkarte wird der Bridge br0 hinzugefügt. In der Option –w wird daneben noch die MAC-Adresse und der Typ der Netzwerkkarte angegeben (hier Virtio). Auch in der Option –disk wird Virtio als Treiber festgelegt, um möglichst performant zu sein.

Wichtig: Die Option –serial erstellt uns das passende Interface, womit wir später auf die Console zugreifen können!

Die virtuelle Maschine wird von virt-install erstellt und bootet direkt von der angegebenen CD cdimage.iso. Hat man sich hier ein Linux-Installer erstellt, der entweder direkt über die serielle Console arbeitet, oder einen SSH-Server bootet, kann die Installation über diese Wege fortgesetzt werden. In der Manpage von virt-install wird erläutert, dass virt-install auch direkt einen Installer für die jeweilige Distribution direkt aus dem Internet nachladen kann (Option –l). Mit der Option –x lassen sich Boot-Parameter an den Kernel, der mit dem Installer geladen wird, mitgeben (so kann beispielsweise die Ausgabe an eine serielle Console gesendet werden). Wer mit virt-install arbeiten möchte, sollte vorher in die Manpage schauen. Die Optionen sind sehr vielfältig und bieten unterschiedliche Möglichkeiten eine VM einzurichten.

Zur Ergänzung der virt-Shell gibt es noch einige weitere Tools, welche in dem Debian-Paket libguestfs-tools enthalten sind (auch andere Distributionen haben dieses Paket dabei). So lässt sich beispielsweise mit virt-df die Festplattenbelegung von VMs auslesen, ohne direkt in die VM eingreifen zu müssen. Virt-Rescue startet ein kleines Rescue-System, in dem sich dann die virtuelle Maschine als Datenträger mounten lässt. Es lohnt sich, nach der Installation von libguestfs-tools zu schauen, welche Befehle mit virt- existieren.

Die Virt-Shell

Wie sich unschwer erraten lässt, ist die Virt-Shell eine Shell, in der libvirt verwaltet werden kann. Es werden nicht nur virtuelle Maschinen, sondern auch physische und virtuelle Netzwerke, Speicher-Pools, Volumen und Host-Systeme verwaltet. Durch die Vielzahl von Möglichkeiten kann durchaus das Gefühl entstehen, von der Virt-Shell erschlagen zu werden. Wer jedoch eine Zeit lang mit dieser Shell gearbeitet hat, wird schnell feststellen, welche Möglichkeiten sich durch diese Shell ergeben. Auch lassen sich einfache Aufgaben schneller erledigen, für die „Mausschupser“ eine deutlich längere Zeit brauchen würden.

Um in die Shell zu gelangen, ruft man auf der Linux-Console einfach den Befehl virsh ohne weitere Optionen auf. Beenden lässt sich diese Shell, in dem man quit eingibt.

Zur Verwaltung virtueller Maschinen stehen Befehle wie start, shutdown, resume, list, etc. bereit. Eine VM wird beispielsweise mit dem Befehl start vm_name gestartet, wobei VM_name der Name der virtuellen Maschine ist. Der Befehl list zeigt an, welche virtuellen Maschinen auf dem System vorhanden sind. Die Option –all zeigt auch diejenigen Maschinen an, die aktuell nicht laufen. Darüber hinaus lassen sich mit den befehlen pool-* und vol-* virtuelle Speicherpools und Volumes verwalten. Für ausführlichere Details zu den jeweiligen Befehlen sei an dieser Stelle auf die Manpage verwiesen. Direkte Hilfe gibt es durch den Befehl help. Ohne Parameter aufzurufen wird eine Übersicht aller zur Verfügung stehenden Befehle angezeigt. Help Befehl gibt nähere Informationen zu den jeweiligen Befehlen. So werden beispielsweise die wichtigsten Optionen und Parameter sowie optionale Parameter erklärt.

Wichtig zur Verwendung unter dem Aspekt der Barrierefreiheit ist der Befehl console:

Console VM_name

Startet eine serielle Console zu der VM VM_name. Mit STRG + 9 kann man diese Console auch wieder beenden.

Fazit

Da sich Libvirt vollständig über die Virt-Shell administrieren lässt, ist libvirt sehr gut für Blinde und Sehbehinderte Administratoren geeignet. Entsprechende SSH-Clients, die auch mit anderen Hilfstechnologien kompatibel sind, gibt es für alle Betriebssysteme – sogar für IOS. Oberflächen wie beispielsweise der Virt-Manager ermöglichen eine grafische Verwaltung von virtuellen Maschinen, ohne dabei Funktionen einzusparen bzw. andere Funktionen bereitzustellen, welche sich nicht auch über die Virt-Shell erledigen lassen.

Voraussetzung ist immer, dass innerhalb der jeweiligen virtuellen Maschinen eine serielle Console konfiguriert ist, damit alle Ausgaben über die Virsh-Console genutzt werden können.

Das Projekt OVirt ist noch recht jung, bietet aber bereits eine sehr große Vielzahl an Möglichkeiten. Da dieses Projekt auf RPM-Basierten Distributionen entwickelt wird, sind erhältliche Debian-Pakete in der Regel sehr veraltet. Die Weboberfläche ist leider mit aktuellen ScreenReadern derzeit nicht zugänglich. Daher wird OVirt hier nicht weiter untersucht – eine spätere Betrachtung lohnt sich aber sicherlich!

Die Virtualisierung Xen

Im zweiten Teil der Serie zur Zugänglichkeit von Virtualisierungslösungen betrachten wir nun den Hypervisor XEN.

Grundlegendes

Xen ist in der Regel in den meisten Paketquellen der jeweiligen Linux-Distribution enthalten und kann direkt installiert werden. Früher war ein spezieller Kernel erforderlich, damit Xen als sogenannte Dom0 betrieben werden konnte. In der Xen-Termologie wird der Hypervisor selbst (das System, auf dem die jeweiligen virtuellen Maschinen laufen) als Dom0 bezeichnet. Die Maschinen bezeichnet man dann als DomU. Die DomU-Unterstützung war bereits recht früh in den Linux-Kernel aufgenommen worden. Die Unterstützung von Dom0 wurde erst später (Kernel 2.6.X) fest eingebunden.

Steuerung mit XM

Gesteuert wird Xen über das Tool xm, welches fester Bestandteil von Xen ist. So lassen sich beispielsweise mit xm list alle existierenden VMs anzeigen. Die Konfiguration der jeweiligen virtuellen Maschinen werden in Konfigurationsdateien unterhalb von /etc/xen vorgenommen. Dort wird festgelegt, welchen Namen die VM hat, welches Netzwerk, welche CPU, usw. Diese Datei lässt sich ohne größere Probleme direkt mit einem Editor wie Vim oder Nano an die jeweiligen Wünsche anpassen. Interessant ist, dass Xen für die Installation verschiedener Linux-Distributionen sogenannte templates mitbringt. Dort wird festgelegt, welche Softwarekomponente man genau haben möchte und welche weiteren Voraussetzungen die VM erhalten soll. Dies alles lässt sich in verschiedenen Konfigurationsdateien festlegen. Mit einem Befehl lässt sich dann die gewünschte Distribution installieren, ohne dass über ein grafisches Interface eingegriffen werden muss. Freilich lassen sich so keine Windows-Systeme aufsetzen, da diese nicht über solche Mechanismen unter Xen verfügen.

Immer geht’s um die Console

Ist eine VM erst einmal installiert, lässt sie sich auch unter Xen über eine Console ansprechen. Mit dem Kommando xm console (VM-ID) lässt sich eine serielle Console zur jeweiligen VM öffnen. Damit lässt sich die komplette VM steuern, wenn diese all ihre Ausgaben auf die serielle Console umleitet.

Starten, stoppen, und andere Mechanismen lassen sich alle über das Tool xm realisieren.

Kurz um: wer sich mit dem Tool XM vertraut gemacht hat, kann ohne weiteres mit Xen barrierefrei virtuelle Maschinen administrieren, wenn diese nicht das Betriebssystem Windows beinhalten.

Zugänglichkeit verschiedener Virtualisierungstechnologien

Mit diesem Beitrag soll eine kleine Serie gestartet werden, in der die Zugänglichkeit verschiedener Virtualisierungstechnologien genauer beleuchtet werden soll.

Welche Systeme werden betrachtet?

Zunächst sollen Virtualisierungstechnologien, welche unter Linux laufen genauer betrachtet werden. Es geht hier im Schwerpunkt um unterschiedliche Frontends, womit die jeweiligen Technologien realisiert bzw. umgesetzt werden. Dabei werden ausschließlich Systeme betrachtet, welche im Serverbetrieb vorkommen und genutzt werden. Lösungen für den Desktop-Betrieb wie beispielsweise Gnome-Boxes oder Virtualbox werden nicht Bestandteil dieser Serie sein.

Folgende Systeme werden genauer angeschaut:

Wobei UCS auf Libvirt aufbaut und Libvirt verschiedene Technologien wie beispielsweise Xen und KVM (Kernel Based virtual Machine) verwalten kann.

Alle hier ausprobierten Technologien werden mit KVM benutzt, außer Xen. Xen ist eine eigene Technologie die mit KVM nicht vermischt werden kann.

Grundlagen

Es gibt zwei Wege, über die man den Bildschirm der eigentlichen virtuelle Maschine betrachten kann: Über VNC und über eine Console. In neueren Frontends wie beispielsweise Proxmox wird hauptzächlich VNC für den Zugriff auf die VMs verwendet.

Was ist VNC?

VNC (Virtual Network Computing) ist eine Technik, mit der der Bildschirminhalt eines Computers über ein Netzwerk übertragen werden kann. Hierbei wird nicht nur der Bildschirm, sondern auch die Tastatur und Mauseingaben übertragen.

Für Virtualisierungs-Systeme ist VNC also eigentlich genau das richtige: Man kann den zu virtualisierenden Computer genau so steuern, als würde man unmittelbar vor dem Computer sitzen.

Für eine barrierefreie Nutzung ist aber VNC denkbar ungeeignet! Es wird kein Sound übertragen und ein ScreenReader kann auch nicht eingesetzt werden, weil die Accessibility-Informationen, die ein ScreenReader braucht, nicht übertragen werden. Technisch überträgt VNC das Bild ausschließlich grafisch. Eine Anreicherung mit zusetzlichen Informationen wie dem Accessibility-Informationen findet nicht statt.

Somit fällt VNC als Zugriffsmöglichkeit auf virtuelle Maschinen für all diejenigen, die unterschiedliche Hilfstechnologien wie Spracheingabe, ScreenReader, usw. verwenden leider weg.

Die Lösung: Text muss her

Wenn es mit einer grafischen Übertragung nicht klapt, brauchen wir eine Möglichkeit, alle Informationen auf Text-Ebene zu übertragen! Die Lösung: Eine Console!

Jeder, der sich intensiver mit Linux beschäftigt hat, kennt die Textconsole. In einer Textconsole werden alle Informationen, wie der Name schon sagt, In Textform ausgegeben.

Also genau das, was wir brauchen.

Da die hier vorgestellten Frontends ohnehin auf Linux-Systemen arbeiten, haben wir direkt eine Console zur Verfügung. Am Einfachsten verbindet man sich via SSH auf das jeweilige Host-System und ruft dort eine Console zu dem virtualisierten Rechner auf. Vorausgesetzt, das jeweilige Betriebssystem, welches auf der virtuellen Maschine läuft, unterstützt die Ausgabe der Bildschirm-Informationen über eine serielle Console. (Windows fällt da schon einmal weg) J

Sollte ein virtualisiertes Windows zum Einsatz kommen, muss die Installation entweder durch jemand, der die VNC-Schnittstelle verwenden kann, durchgeführt / unterstützt werden, oder man verwendet eine sogenannte unbeaufsichtigte Installation. Dort wird eine sogenannte Antwort-Datei auf dem Installationsdatenträger hinterlegt, in der alle Einstellungen, die das Windows-Setup abfragt, hinterlegt sind. Zusetzlich kann über diesen Weg auch weitere Software wie ein ScreenReader automatisch installiert werden (Hier ist allerdings recht viel Arbeit im Vorfeld erforderlich). Dieses Vorgehen im Detail zu erläutern, würde den Rahmen dieser Serie sprängen.

Im nächsten Teil betrachten wir den Hypervisor Xen und schauen, wie dieser verwendet werden kann.

Ab sofort: Zarafa Partner!

Wir sind ab sofort offizieller Partner von Zarafa!

Realisieren Sie mit uns professionelle Groupware-Umgebungen und beziehen Sie ihre vollständige Mail-Infrastruktur mit ein!

Selbstverständlich achten wir auch hier auf die Barrierefreiheit! Wir sind mit dem Entwicklerteam von Zarafa in direktem Kontakt, um auftretende Probleme bei der Zugänglichkeit zu lösen!

Sprechen Sie uns doch einfach an!

Update von Owncloud auf Version 7

Nach ersten erfolgreichen Updates von Owncloud von Version 6.0.1 auf Version 7.0.1 hier ein paar kurze Hinweise:

  • Wie Immer: Sicherungen erstellen! Sowohl von der MYSQL-Datenbank, als auch von den Daten im Dateisystem.
  • Download der aktuellen Version von Owncloud von der Website http://owncloud.org
  • Auspacken des Archivs mit tar.
  • Das alte Owncloud-Verzeichnis umbenennen (nicht nur „überkopieren“, dafür wurden zuviele Dateien entfernt, die beim „überkopieren“ noch da bleiben würden).
  • Neue Owncloud-Version in das alte (jetzt leere) Verzeichnis kopieren.
  • Die Konfigurationsdatei der alten Version unterhalb von /config/config.php in die neue Version kopieren.
  • An der Weboberfläche anmelden und abwarten, bis das Update erfolgreich eingespielt wurde.
  • Done!

Die App notizen nachinstallieren

Nach dem Update fehlt die App Notizen. Wer diese App in Version 6 genutzt hatte, muss sie per Hand nachinstallieren:

  • Die App Tasks Enhanced von der Website laden.
  • App in das Unterverzeichnis apps entpacken.
  • Zum Schluss muss die App noch in der Weboberfläche aktiviert werden.