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.
.

.

• "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.)
.

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.
.

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.
.

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.
.

.

• 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.
.

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

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.

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.
.

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.
.

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

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.
.
.

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.
.

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.
.