Die VM starten

Wenn die VM-Konfiguration fertig ist, sollte die Konfigurationsdatei ihren Weg auch auf den anderen Clusterknoten finden. Danach genügt ein »virsh define/etc/libvirt/qemu/ File « , um die Ressourcen-Definition in die Libvirt zu laden. Die »virsh« ist die hauseigene Shell der Libvirt, die das Starten, Stoppen und Modifizieren virtueller Maschinen ermöglicht. Wer es etwas bunter mag, installiert auf seiner Workstation den »virt-manager« ( Abbildung 2 ) und erhält so nach dem Einrichten einer Verbindung mit dem Zielsystem ein GUI, das die virtuellen Maschinen verwalten kann.

Abbildung 2: Der Virt-Manager ist ein praktisches Werkzeug, um eine grafische Übersicht über die VMs eines Hosts zu bekommen.

Nun fehlt eigentlich bloß noch der erste Start der virtuellen Maschine, um sie zu konfigurieren. Das erledigt entweder der Befehl »virsh start Name « auf der Kommandozeile des Servers oder ein entsprechender Klick im »virt-manager« . Achtung: Weil die DRBD-Ressource noch nicht von Pacemaker verwaltet wird, muss das händische Starten der virtuellen Maschine auf genau dem Host passieren, auf dem die DRBD-Ressource gerade im »Primary« -Modus läuft. Hat alles funktioniert, kann die Installation und Konfiguration der VM losgehen.

Übrigens: Damit Pacemaker später über seinen VM-Resource-Agent mit Libvirt und den virtuellen Maschinen kommunzieren kann, muss die VM in der Lage sein, ACPI-Befehle zu interpretieren. Libvirt initiiert den Shutdown einer VM durch ein entsprechendes ACPI-Signal. Damit das Gast-Betriebssystem damit umgehen kann, muss es ACPI können. Unter Linux lässt sich das Problem bereits dadurch aus der Welt schaffen, den »acpid« ( Abbildung 3 ) zu installieren. Dieser tut ab Werk bei einem Druck auf den Power-Knopf – nichts anderes ist das Signal, welches Libvirt an eine VM für den Shutdown schickt – bereits das Richtige.

Abbildung 3: Der acpid ist in Linux-VMs notwendig, damit Libvirt das System von außen mittels virtuellem Knopfdruck herunterfahren kann.

Die Integration in Pacemaker

Wenn die virtuelle Maschine fertig konfiguriert ist und läuft, ist noch sicherzustellen, dass der Start nahtlos auf beiden Rechnern funktioniert. Dazu sollte wie bereits erwähnt zumindest die ».xml« -Konfiguration der VM auf beiden Rechnern vorhanden und identisch sein. Ob die VM problemlos auf beiden Rechnern lauffähig ist, lässt sich am leichtesten dadurch testen, dass sie auf dem aktuellen Rechner heruntergefahren wird, um danach einen Rollentausch der DRBD-Ressource (Wechsel Primary und Secondary) zu machen und dann auf dem anderen Clusterknoten ebenfalls die VM zu starten. Kommt sie problemlos hoch, ist die Libvirt-Konfiguration in Ordnung und es geht daran, Libvirt in Pacemaker zu integrieren.

Dazu muss zunächst die vorhandene DRBD-Ressource ihren Weg in die CIB finden. Wie das geht, das wurde im zweiten Teil der HA-Serie detailliert erklärt. Colocation- oder Order-Constraints sind zu diesem Zeitpunkt noch unnötig, denn es fehlt im Moment noch die virtuelle Maschine selbst.

Der Resource-Agent für die Anbindung von Pacemaker an die Libvirt heißt »ocf:heartbeat:VirtualDomain« . Der Code stammt ursprünglich aus der Feder von Florian Haas, gehört mittlerweile allerdings zur OCF-Sammlung des Linux-HA-Projektes und ist somit Bestandteil jeder HA-Installation. Seine Verwendung dokumentiert das Exempel in Listing 2 .

Das Beispiel lässt sich so übernehmen, anzupassen sind lediglich die Parameter. Der erste Parameter »config« zeigt auf die Konfiguration der virtuellen Maschine, der zweite Parameter »force_stop« legt fest, ob die Domäne von Pacemaker getötet werden soll, wenn sie nach einem per ACPI übermittelten Shutdown-Request nicht selbstständig herunterfährt. Im Normall sollte »force_stop« auf den Wert »false« gesetzt sein. Bei virtuellen Maschinen mit Windows-Betriebssystem kann es aber unter Umständen notwendig sein, diese Funktion doch zu aktivieren.