Timo's Notitz-Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
[[:start|Notitzen rund um den Computer]]
====== KVM am Ubuntu-Root-Server ======
http://www.pro-linux.de/artikel/2/1490/kvm-am-ubuntu-root-server.html

Der Ausgangspunkt für diese Anleitung ist ein Ubuntu-Root-Server mit zusätzlichen, freien IP-Adressen. Das Ziel: Die Ausführung mehrerer virtueller Server, wobei jeder über eine eigene IP-Adresse aus dem Internet erreichbar ist.
Von Michael Kofler

Vorweg: Überblick über die erforderlichen Schritte

    * Installation von KVM und der libvirt-Werkzeuge
    * Download eines Ubuntu-ISO-Images als Basis für die Server-Installation
    * Erstellung einer virtuellen Ubuntu-Maschine, vorerst noch ohne öffentlichen Netzwerkzugang
    * Konfiguration einer Netzwerkbrücke am Root-Server
    * Änderung der Netzwerkkonfiguration der virtuellen Maschine

Wer schon etwas KVM-Erfahrung hat, kann zuerst die Netzwerkbrücke einrichten und diese bei der Installation der virtuellen Maschine sofort verwenden. Das verkürzt die Arbeiten um ein paar Minuten.

Ich gehe in diesem Artikel davon aus, dass sich die IP-Adresse des Root-Servers und die für die virtuellen Maschinen vorgesehenen Adressen nicht im gleichen Segment befinden. Dieser Fall tritt in der Praxis oft auf, wenn zusätzliche IP-Adressen erst nachträglich erworben oder zugewiesen werden.

Des weiteren gehe ich davon aus, dass Sie mit den libvirt-Werkzeugen arbeiten möchten (und nicht direkt mit dem KVM-Kommando). Die libvirt-Werkzeuge vereinfachen sowohl die Netzwerkintegration als auch die Verwaltung der virtuellen Maschinen.

Ich habe für meine Tests die 64-Bit-Version von Ubuntu Server 10.04 LTS verwendet (sowohl als Host am Root-Server als auch als Gast). Grundsätzlich spricht aber nur der kleinere Update-Zeitraum dagegen, Ubuntu 10.10 zu verwenden.

Zuletzt noch eine Warnung: Auch wenn ich mich bemüht habe, die Vorgehensweise möglichst verständlich darzustellen, kann ich hier nicht auf alle Grundlagen eingehen (sonst würde aus diesem ohnedies sehr langen Artikel ein Buch). KVM- oder allgemeine Virtualisierungs-Vorkenntnisse schaden also nicht!

Vorbereitungsarbeiten

Zuerst sollten Sie testen, ob die CPU Ihres Root-Servers Hardware-Funktionen zur Virtualisierung hat und somit KVM-kompatibel ist. Unter Ubuntu ist für diesen Test das Kommando kvm-ok vorgesehen.

''$ **kvm-ok**\\
INFO: Your CPU supports KVM extensions''

===== Die Installation der KVM- und libvirt-Werkzeuge ist schnell erledigt: =====
''# **apt-get install qemu-kvm virtinst libvirt-bin**''

Als Basis für die folgende Installation laden Sie sich das ISO-Image für Ubuntu-Server herunter, z.B. so:

''$ **wget http://releases.ubuntu.com/lucid/ubuntu-10.04.1-server-amd64.iso**''

==== Virtuelle Maschine installieren ====
Mit dem Kommando virt-install richten Sie eine neue virtuelle Maschine ein. An das Kommando können unzählige Optionen übergeben werden (siehe man virt-install): --os-variant gibt an, welches Gastsystem installiert werden soll. Diese Angabe hilft bei der Optimierung der emulierten Hardware-Komponenten. --name gibt der virtuellen Maschine einen Namen für die libvirt-Verwaltung.

**--ram** gibt die Größe des RAMs in MByte an. **--cdrom** gibt den Ort der ISO-Datei mit dem Installationsmedium an. **--disk** gibt den Ort der Image-Datei an, die als virtuelle Festplatte dienen soll. Wenn diese Datei noch nicht existiert, wird sie erzeugt, wobei size die Größe in GByte angibt. Den Ort für die Image-Datei können Sie beliebig wählen, üblich ist aber das Verzeichnis **/var/lib/libvirt/images**.

**--vnc** gibt schließlich an, dass das Grafiksystem der virtuellen Maschine via VNC gesteuert werden soll. virt-install muss mit root-Rechten bzw. mit sudo ausgeführt werden.

''# **virt-install --os-variant ubuntulucid --name kvmblog --ram 512 --cdrom ubuntu.iso --disk /var/lib/libvirt/images/kvmblog.img,size=10 --vnc**''

Wenn Sie keine Tippfehler gemacht haben, erzeugt virt-install jetzt die neue Image-Datei und startet dann die virtuelle Maschine. Davon können Sie sich mit dem Kommando virsh list überzeugen, das alle laufenden virtuellen Maschinen aufzählt.

''# **virsh list**''
<code>
Id Name                 State
----------------------------------
5 kvmblog              running
</code>

Über welchen VNC-Port die virtuelle Maschine bedient werden kann, verrät virsh vncdisplay name.

''# **virsh vncdisplay kvmblog**''
<code>
:0
</code>

Die eigentliche Installation führen Sie nun mit einem VNC-Viewer zuhause durch. Dabei stellen Sie via SSH eine Verbindung zum Root-Server her. Wenn Sie zuhause unter Ubuntu arbeiten, installieren Sie dort am besten das Paket vncviewer und starten das Programm dann so:

''zuhause$ **vncviewer -via ihrlogin@ihr-root-server localhost:0**''

Dabei müssen Sie Ihr SSH-Login-Passwort angeben. Die Portnummer nach localhost muss dem Ergebnis von vncdisplay entsprechen. Normalerweise ist das :0, wenn nur eine virtuelle Maschine läuft. Wenn mehrere virtuelle Maschinen laufen, bekommt jede virtuelle Maschine einen eigenen Port. Im Fenster des VNC-Clients sollten Sie nun das Ubuntu-Installationsprogramm sehen:


==== Ubuntu-Installationsprogramm in VNC ====

Die Ubuntu-Installation beginnen Sie mit der Auswahl der Sprache und dann mit der Funktionstaste F4, mit der Sie die Variante Eine minimale virtuelle Maschine installieren wählen können. Gegenüber einer normalen Server-Installation hat das den Vorteil, dass ein für virtuelle Hardware optimierter Kernel zum Einsatz kommt.

Wenn Sie die Installation fortsetzen, wechselt das Installationsprogramm die VGA-Auflösung. Das wirft den VNC-Viewer möglicherweise aus der Bahn. Starten Sie das Programm einfach neu, die Installation geht weiter, die virtuelle Maschine läuft noch.

Der weiterer Installationsverlauf ist genau gleich, als würden Sie Ubuntu auf physikalischer Hardware installieren. Meine Empfehlung zur Partitionierung der (virtuellen) Festplatte: Verwenden Sie LVM, dann können Sie die virtuelle Maschine später unkompliziert um eine zweite virtuelle Festplatte erweitern und so den LVM-Speicherpool vergrößern.

Noch eine Anmerkung zur Netzwerkkonfiguration: Da hier bei virt-install keine genaueren Angaben gemacht wurden, kommt (vorerst) das virtuelle Netzwerk default der libvirt-Werkzeuge zum Einsatz. Die virtuelle Maschine erhält deswegen ihre Netzwerkparameter via DHCP. Sie befindet sich in einem internen Netzwerk (IP-Adressbereich 192.168.122.*) und ist nur vom Host-Rechner aus erreichbar. Die virtuelle Maschine kann via NAT mit dem Internet kommunizieren, ist aber (noch) nicht aus dem Internet erreichbar.

Während der Ubuntu-Server-Installation können Sie auswählen, welche Server-Dienste Sie nutzen möchten. Es ist in der Regel zweckmäßig, hier die zwei Punkte Basic Ubuntu Server und OpenSSH server auszuwählen.

Wenn die Installation abgeschlossen ist, wird die virtuelle Maschine gestoppt. Um sie neu zu starten, führen Sie virsh start aus.

''# **virsh start kvmblog**''

Anschließend können Sie (wieder via VNC) innerhalb der virtuellen Maschine Konfigurations- und Administrationsarbeiten durchführen - z.B. Updates durchführen, Ihren Lieblingseditor installieren etc. Damit Sie die virtuelle Maschine mit virsh shutdown durch ein ACPI-Signal geordnet herunterfahren können, müssen Sie innerhalb der virtuellen Maschine das Paket »acpid« installieren.

''kvmblog# **apt-get update && apt-get dist-upgrade**''
''kvmblog# **apt-get install acpid**''

Damit ist Ihre virtuelle Maschine im Prinzip einsatzbereit. Sie kann durch virsh-Kommandos gestartet und gestoppt werden. Aufpassen sollten Sie allerdings bei einem Reboot des Root-Servers: Fahren Sie vorher alle virtuelle Maschinen herunter, sonst werden diese einfach ausgeschaltet! Nach dem Reboot müssen Sie die virtuellen Maschinen nach Bedarf neu starten. (Der Neustart lässt sich durch virsh autostart automatisieren, das Herunterfahren bei Bedarf durch ein entsprechendes Init-Script.)

Sollte beim Einrichten der virtuellen Maschine etwas schief gehen und Sie den Vorgang vollkommen neu starten möchten, können Sie die Ausführung der virtuellen Maschine mit virsh destroy radikal stoppen und die Definition der virtuellen Maschine dann mit virsh undefine löschen. (Dieses Kommando löscht die Datei name.xml im Verzeichnis /etc/libvirt/qemu. Diese Datei beschreibt die Parameter der virtuellen Maschine.) Wenn Sie auch die Image-Datei (also die virtuelle Festplatte) löschen möchten, verwenden Sie dazu rm:

''# **virsh destroy kvmblog**''
''# **virsh undefine kvmblog**''
''# **rm /var/lib/libvirt/images/kvmblog.img**''

===== Der Brückenschlag ins Internet =====
Ich gehe jetzt davon aus, dass der Hostrechner die öffentliche IP-Adresse 212.238.211.2 hat. (Diese und alle weiteren Adressen haben reinen Beispielcharakter!) Außerdem stehen Ihnen acht weitere IP-Adressen von 79.47.194.160 bis .167 zur Verfügung (79.47.194.160/29 in der Kurznotation), also in einem vollkommen anderen Netzwerksegment.

In der Regel ist es so, dass die erste und letzte Adresse des Adresspools nicht direkt verwendet werden können, weil sie als Netzwerkadresse bzw. als Broadcast-Adresse für das Subnetz dienen. Das reduziert die Anzahl der frei verwendbaren IP-Adressen auf sechs, also 79.47.194.161 bis .166.

Wie kommen IP-Pakete, die an die Adressen 79.47.194.161 bis .166 gerichtet sind, zu Ihrem Root-Server mit der IP-Adresse 212.238.211.2? Normalerweise kümmert sich Ihr Root-Server-Provider um das erforderliche Routing. Mit anderen Worten: Der Router Ihres Providers ist so programmiert, dass ein an 79.47.194.161 adressiertes IP-Paket direkt zu Ihrem Hostrechner geleitet wird.

An dieser Stelle beginnen nun Ihre Konfigurationsarbeiten: Sie müssen sicherstellen, dass diese IP-Pakete an die entsprechende virtuelle Maschine weitergeleitet werden. Dazu bestehen zwei Möglichkeiten: durch eine Netzwerkbrücke (Bridge) oder durch zusätzliche Routen, die Sie auf Ihrem Hostrechner einrichten. Ich beschreibe hier nur die Bridge-Variante, die mit wesentlich weniger Konfigurationsaufwand verbunden ist. Ihr Nachteil besteht darin, dass eine IP-Adresse des Subnetzes (in diesem Beispiel 79.47.194.166) für die Bridge benötigt wird.

Vorsicht: Wenn Sie bei der Änderung der Netzwerkkonfiguration eines Root-Servers Fehler machen, kann es Ihnen passieren, dass Sie den Netzwerkzugang zum Root-Server verlieren. (Ich spreche aus Erfahrung ...) Bevor Sie die Netzwerkkonfiguration ändern, sollten Sie daher sicherstellen, dass Sie zur Not über ein Rescue-System auf das Dateisystem Ihres Root-Servers zugreifen und auf diese Weise falsche Konfigurationsdateien in den bisherigen Zustand zurückversetzen können. Eine Sicherheitskopie des /etc-Verzeichnisses ist dabei hilfreich - dann können Sie modifizierte Dateien problemlos wieder in den Originalzustand bringen.

Bei den ersten Experimenten ist es zweckmäßig, eine bleibende Veränderung der Netzwerkkonfiguration zu vermeiden und die Bridge vorläufig manuell mit »brctl« und »ifconfig« einzurichten. Dazu reichen zwei simple Kommandos aus: **»brctl«** richtet die Bridge br0 ein (verwenden Sie einen anderen Namen, wenn br0 bei Ihnen bereits in Verwendung ist), und **»ifconfig«** legt die IP-Adresse und Netzwerkmaske für die Bridge fest.  Bei der Ausführung von ifconfig wird automatisch eine Route zu 79.47.194.160 eingerichtet, wovon Sie sich mit route -n überzeugen können.

''# **brctl addbr br0**''
''# **ifconfig br0 79.47.194.166 netmask 255.255.255.248 up**''
''# **route -n**''
<code>
Kernel IP routing table
Destination   Gateway   Genmask         Flags Metric Ref Use Iface
79.47.194.160 0.0.0.0   255.255.255.248 U     0      0     0 br0
...
</code>

Sollte es notwendig sein, können Sie die Bridge mit **ifconfig br0 down** und **brctl delbr br0** wieder entfernen.

Definition der virtuellen Maschine ändern

Nun geht es darum, die Definition der virtuellen Maschine dahingehend zu ändern, dass diese über die Netzwerkbrücke br0 kommuniziert. Dazu fahren Sie die virtuelle Maschine herunter und führen dann virsh edit aus. Wenn Sie die Änderungen an der XML-Datei nicht mit dem vi durchführen möchten, müssen Sie vorher export EDITOR=xxx ausführen.

''# **export EDITOR=jmacs**''
''# **virsh edit kvmblog**''

Die XML-Datei enthält einige Zeilen, die die Netzwerkschnittstelle beschreiben:

<code>
<interface type='network'>
<mac address='52:54:00:4a:eb:25'/>
<source network='default'/>
<model type='virtio'/>
</interface>
</code>

Darin führen Sie die folgenden Änderungen aus:

<code>
<interface type='bridge'>
<mac address='52:54:00:4a:eb:25'/>
<source bridge='br0'/>
<model type='virtio'/>
</interface>
</code>

Netzwerkkonfiguration in der virtuellen Maschine ändern

Nun starten Sie die virtuelle Maschine neu (virsh start kvmblog) und ändern jetzt via VNC die Netzwerkkonfiguration in der virtuellen Maschine. Entscheidend ist die Datei /etc/network/interfaces, die Sie wie im folgenden Muster einrichten:

<code>
# **/etc/interfaces/network (in der virtuellen Ubuntu-Maschine)
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 79.47.194.161
netmask 255.255.255.248
gateway 79.47.194.166
</code>

Damit verwendet die virtuelle Maschine die IP-Adresse 79.47.194.161. Als Gateway dient die Bridge, also 79.47.194.166. Was jetzt noch fehlt, ist die manuelle Konfiguration des Name-Servers in der Datei /etc/resolv.conf. (Hier verwenden Sie dieselbe Einstellung wie auf Ihrem Root-Server.)

/etc/init.d/networking restart aktiviert die neuen Netzwerkeinstellungen. Anschließend können Sie testen, ob alles funktioniert: Sowohl auf dem Hostrechner als auch in den virtuellen Maschinen muss es möglich sein, sich gegenseitig ping-Signale zuzusenden. Innerhalb der virtuellen Maschine muss das Internet erreichbar sein, und die virtuelle Maschine muss nun auch aus dem Internet erreichbar sein (testen Sie z.B. das SSH-Login). Damit können Sie nun (endlich) die Administration der virtuellen Maschine via SSH fortsetzen und sind nicht länger auf VNC angewiesen.

Netzwerkkonfiguration des Root-Servers ändern

Bei einem Neustart des Root-Servers geht die mit **»brctl«** und **»ifconfig«** eingerichtete Netzwerkbrücke verloren. Natürlich können Sie diese Kommandos durch ein Init-Script automatisch ausführen. Besser ist es aber, die Konfigurationsdatei /etc/network/interfaces des Root-Servers so zu ändern, dass die Netzwerkbrücke durch die Netzwerk-Scripts von Ubuntu automatisch errichtet wird. Dem bisherigen Beispiel folgend muss die Datei so aussehen:

<code>
# /etc/interfaces/network (auf dem Ubuntu-Hostrechner)
auto lo
iface lo inet loopback

# Device eth0 (unverändert)
auto  eth0
iface eth0 inet static
address   212.238.211.2
broadcast 212.238.211.31
netmask   255.255.255.224
gateway   212.238.211.1

# Device br0 (die Netzwerkbrücke)
auto br0
iface br0 inet static
address   79.47.194.166
netmask   255.255.255.248
pre-up    brctl addbr br0
post-down brctl delbr br0
bridge_maxwait 2
</code>

Dabei sind mehrere Details wichtig: Das Bridge-Device muss vor dem Aufbau der Brücke manuell eingerichtet und danach wieder entfernt werden. Darum kümmern sich die Kommandos **»pre-up«** und **»post-down«**. bridge_maxwait 2 stellt sicher, dass der Brückenaufbau den Bootprozess nicht unnötig bremst.

Autoreninformation

Dieser Artikel wurde auch auf der Seite des Autors unter kofler.info veröffentlicht. Darüber hinaus führt Michael Kofler ein Blog zum Thema.