Im Prinzip ist es ein etwas verbesserter PC mit fehlertolerantem RAM Speicher und auf Wunsch zwei gespiegelten RAID-1 Platten. Das ist also alles kein Geheimnis.

Für den Boot-Vorgang stehen zwei Alternativen zur Verfügung, der normale boot-Vorgang von der eingebauten Festplatte (oder von den gespiegelten Platten) und der rescue- boot aus dem Netzwerk mit einer debian Variante genannt "grml".

Beide Varianten lassen sich nur im Webinterface im webtropia Kunden- Management umschalten sowie dort ein Neustart initiieren.
.

Die Bezeichnung VM ("virtuel machine") steht für eine weitere zusätzliche eigenständige Betriebssystem Umgebung zusätzlich zu Ihrem bereits im RAM gebooteten debian Betriebssystem.

Mit diesem Trick können sie auf der grafischen debian VNC-Server Oberfläche den gesamten Boot- und auch den shutdown- Vorgang ihrer VM mitverfolgen.

Bei der Einrichtung solch einer VM gibt es zwei für uns sinnvolle Varianten : Starten der VM aus einer vorher lokal mit wget in ein virtuelles Verzeichnis geholten ISO Betriebssystem-Datei der unterschiedlichsten Art heraus oder starten von der eigenen lokalee Platte (sofern dort bereits etwas eingerichtet ist).

Beim initiierten Start des rescue Systems bekommt das rescue debian zwei IP Nummern zugeordnet, eine öffentliche IPV4-Nummer des Servers (die Sie von draußen auch anpingen können) und eine lokale IPV4-Nummer mit DNS Eintrag und Gateway-IP nach draußen. Damit können dann von opensuse oder von debian zum Beispiel Repositorys nachgeladen und weitere notwendige Software installiert werden.

Auch das Installations- oder boot-System einer VM bekommt über DHCP eine interne IPV4-Nummer samt Gateway nach draußen.

Beginnen wir (nochmal) mit dem debian grml rescue System :

Wird im ZKM auf der Webseite des ausgewählten Servers unter dem menüpunkt "rescue" das "Starte das rescue-System" ausgewählt /angeklickt und dann nochmal bestätigt, bekommt der root-Server einen gnadenlosen sofortigen Hardware-Reset und jetzt die alternative Boot-Reihenfolge eingestellt und holt sich vom TFTP-Server über das Netzwerk das komplette "grml"-Image in seinen RAM-Speicher. Das ist also ein virtuelles debian System ausschließlich im RAM.

Auf der Webseite bekommt man nach erfolgtem Start (und einem reload der Seite) ein Einmal-Passwort für diesen rescue-Start für den "root"-User. Dann ist man also Chef-Admin über alles auf diesem Server.

Das gestartete debian grml Image hat die Netzwerk-Hardware erkannt und konfiguriert und enthält fast alle für den Software-Service und die Reparatur wichtigen Module, so auch den "mdadm" zur Erkennung von evtl. bereits konfigurierten RAID Festplatten, dazu den midnight- commander und andere sehr gebräuchliche Hilfs-Programme.

Für allgemeine Zwecke habe ich gleich am Beginn jedweder Arbeit immer folgende Kommandos abgesetzt :
.

• apt-get update
• apt-get install joe                      (ein simpler Texteditor)
• apt remove vim                          (der funkt öfter dazwischen)
• aptitude install tightvncserver     (brauche ich für die grafische Oberfläche)
• aptitude install autocutsel          (für das Clipboard zu VNC)

weiter geht es mit dem Anlegen einer 8 GB RAM-Disk:

• mount -ttmpfs -osize=8G tmpfs /tmp          (fällt bei 32 GB kaum ins Gewicht)

.

In diese RAM-Disk kann ich jetzt jedes beliebige ISO Image einer CD oder DVD laden und damit die VM starten.

hier erst mal schaun, was an ISOs verfügbar ist - Beispiel :

repo.myloc.de/opensuse/15.4/iso/

• wget -O /tmp/image.iso - dann http oder https oder ftp .......................

als Beispiel (bitte das Nachdfolgende in einer Zeile aufrufen) :

• wget -O /tmp/image.iso repo.myloc.de/opensuse/15.4/iso/openSUSE-Leap-15.4-NET-x86_64-Current.iso

.
Es können daher sowohl die NET-Versionen (etwa 200 MB) von opensuse sein als auch die DVD-Versionen (etwa 4,5GB). Die DVD-Versionen sind aber dann sinnvoller, wenn ich eine volle Installation der DOM-0 (Host bzw. Gastgeber) oder auch einer DOM-U (einer VM bzw. eines Gastes) ohne Updates oder sonstige Extras durchziehe.
.

Bislang waren das die ganz normalen Vorbereitungen. - Das hier - die KVM Module - muß man nachinstallieren !!!
.

• apt-get update

.
(dann in einer Zeile .......)
.

• apt install qemu-kvm libvirt-clients libvirt-daemon-system bridge-utils libguestfs-tools genisoimage virtinst libosinfo-bin

.
Damit bei mir bei bereits installierten VMs garantiert nichts schief läuft (habe da schlechte Erfahrungen gemacht), starte ich diese Befehle auch noch.
.

• apt-get install mdadm    # Werkzeug zum Verwalten von RAID-Systemen
• modprobe md_mod        # RAID framework laden (RAID-Treiber)
• mdadm-startall              # Alle RAID-Systeme starten

.

Möchte ich ein opensuse ISO starten, brauche ich die grafische Konsole dieser debian VM. Der installierte "tightvncserver" muß deshalb vorher gestartet werden.
.

• tightvncserver -geometry 1600x1024

.
(ich habe mehrere große 1920x1280 LCD Monitoren, da macht diese Auflösung Sinn)

Da ich die IPV4 Nummer meines Servers bereits kenne und darüber bereits mit der putty Text-Konsole auf dem rescue Syytem drauf bin, übernehme ich diese IP-Nummer in meinen Windows VNC-Client. Der VNC-Server hat als Default-Port die Nummer 1.

Der gestartete VNC-Server auf der debian Ebene wäre daher ab sofort mit der "IP-Nummer:1" (auf  ":1" achten - das ist die notwendige Port-Nummer) erreichbar und verlangt das beim Erstaufruf vergebene Kennwort.

Ich will aber nicht die grafischer Oberfläche des rescue-Systems haben, sondern die zu startende VM. DIe VM starte ich aber mit einer anderenPortnummer, das ist bei uns die ":0".

Bei gleicher IPv4-Nummer könnte ich also sowohl auf die "grml"-Oberfläche als auch auf die zu installierende VM-Oberfläche gehen.

Den lokalen Windows- VNC-Client lade ich dann schon mal auf Vorrat auf den Bildschirm, starte ihn aber noch nicht, damit es später ganz schnell gehen kann.

So weit die Vorbereitungen für eine Installation einer VM aus einer ISO-Datei heraus.
.

Diese lange Kommando hier muß in einer durchgehende Zeile auf die Kommandozeile der putty Konsole übertragen werden.
.

• kvm -enable-kvm -hda /dev/sda -hdb /dev/sdb -m 2048 -smp cores=4 -vnc :0 -k de -cdrom /tmp/image.iso -boot d

.
Auch wenn es sich um eine oder zwei ganz neue leere Platten handelt, sollten beide Platten "sda" und "sdb" eingebunden sein.
.
2 Funktionen sind ganz wichtig.

(1) Nach dem Aufruf dieser Zeile ist diese (eine meiner beiden) putty-Konsole(n) blockiert, weil dort die VM gestart wurde. Mit "ctrl C" kann ich in dieser einen Konsole eine hängende oder verkorkste VM killen.

(2) Nach dem Aufruf dieser Zeile wird die VM sofort gestartet und das vorhandene ISO Image gebootet. Die opensuse ISOs haben fast alle einen 8 Sek. Timeout, während dessen man im Start-Menü die installation auswählen kann, also bevor versucht wird, von der lokalen Platte zu starten.
.
(3) Nach dem Absetzen des "kvm"- Befehls (siehe oben) starte ich deshalb "sofort" (so schnell wie möglich) den vorbereiteten VNC-Client und drücke eine der beiden Pfeiltasten (rauf ofer runter), damit eben kein Start von der lokalen Platte versucht wird.
.

Bei der Installation eines neueren Opensuse Systems (Leap 15.0 und höher) als Host spielt die "Bootfähigkeit" dieser allerersten Partition eine große Rolle. Daran bin ich tagelang gescheitert, wenn "uefi" ins Spiel kommt. Früher mit ganz normalem BIOS Boot war das unproblematisch.

Inzwischen ist es einfach nur noch komisch. Der neue Intel i5 Sever hat solch ein BIOS und man muß dem opensuse YAST-Installer freie Hand lassen, wie er die ersten 3 Partitionen aufteilt. Auch gleich mit einer oder mehreren gespiegelten RAID-1 Partitionen zu starten geht schief.

Ich habe notgedrungen auf der Platte "sda" eine nicht gespiegelte Installation angestossen. Dabei wurden als wirklich einzig funktionierender automatischer Vorschlag eine klitzkleine "efi-Bootpartition" ganz am Anfang der Platte mit nur 8 "MegaByte" erstellt, dann eine 1,8 TERA-BYTE große "root" Partition und dann eine 2 GB grosse swap Partition ganz am Ende der Platte.

Das ist natürlich völliger Schwachsinn - aber alle anderen von mir tagelang ausgetüfftelten Konfigurierten Varianten wurden vom Installer abgelehnt, sie seien nicht bootfähig.
.
So mit diesem Vorschlag ist zumindest die ganz normale "kleinste" Server-Installation durchgelaufen und der Server kam nach dem Abschluß der Installation und dem automatischen Restart (immer noch in der VM) wieder zum Vorschein.
.

Also innerhalb der debian VM ließ sich dieses installierte opensuse Betriebssystem mehrfach starten und runter fahren (shutdown now). Gleich nach dem ersten Start habe ich im YAST-Bootmanager alle Einträge von "quiet" und "silent" entfernt und so den Bootvorgang auf "extrem redselig" umgebaut. Nach jedem "shutdown" startet diese VM jetzt ohne weitere Eingriffe automatisch.

So kann ich wirklich Zeile für Zeile mitverfolgen, wo es evtl. hakt und stolpert. Bislang startet diese VM noch von dem vorhandenen ISO Image und nicht aus dem eigenen MBR (oder dem eigenen "root"-Verzeichnis) der Boot-Platte.

Die nächste Aufgabe war, daß die VM fehlerfrei von der lokalen Platte bootet. Dazu muß die VM komplett gelöscht / entfernt werden und eine neue VM mit anderen Parametern muß installiert werden.
.

Wenn ich in der putty-textkonsole ein "ctrl C" absetze, wird die VM gekillt. Alles ist weg. Mein opensuse ISO Image lasse ich noch in der RAM-Disk leben, falls ich es nochmal brauche.

Zur Stufe 2 der opensuse Installation starte ich eine neue KVM VM mi anderen Optionen, die ich mühsamst rausgefunde hatte.

Im Internet gefunden : How can you boot off a physical SSD/HDD/USB drive?
Jetzt Versuche, eine VM ohne ISO Image von einer Partition zu booten:

Das Kommando hat aber nur 1 Drive !!!!!!!!! - mit 2 Drives gehts (bei mir) nicht.
.

• kvm -enable-kvm -hda /dev/sda -m 2048 -smp cores=4 -vnc :0 -k de -drive file=/dev/sda1

.
Alternativ gibt es diese Zeile - weil obige Zeile nicht mit jeder Hardware funktioniert.
.

• kvm -enable-kvm -hda /dev/sda -m 2048 -smp cores=4 -vnc :0 -k de -drive  file=/dev/sda1, format=raw

.
Jedenfalls war es ein sehr mühsames Probieren aler Optionen, welche Option welche andere ausschliesst. - Irgendwann lief es auf dieser i5 Hardware mit folgendem Kommentar :

WARNING: Image format was not specified for '/dev/sda' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
WARNING: Image format was not specified for '/dev/sda1' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
kvm -enable-kvm -hda /dev/sda -m 2048 -smp cores=4 -vnc :0 -k de -drive   415,11s user 24,56s system 27% cpu 26:42,08 total

Zu beachten ist, daß jetzt an die IP Nummer für die VM als Port-Nummer ein ":0" angehängt werden muß.

Ich bin für jeden Tip dankbar, wie diese KVM Zeile korrekt aussehen sollte.
.

Da ich den Bootloader auf "geschwätzig" umgestellt hatte, konte ich mitverfolgen, wie die installierte opensuse Version - das wird der zukünftige Xen- oder KVM- HOST - einwandfrei von der lokalen Platte 1 (/dev/sda) startet. Aber wie gesagt - nur ohne RAID.

Auch das Starten habe ich zigmal probiert, weil ganz am Anfang Probleme auftauchten und der boot-Prozess stehen blieb.
.

Nachdem das Booten von Platte (testweise sogar mehrfach) funktioniert hatte, müssen aus den 1,7 Terabyte vernünftige 50 Gigabyte gemacht werden.

Das geht nur offline ohne VM - direkt aus der grml-debian VNC-Oberfläche. Dazu muß der Windows- VNC-Client mit der Portnummer ":1" gestartet werden. Die VM ist bereits abgeschaltet. Im Moment brauche ich auf RAID-1 Partitionen keine Rücksicht zu nehmen, ich bearbeite nur die Platte "sda"

Die drei ersten Partitionen haben alle eigene UUIDs, die im Bootloader und auch in der /etc/fstab/ eingetragen sind und zumindst die efi- und die root-Partition müssen ihre UUIDs behalten.

Aus diesem Grund wurde im gparted kein "Löschen", sondern ein "Verkleinern" der root-Partition beauftragt - unter Beibehaltung der UUID. Und da diese Partition kein RAID ist, geht es doch erstaunlich schnell.

Doch eine swap- Partition am Ende der 1,8 TB Platte ist totaler Unsinn. Die hatte ich gelöscht, weil die zum Booten (eigentlich) nicht notwendig wäre, dachte ich. Ich habe die 2 GB swap dann direkt an die 50 GB root Part. angehängt - natürlich mit einer neuen UUID.
.

Bislang hatte das in der VM gestartete opensuse System nur den Netzwerkzugang von drinnen nach draußen über das webtropia DHCP mit deren Gateway. Über meine webtropia Server- IPV4-Nummer ist jedoch das rescue-System auf dem Server zu erreichen und das hatte ja auch funktioniert. Das opensuse- System kann ich zwar in der VM konfigurieren - aber von außen nicht erreichen und somit auch nicht weiter prüfen.

Dennoch kann ich dem installierten und in der VM gestarteten opensuse- System jetzt schon die zukünftigen Netzwerk-Daten eintragen. Das sind die eigene IP-Nummer, die Gateway-IP und mindestens eine DNS Server-IP. Jetzt kann diese Installation nicht mehr nach draußen schaun, weil diese Konstellation nicht geroutet wird. Es kollidiert aber auch nichts, denn die diese IP-Nummer wird zur Zeit vom rescue- System benutzt.
.

Die in der einen putty-Konsole laufende VM kann ich nach dem korrekten "shutdown now" von opensuse abschalten und auf der ZKM Webseite den rescue- Modus beenden. Dabei wird aber noch kein "reboot" oder "restart" ausgeführt. Es wird nur die boot-Modalität auf normal oder Standard umgestellt.

Aufgrund bitterer Erfahrung sollten jetzt unbedingt und zuerst alle Platten-Partitionen "umounted" werden, damit beim "restart" dort nichts kaputt geht - wie bei mir. Das Booten des opensuse Systems von der lokalen Platte hatte ich vielfach erfolgreich ausprobiert und ich war mir sicher, daß es jetzt auch direkt von der Platte ohne VM (in einer akzeptablen Zeit von weniger als 1 Minute) funktioniert.
.

Schlimmer war, weder ein Restart über das ZKM- Web-Server-Management noch die gewaltsame "Heimkehr" in den rescue-Modus funktionierten. Der Server war über Stunden einfach weg (von draußen unsichtbar verschwunden oder beschäftigt). Doch ganz erstaunlich - der zufällig entdeckte "Ctrl-alt-del"-Knopf auf der Lantronix Monitor-Oberfläche ganz ganz oben links inder Ecke - der funktionierte. Dieser Button initiierte endlich einen Restart, wie wir ihn von jedem PC gewohnt sind. Warum die andern "reset"-Methoden nicht gingen oder gehen, bleibt unklar.
.

Als endlich der rescue-Modus wieder lief (jetzt ar auch die IP-Nummer wieder online zu sehen), habe ich dort die root-Partition der opensuse Installation gemountet und in der boot Config wie auch in der /etc/fstab diese UUIDs komplett gegen die logischen Devices ausgetauscht.
Damit reduzierte sich später der timeout beim Start von der Platte auf gerade noch akzeptable 1,5 Minuten.
.

In der 8 Woche, als es dann so langsam funktionierte, habe ich nur noch kurze Notizen gemacht, die ich gerade suche.

Wie gesagt, ein paar Themen fehlen noch.

.