====== Erläuterungen ====== {{::openqrm:openqrm_menue.png|}} ===== Begriffserklärung ===== ==== VM Manager (1) ==== Im VM-Manager werden neue VM's angelegt, gestoppt, konfiguriert, gestartet oder einem Restart unterzogen. Hierbei handelt es sich jedoch nur um die virtuelle Maschine, die erst in der Appliance mit einem Image zusammengefügt wird um das Äquivalent eines kompletten Rechners darzustellen. ==== Resource (2) ==== Eine Resource ist entweder ein physikalischer Rechner oder eine VM. Abstrakt ausgedrückt, ist alles worauf ein Betriebssystem laufen kann (rechentechnisch => CPU) bei openQRM, eine Resource. ==== Storage (3) ==== In openQRM wird alles als Storage bezeichnet, wo man Daten nichtflüchtig speichern kann. Hierzu zählen in unserem Fall in erster Linie logische Laufwerke (LV's). Ein Storage ist immer auch an ein Übertragungsprotokoll gebunden, in unserem Fall verwenden wir die Protokolle "NFS" und "AoE". Es ist aber auch möglich "iSCSI" einzusetzen. ==== Image (4) ==== Ein Image könnte man als Rezept bezeichnen, in dem beschrieben wird, welche Zutaten ein Storage benötigt, damit es einer Resource schmeckt. Mit anderen Worten wird hier beschrieben, was die Resouce mit dem Storage machen soll, damit beides zusammen (in unserem Sinne) funktionieren kann. Ein Image ist immer auch an ein Übertragungsprotokoll gebunden (gezwungener maßen, da es ja auf einem Storage basiert), in unserem Fall verwenden wir die Protokolle "NFS" und "AoE". Es ist aber auch möglich "iSCSI" einzusetzen. Leider wird der Begriff "Image" in openQRM für zwei verschiedene Dinge verwendet. Eine gepackte Betriebssysteminstallation wird ebenfalls als "Image" bezeichnet, ist aber etwas völlig anderes! Ich persönlich würde den Begriff "Image" weder für das eine noch für das andere verwenden, denn "Image" bezeichnet im wörtlichen Sinne ein "Abbild" und weder das eine noch das andere ist eine Abbildung. Das eine ist in meinen Augen eine "VM-Boot-Anweisung" und das andere ein "Installations-Archiv". ==== Appliance (5) ==== Mit Hilfe einer Appliance weist man einer Resource ein Image zu, sodass man ein vollständig funktionierendes Rechnersystem (physisch oder virtuell) erhält. ==== Plugin Manager (6) ==== Durch Plugin's kann openQRM zusätzliche Funktionen bekommen. Zum Beispiel kann ein AoE-Storage erst dann angelegt werden, wenn das AoE-Plugin gestartet wurde. Ebenso ist es im allgemeinen notwendig das die Plugins für DNS und DHCP gestartet wurden. Für einen Neustart des DNS-Dienstes, muss man z.B. hier das entsprechende Plugin stoppen und dann wieder starten. ===== Beschreibung ===== ==== Ziel ==== Das Ziel dieser Doku ist es, die Handhabung von openQRM an Hand eines ganz konkreten Beispieles zu zeigen. Auf diesem Beispiel aufbauend kann man, im laufe der Zeit, sein Wissen über openQRM nach und nach erweitern. Das hier beschriebene Beispiel beschreibt eine VM-Installation, mit dessen Hilfe ein NFS-Storage sowie ein AoE-Storage befüllt werden. Im finalen Zustand wird die VM das AoE-Storage als "Root-Device" verwenden. ==== Vorgehensweise ==== Damit openQRM richtig funktionieren kann, müssen eine Reihe von Programm-Paketen installiert sein. Einen Teil installiert das openQRM-Setup selbst, andere werden schlicht vorausgesetzt. Zu diesen benötigten Paketen gehören DHCP und TFTP. Diese sollten (wenn alles nach Plan läuft) gestartet sein. Wird jetzt ein physikalischer Rechner hochgefahren, sollte man darauf achten, das er als erstes einen PXE-Boot über die Netzwerkkarte versucht, dann bekommt er vom DHCP eine IP zugeteilt und ihm wird auch per TFTP ein Linux-Kernel und eine initrd übergeben. Ist der Bootvorgang abgeschlossen, steht dieses System automatisch in openQRM als Resource bereit und kann durch openQRM verwaltet werden. Dieser Vorgang ist so simpel, das er in dieser Doku nur erwähnt wird. Eine andere Möglichkeit eine Resource bereit zu stellen, ist die, dass man sich eine VM einrichtet. Wie man eine KVM-VM einrichtet wird in dieser Doku ausführlich beschrieben. Als nächstes benötigt unsere neue Resource ein Betriebssystem. Die normale Vorgehensweise von openQRM ist die, dass man sich ein vorbereitetes Image (so werden hier gepackte Betriebssysteminstallationen genannt; nicht zu verwechseln mit den "Rezepten", die man in openQRM unter dem Menüpunkt "Base / Components / Images" sieht), von deren Web-Seite gesaugt. Das wird gewöhnlich über den Menüpunkt "Plugins / Deployment / Image-shelf / Import" realisiert. Es ist auch möglich, sich so ein Image (Installations-Archiv) aus einem vorhandenen System zu erstellen, wenn das System von openQRM verwaltet wird. Hier wird allerdings beschrieben, wie man eine Neuinstallation von Ubuntu in einer VM durchführt. Das geht mit dem Standard-Release von openQRM nicht, denn diese Funktion wird erst durch einen selbst geschriebenen Patch bereitgestellt. Da wir in openQRM flexibel sein wollen, ist es sinnvoll, einen über NFS exportierten Speicherbereich einzurichten, denn NFS wird in openQRM sehr vielseitig verwendet. Dazu muss zunächst ein NFS-Storage erstellt werden in dem man im zweiten Schritt ein logisches Laufwerk anlegt. Im Anschluss muss dann ein NFS-Image (ich nenne es in der Begriffserklärung "Rezept") formuliert werden. Um damit arbeiten zu können braucht man jetzt eine Appliance. Eine Appliance verbindet unsere VM (Resource) mit Speicherplatz (Image bzw. "Rezept"). In unserem Fall soll hier nur die frische lokale Installation auf das NFS-Storage übertragen werden (wie unten beschrieben wird). Nachdem dieser Vorgang abgeschlossen ist, können wir an das eigentliche Ziel gehen. Und legen uns, genau wie für NFS schon getan, ein AoE-Storage mit logischem Laufwerk an sowie ein AoE-Image ("Rezept"). Die Appliance könnte man jetzt umkonfigurieren, sodass es nicht mehr das NFS-Storage sondern das AoE-Storage als Root-Device verwendet aber (wie ich unten erwähne) kann das zu Problemen führen. Deshalb löschen wir die NFS-Appliance und legen uns eine neue AoE-Appliance an. Beim Start der Appliance wird eine Kopie der Installation vom NFS-Storage auf das AoE-Storage übertragen. Im Anschluss muss im AoE-Image ("Rezept") die Konfiguration so angepasst werden, dass beim nächsten Start der VM die Übertragung nicht erneut stattfindet. Jetzt haben wir eine funktionierende virtuelle Maschine, wie wir sie (unter anderem) einsetzen wollen. ===== Wissenswerte Hinweise ===== Bestimmte Eigenschaften, die unter bestimmten Umständen auch als Bug's bezeichnet werden können, sollte man kennen. Das erspart dem Anwender unter Umständen viele graue Haare! Hier will ich kurz die Dinge aufzählen, die mir bekannt sind: - Es gibt Fälle, in denen das NFS-Storage nicht richtig exportiert wird. So kommt es vor das ein NFS-Storage nur mit einer Berechtigung für die lokale IP des openQRM-Servers exportiert wird. Das kann natürlich nicht funktionieren. In so einem Fall muss man die IP für den Export in der Datei "/etc/exports" korrigieren und mit dem Befehl "exportfs -r" erneut exportieren. Möglicherweise funktioniert es auch, wenn man die entsprechende Appliance stoppt und wieder startet. - Sollte man ein "-" im LV-Namen benutzt haben (wie hier), dann wird der Device-Manager (dm) den Bindestrich in zwei Bindestriche umwandeln, somit stimmt der Name der Gerätedatei und der Config-Eintrag von openQRM nicht überein! Dann sollte man das LV löschen und erneut anlegen. Als Bindestrich sollte man den Unterstrich verwenden. - Legt man von einem, per AoE exportierten, LV ein "clone" an, dann verliert der AoE-Export seine Zuordnung (MAC-Adresse). In diesem Fall kann man die entsprechende Appliance stoppen und erneut starten, denn beim Start einer Appliance wird der entsprechende AoE-Export wieder einer MAC-Adresse zugeordnet. Oder man schreibt die MAC-Adresse von Hand wieder an die entsprechende Stelle in die Datei "/etc/vblade.conf" und startet den vblade-Dienst "/etc/init.d/vblade reload" neu.