Sie sind hier : Homepage →  > hier stehen die veralteten Seiten→  Linux (6b) Einen Server umziehen

Eine beinahe "never ending Story" - solch ein Umzug

Juni 2020 - von Gert Redlich - Das Ziel war, von der Pflege der eigenen Hardware unabhängig zu werden und mehr Zeit fürs Wesentliche - die Museenseiten - aufzubringen. Irgendwan muß man anfangen, abzuschminken, wenn es in der Summe über den Kopf wächst.
.

Vorhanden ein virtualisierter HP Server mit opensuse XEN

von hier
nach hier

Unser eigener HP Proliant DL 380 G5 hat 2 Opterons mit je 4 Kernen und 8 x 72GB RAID-5 Platten und 32 GB RAM. Das reichte für mehrere virtuelle Server auf dieser extrem stabilen und verlässlichen Hardware - über viele Jahre. Die Key-Programme waren alle Web-Services auf Basis des CMS typo3 mit php 5.3 und mysql. Ein CMS ist kein Shop oder ein sonstiges Transaktionsprogramm. Man kann es auch mal abschalten. Die opensuse Version 12.3 ist natürlich nicht mehr aktuell. So weit der Istzustand.

Die Grundlagen der Virtualisierung von Hardware.

Drei Beispiel-Gäste auf XEN

Bei der XEN Virtualisierung setze ich auf die physikalisch vorhandene Hardware (den PC) quasi den gemeinsamen (langen) virtuellen Keller (den "host") oben drauf, auf den dann wiederum eine Anzahl von darüber liegenden virtuellen Reihenhäusern (die VM-Gäste) installiert werden.

Brennt ein solches virtuelles (Reihen-) Haus ab (wird also einer der VM-Gäste gekillt), merken der Keller (der Host) und die anderen Gäste davon nichts. Das funktioniert bei mir seit zig Jahren verlässlich.
.

Der generelle Unterschied zwischen XEN und KVM

Der sogenannte Virt-Manager verwaltet die Gäste (die VMs)

Entscheidend ist die Ebene der symbolischen virtuellen "Kellerdecke" für die Gäste. Damit die Gäste irgendwie auf die gemeinsame Hardware schaun können, wird bei XEN der Linux-Kernel mit diversen XEN Modulen "aufgebohrt" und zu einem erweiterten XEN-Kernel neu "kompiliert" (zusammengebaut).

Auf diesem erweiterten XEN-Kernel setzt die Virtualisierungs-Ebene auf, die den Namen "virtlibd" (die Virtualisierungs-Bibliothek) erhalten hat. Sie sieht von oben - vom Gast aus gesehen - genau wie die eigentliche Server-Hardware aus. Alle Gäste sehen auf den gleichen virtuellen PC, als wenn jeder seinen eigenen echten PC (unter dem Hintern) hätte - genial.

Nachdem in die aktuellen modernen 64bit Prozessoren von Intel/AMD auch hardwareseitig Virtualisierungs- Funktionen in den Chip integriert wurden, geht es noch einfacher und noch performanter. Der neue XEN-Kernel nutzt nämlich einen Teil dieser neuen Prozessor-Funktionen.

Anders ist es bei der KVM Virtualisierung. Dort setzt diese Virtualisierungs-Ebene direkt auf dem ganz normalen Linux Kernel auf, in dem diese KVM-Technik beeits integriert war. Die Virtualisierungs-Funktionen werden (alle) vom Linux-kernel an die KVM- Prozessorfunktionen durchgereicht. Die Virtualisierungs-Ebene muß diese Funktionen nur noch an die diversen Gäste (nach oben) zur Verfügung stellen.
.

Ein grundlegender Unterschied zwischen XEN und KVM

.

  • "XEN" nennt man darum auch Software-Virtualisierung.
  • "KVM" nennt man dagegen die Hardware-Virtualisierung.


Performance Tests haben inzwischen nur noch marginale Unterschiede unterhalb von 1% messen können.  - Bei 8 Prozessor-Kernen (oder 12 oder sogar 64) ist das absolut bedeutungslos.

Doch erheblich wichtiger ist ein bedeutender Unterschied. Bei XEN werden die Gäste auf der Software-Ebene "absolut" voneinander getrennt. Bei KVM ist die Trennung "relativ", weil sie teilweise im Prozessor - in der Hardware - abgewickelt wird.

Bei XEN haben es bislang nur ganz wenige geschafft, über die Kaperung eines Gastes oder dessen totalen "Abschuss" den Host oder die anderen Gäste zu beeinträchtigen oder gar zu killen.

Bei KVM ist diese Trennung von Host und Gästen und den Gästen untereinander (zur Zeit - wir haben Mai 2020) nur theoretisch gegeben. Es ist praktisch möglich, durch das Übernehmen (Entern oder Kapern) eines Gastes das gesamte System samt Host und auch die Hardware zu kompromittieren oder gar stillzulegen.
.
Ich habe es noch nicht ausprobiert. Meine XEN-Server laufen seit vielen Jahren völlig problemlos und Erfahrung ist nun mal durch nichts zu ersetzen. (Ein Werbespruch der Firma REVOX.)
.

Gegebener Zustand in April 2020

Opensuse ist zur Zeit mit der Version 15.1 aktuell, baut aber bereits an der 15.2 (die dann ganz bestimmt wieder verläßlich läuft - wie immer). Im Januar 2020 waren die Versuche mit 15.1 leider negativ/instabil. Dagegen läuft die abgekündigte 42.3 (müsste eigentlich 14.3 heißen) richtig stabil, sowohl als Host wie auch als Gast. Auch das Key-Produkt, yast und yast2 läuft wieder so schnell wie früher. Ein Versuch mit der 15.1 mit den letze Updates (als VM-Gast) im April 2020 ging dann auch ganz gut, kam aber zu spät.

April 2020 - Also wird auf dem neuen Intel i7 Server (in Düsseldorf) zuerst die 42.3 als XEN Host installiert, dazu der XEN-Kernel samt Netzwerk-Bridge und die XEN-Tools samt Virt-Manager. Klappte hervorragend. Dann zwei Gäste sogar mit opensuse 15.1 und zusätzlich 2 Gäste mit 42.3, also 4 Gäste insgesamt..

Hintergrund : Dem Gast-Betriebssystem ist es völlig wurscht (muß es auch völlig wurscht sein !!!), was da unten drunter werkelt, also ob da eine 12.3 oder 42.3  läuft, die Virtualisierungsebene oben drüber muß stimmen.
.

opensuse XEN 42.3 "läuft" verlässlich - (it runs)

Mit dieser Erfahrung im Hinterkopf habe ich versucht, auf dem neu installierten 42.3 Server eine (für mich essentiell notwendige) 12.3 Version vom dwgd.de Netzrepository zu installieren und bin kläglich nach 3 oder 5 hartnäckigen Versuchen gescheitert. Auch die 13.2 Version ließ sich nicht installieren. Na gut, holen wir uns die 12.3 DVD mit 4.7 GB ins Boot und probieren es erneut (mehrfach). Diese Gast-Installation von einer 4,7 Gigabyte ISO müste doch ohne Netzwerk auskommen. Auch gescheitert. Auf die Idee, es bei mir im Wiesbadener EDV Labor auch mal zu probieren, kam ich zu der Zeit noch nicht, denn die Versionen 42.3 und die 15.1 gingen mit mehreren Minuten !!!! Verzögerung leidlich gut von der Hand. Noch hatte ich also keinen Leidensdruck.

Also irgend etwas läuft da schief im "myloc Webtropia" Housing in Düsseldorf.
.

Wieder ein Trick - einen zweiten Server angemietet

Um bei allen Versuchen nicht jedesmal den bereits produktiv laufenden Server neu starten zu müssen, habe ich bei myloc einen zusätzlichen Ryzen 5 Server angemietet. Auf den 2 x 1.8 TB Patten als Raid1 ist genügend Platz für alle da. Dort auch gleich opensuse 42.3 als host sowie XEN installiert und 2 Gäste mit 42.3 und 2 Gäste mit 15.1 aufgesetzt. Alles lief (mit einigen Timeouts) eigentlich problemlos. Ich kannte es ja nicht besser.

Neben dem DNS und dem Mailserver auch gleich einen ftp server (repos.ipw.net) aufgesetzt und dort von draußen die kompletten 12.3, 13.2 und 42,.3 repos rein geholt. Es sind über 180 GB Daten !!!. Bei 30 TB Transfer-Limit kein Problem.

Jetzt alle Installations-Versuche auf dem myloc intel i5 Server nochmal aus dem eigenen Repository (es ist jetzt kontrollierbar, wann der virt-install die Installation abbricht) Versuche mit einer Rückwärts-Reihenfolge, also erst 15.1, dann 42.3 und dann bei der 13.2 stockte es schon ganz erheblich und brach dann ab.
.

Und jetzt ein Glückstreffer in einem Suse-forum:

.

  • Thread: 12.3 VM install on 42.3 Host failes


https://forums.opensuse.org/showthread.php/540219-12-3-VM-install-on-42-3-Host-failes?p=2935831#post2935831


Mit opensuse 42.3 als Host und KVM (also kein XEN) hätte er die opensuse 12.3 ohne Probleme installiert. ...... Aha, es würde und es muß also gehen.
.

Mein Testserver, ein Fujitsu-Esprimo-e900-e90

Für meine Labor-Tests mit der Virtbox samt unterschiedlichen Windows Gästen (Win 2000, Win XP, Win 7 und Win 8.1) hatte ich seit Monaten einen solchen gebrauchten Fujitsu-Esprimo-e900-e90 im Labor (hatte gerade mal 70 Euro samt legaler Win 10 Lizenz gekostet), mit einer 4-Kern i5 CPU und 8GB Ram und (später zugekauften) 2 x 128 GB SSDs.

Also wenn es wirklich gehen sollte, hier "gleich und sofort" einen Versuch über meine 200 Mbit/s Fritzbox (Kabel) starten.

Aus meinem eigenen Repository von meinem 2. Server (der Ryzen 5 bei myloc) in Düsseldorf die opensuse 42.3 als Host - diesmal mit KVM Modulen, also nicht mit XEN, installiert, keine 3 Minuten. Völlig Irre !!! Dann die Korrektur des Hosts von DHCP auf eine feste IP - weniger als 1 Minute.

  1. Dann die Opensuse 12.3 als 1. Gast aus meinem Repos, weniger als 2 Minuten mit 800MB Download.
  2. Sogleich die 13.2 als 2. Gast installiert, etwa 3 Minuten mit 1,2 GB Download,
  3. dann die 42.3 als 3. Gast - ebenfalls etwa 3 Minuten mit 1,5GB Download und
  4. dann die 15.1 als 4. Gast mit etwa 2,1 GB Download in knapp 4 Minuten.


Das war völlig problemlos und schnell, also völlig Irre - reif für eine ganze Flasche Wodka. (Ich trinke aber keinen Alkohol.)
.

Also bei mir in Wiesbaden geht es alles problemlos.

Das gab erst mal ein Danke an das Forumsmitglied für den Tip. Der war Gold wert. Zu wissen, daß es irgendwo geht - super.
.

Zurück zum Server in Düsseldorf

Jetzt eine genauere Analyse, warum es im myloc Rechner-Schrank nicht geht. Es hängt nach dem Laden des 50MB großen Installations-Kernels (Teile 1 bis 6) aus irgend einem Netzwerk Repository immer wieder direkt nach dem (1. ??) DHCP Aufruf. Nach einem sehr langen Timeout kommt eine Art Rescue Textvariante (in grell bunt) der Installation und will die Netzwerk Daten nochmals haben.

Wichtig : Bei der Gast-Installtion von 42.3 und 15.1 tritt dieser DHCP Effekt nicht auf, dort läuft es erträglich flink - mit jeweils mehreren längeren Timeouts durch.

Diese komische Text-Maske nach dem Timeout kommt auch von der 12.3 und der 13.2 DVD ISO Installation (jdesmal 4,7GB !!), und das machte mich ganz besonders skeptisch.

Wenn es bei mir in Wiesbaden nicht wirklich "ratz fatz" gehen würde, wäre ich der Annahme erelgen, es geht halt nicht besser.

Die Antworten aus dem myloc Support-Team würde ich als sehr durchwachsen bezeichnen, damit dort keiner in Tränen ausbricht. Nach 25 Jahre Internet EDV kann man mir keinen solchen dummen Schmus "verzählen". Nach vielen sehr erfreulichen Support-Hilfen - auch Nachts um drei - war das der erste Tiefschlag von myloc webtropia, wie man es nicht machen sollte.

Auf meine Anfrage, warum mein uralter DHCP Server (oder der aus der Kabel-Fritzbox) in Bruchteilen von Sekunden eine IP Adresse aus dem hiesigen Kontingent liefert (ich habe auch einen Gigabt Switch) und es dort im Rechenzentrum bis zu 3 Minuten dauere (Nachts um drei !!!! war ich ganz bestimmt einer von ganz ganz wenigen), das DHCP wäre sowieso nur für interne myloc repos verfügbar.

Das ist natürlich Quatsch, denn nach der Netzwerk-URL-Installation aus dem eigenen myloc oder dem repos.gwdg.de Repository werden die Updates aus dem "download.opensuse.com" herunter geladen, also über eine DHCP Verbindung, denn eine IP Nummer hatte ich bislang ja gar nicht vergeben.

So, wie ich es mit der opensuse 12.3 geplant hatte, ging es also nicht. Ein Trick war gefragt - doch welcher ?

Bislang hatte ich mich nie ernsthaft mit der Startprozedur von virtuellen Maschinen beschäftigt. Es hatte ja funktioniert. Jetzt wollte ich herausfinden, was braucht denn der sogenannte Virtualisierungs-Manager, um eine VM zu starten. Angeblich sei da eine Datenbank dahinter, ist leider auch alles Quatsch von gewichtigen Dillettanten in diversen debian und Red-Hat Foren.

Es sind simple xml Dateien pro einzelner VM. Wird eine neue VM angelegt, wird in /etc/libvirt/qemu/ eine xml Datei generiert, in der die gesamten Startprozeduren stehen. Ein Vergleich auf meinem Inhaus test-Server, der jetzt ja 4 unterschiedliche opensuse Gäste startet, öffnet die Augen :

Der Unterschied liegt lediglich bei der boot-Partition, also md4 oder md5 oder md6 oder md7 (alles Raid1 Partitionen) und der Benennung des Chipsatzes der CPU.

Ein weiterer Vergleich mit den Installationen auf dem Ryzen 5 Server und dem Intel i7 Server bestätigt das, denn auch dort habe ich nur Raid1 Partitionen.

Durch den Umstieg auf dem Düsseldorfer i7 Server von XEN nach KVM und der unveränderten Bootfähigkeit der unter XEN installierten Gäste lag also mein Augenmerk nur noch auf dem Chipsatz bzw. der Prozessor-Architektur.

Das ist es also, ich kann einer bereits installierten aber abgeschalteten VM mit beinahe beliebigem Betriebssystem eine ganz andere Betriebssystem-Variante unterschieben (oder überbügeln).

Nach der Anpassung von lediglich 2 Zeilen in der namentlich bekannten xml-Datei auf dem Host ist diese mit einem 10 Jahre alten root Filesystem überschriebene VM - im Prinzip - bootfähig - jedanfalls manchmal.
.

Die uralte VM reparieren - der Bootloader muckt

Irgend etwas hat aber nicht fuktioniert. Die VM startet nur bis zum grub2 Fehler. Ich nehme an, im Bootloader (oder MBR) steht die Inode des Boot-Verzeichnisses von /boot/ und die stimmt natürlich nicht mehr. Opensuse 12.3 verwaltet seine Platten noch nicht mit UUIDs !! Das wäre ein Vorteil.

Also muß ich den MBR reparieren. Das soll im Lifebtrieb oder mit der rescue Version von 12.3 gehen. Es geht aber nicht. Kann MBR nicht schreiben oder kann initrd nicht schreiben, jede Menge komischer Fehler.

Hier sucht man sich wirklich einen Wolf. Wie kan ich eine nicht startfähige VM dennoch starten. Es war wie immer - der Zufall.

Wenn ich also eine neue VM (auf die gleiche Partition) anlegen möchte und mit der 12.3 NET ISO oder der 12.3 DVD diese neue VM boote und dann aber im ersten Menue sage - von Platte booten, läuft das System immer wieder auf diesen Grub 2 Fehler auf.
.

Man nehme eine 42.3 NET ISO auf der lokalen Platte

Zeile 4 auswählen
Zeile 2 auswählen
und warten
Potz Blitz- was ist das hier
das ist meine 12.3 Version

Irgendwo hatte ich es früher bestimmt mal gelesen und es war wieder veschwunden. Doch jetzt hatte ich es - einfach durch Ausprobieren wieder entdeckt, wie es geht.

Mit der 42.3 Net ISO installiere man "scheinbar" eine neue VM auf die gleiche - nach wie vor nicht bootfähigen - 12.3 Partition und im ersten grünen Bootscreen im Auswahlmenue wähle man --- eben nicht "von Patte booten" oder "Installation" oder "Upgrade",

sondern  den unscheinbaren Eintrag Zeile 4 >>>>>>>>>>>>>>>>
.

>> "More ........"

.
Der ganz normale universelle 42.3 Installations-Kernel wird gestartet.
.

Was sich hinter dem unscheinbaren Eintrag "Boot Linux System" verbirgt

Im Prinzip war auch das wiederum ein Zufallstreffer - ein Glücktreffer, denn in dem Menue war ich noch nie und wußte auch nicht, was da abgeht.

Mit dieser Auswahl wird ein Partitions-Scan über alle in "md8" vorhandenen Sub-Partitionen gestartet, ob und welche bootfähigen Installationen auf der (oder den) Platte(n) sind.

Durch die scheinbare Neuinstallation einer VM bin ich ja bereits in einer/der noch leeren VM, aber schon auf der zukünftigenPlatte (die ich vorher ausgewählt hatte) und der gestartete Kernel 42.3 scannt alle gefundenen Partitionen durch und zeigt mir meine 12.3 Installation auf der angesprochenen VM Partition "md8" an. Das war genial, und völlig unerwartet.

Diese Opton ermöglicht also das hilfsweise Booten eines auf der Platte in /boot/ vorgefundenen Betriebessystems, als wenn es ganz normal als VM autark gestartet wäre.

Man ist sofort "drinnen". Ich erkenne natürlich auch sofort, das ist die "übergebügelte" VM vom Proliant DL380-G5 fix und fertig (bis auf das neue Netzwerk) konfiguriert, mein wichtigster www51.ipw.net. server.

Als erstes jetzt die Kernel Options auf verbose setzen und schaun, ob yast die "initrd" erzeigen kann, die das rescue nicht konnte. Ja, es geht. Dann den korrekten Bootloader schreiben, das geht auch - nach mehreren Versuchen.
.
.

Am 30.5.2020 wußte ich, wie man das fehlerhafte myloc DHCP System überlisten kann - morgens um 3.59

Nachtrag im Feb. 2022 : Die myloc DHCP Adresse kennt nur die eigenen myloc Repositories, ist also gar nicht fehlerhaft, sondern nur ganz gezielt limitiert-begrenzt. Damit soll man einfach nicht arbeiten können !!!

Ich kann also die Partition 3 (vda3) auf /vol2 im root mounten (dort wohnen meine mysql Datenbanken) und mysql starten und danach den Apache2 und mir den Status anzeigen lassen. Es funktioniert. Der Apache2 startet, mit ein paar DNS Fehlern (bislang noch kein Netzwerk) und mariadb startet auch - sogar ohne Fehler. Die opensuse Version 12.3 startet zwar noch nicht von alleine, aber sie läuft als VM.

Jetzt mit yast das statische Netzwerk der VM mit der statischen myloc Sub-IPv4  Nummer und dem Gateway samt DNS konfigurieren und die wichtige "pointopoint Zeile" in die "ifcfg-eth0" (wie das geht - steht hier) (und ganz neu - hier) - einfügen und das wars.
.
Natürlich kann diese VM nach wie vor nicht starten, denn der Bootvorgang bleibt im grub2 Loader hängen. Ich weiß aber zumindest, die VM könnte laufen, wenn sie von alleine booten könnte.
.

Den Bootloader reparieren. Eine Stroy für sich ...

Auch das war wieder eine "Try and Error" Crux. Ich hatte bereits Versuche gemacht, mit Hilfe einer VM-Installation (einer neuen VM über die alte drüber) zumindest einen rescue Modus zu starten. Dort soll man sich mit einigen "Tricks" den Zugang zum eigentlichen System auf der Partition einrichten können:

mount /dev/vda2 /mnt
mount --bind /proc /mnt/proc
mount --bind /dev /mnt/dev
chroot /mnt
grub2-install /dev/vda2

Aber das geht auch nicht - es bringt den Fehler - "kann bootloader nicht schreiben".

Also der Rescue Modus war diesmal nicht hilfreich.
.

Ein "simpler" Trick über eine quasi Neuinstallation

Darum war ich so erfreut, daß ich mit Hilfe des Umweges über die "42.3 Iso beinahe Installation" in diesen "Boot Linux System"-Modus das Betriebssystem auf der gewünschten Partition überhaupt starten konnte.

Auch dort überraschte mich, daß ich als root-User weder den MBR noch den Bootloader schreiben durfte. Das kann doch nicht sein.

Und wieder viele Versuche, die dann am Ende zum Erfolg führten. Der Bootloader Eintrag bei den Loader Options zeigte (aus der alten Version vom HP Server übernommen) bei der "Default Boot Section" auf auf "opensuse 12.3".

Das habe ich versuchsweise auf (siehe Screen-Shot) .....
.

.

geändert unsd siehe da, der "veränderte" Bootloader-Eintrag wurde angenommen und der neue Boot-Loader wurde endlich neu geschrieben und - ganz plötzlich - es funktioniert.

Glück gehabt - Die reparierte VM bootet von ganz alleine ohne Probleme.
.

Startseite -- © 2001/2022 - Copyright by Dipl.-Ing. Gert Redlich / Germany - D-65191 Wiesbaden - Telefon-Nummer - Impressum