Im Sommer/Herbst 2016 überschlugen sich die Angebote im Server-Markt bezüglich root-Servern und eines stach dabei hervor, das war die Firma Hetzner aus Nürnberg, auch wegen des mehrfach gelobten Services.

Angeboten wurde ein PX61 standard dedicatetd "root"-Server (vermutlich Fujitsu/Siemens 1HE) mit einer Intel quadcore CPU mit 4 x 3,6 GHz, sowie gewaltigen 64 !! Gigabyte ECC-RAM und sogar zwei 2 Terrabyte Enterprise Platten gespiegelt. Auf Nachfrage hieß es, so gut wie alle handelsüblichen Distributionen im Bereich Linux seien verfügbar, opensuse oder SLES12 auf jeden Fall. Auf weitere Nachfrage nach der 13.2 (weil die hier auf meinen Servern klaglos läuft) hieß es, ja, auch dafür gibt es ein Installations-Image. Da ich seit suse 10 alle opensuse ISO-images auf meinem Data-NAS drauf habe, dachte ich an nichts Böses oder Ungewohntes. Es sind aber ganz spezielle und auf das Wesentliche abgeänderte Hetzner Images. Das ist sinnvoll und das muß man (im Vorhinein) wissen.

Weiterhin : Die beiden angebotenen 2TB SATA Platten sind inzwischen sogar jeweils 4 Terrabyte groß, ich brauche aber nicht mal 500 Giga. Eine IPV4 Nummer ist immer dabei, weitere IPV4 Nummern (zum Beispiel ein "/29er" Netz für 8 Euro/Monat) sind gegen Aufpreis verfügbar. So weit klingt das alles sehr vernünftig und preislich überaus attraktiv.
.

Bei den HP DL385er Profi-Servern gibt es das (seit 1999 von Compaq auf deren DL380er Servern eingeführte und danach ziemlich ausgereifte) "iLO", sie nannten und nennen es "integrated lights-out". Eigentlich ist es nichts weiter als eine sehr komfortable Remote-Console over Ethernet. Daß da Java im Browser "required" ist, um sich die echte Server-Console (also eine putty Console) zu holen, muß man akzeptieren.

Jedenfalls hat es mir seit den DL-385-G2 Servern das Leben enorm erleichtert. Ich war manches Jahr überhaupt nicht mehr im Server-Keller meines Housing- Partners. Alle Funktionen direkt am Server gehen jetzt vom Bürosessel aus. Auch das (Nach-) Installieren zum Beispiel der DOM-0 von der im DVD-Laufwerk eingelegten (und dann jeweils bei Bedarf aktivierten) opensuse 13.2 NET CD geht vom Bürosessel aus. Soweit also der seit sieben Jahren gewohnte Standard.

Bei Hetzner gibt es soetwas Ähnliches wie "iLO" mit Namen "LARA", das man für 3 Stunden (kostenfrei) zugeordnet bekommen kann. Und da ich meine lokalen Test-Installationen in jeweils ca. 1,5 Stunde über DSL fertig hatte, ist das sehr entgegenkommend und für eine simple XEN Basis-Installation in der Regel vollkommen ausreichend. Übrigens gehen die Hetzner opensuse Mirror-Server über das interne Gigabit Netzwerk extrem schnell. Eine opensuse Installation dürfte damit keine 20 Minuten dauern, eventuell samt allen (von mir gar nicht gebrauchten) Gnome und KDE Grafikmoduln usw. - die ich sowieso nicht installiere.
.

Da ich unsere Server seit 1997 unter suse mit YAST verwalte und programmiere, denke ich natürlich erstmal nicht an irgendwelche Fallstricke. Bislang hatte jede Migration von alter Hardware zu neuer Hardware mit mehr oder weniger vielen Nachtstunden erfolgreich funktioniert. Der Anfang mit den virtuellen XEN Maschinen in 2009 war sicher mühsam, aber das ist jetzt viele Jahre her. Hilfreich war, daß ich in einem eigenen ganzen Class C Netz mit 254 Adressen schalten und walten konnte, wie es erforderlich bzw. sinnvoll war.
.
Mit der gemachten Erfahrung müssten für die Zukunft insgesamt 1 + 6 IPV4 Adressen (also ein zusätzliches /29er Netz) ausreichen. So, wie ich aus ehemals von über 48 Einzelservern in 1997 die immer besser und leistungsfähiger gewordene Hardware von HP/Compaq immer weiter verdichtet hatte, so kann es mit den Virtuellen Maschinen (den DOM-Us) unter XEN auch werden.

Daß in meiner Umgebung immer ein DHCP Server zur Verfügung steht, ist selbstredend. Sonst kann man mit dem virt-manager kein DOM-U Betriebssystem installieren. Davon war ich natürlich von einem Housing- und Hosting-Profi wie Hetzner ausgegangen. Fehlanzeige. Die vorkonfigurierten Hetzner Images holen sich die zugewiesene Haupt-IP Nummer (vermutlich) für die Hypervisor Installation aus dem Accounting System und bieten ein ganz simples Text-Script an, das man auch leicht abändern kann. Kling gut und ist auch verständlich, denn das macht man sonst ja auch, nur macht man das eben mit einer deutlich übersichtlicheren und umfangreicheren grafischen YAST2 Oberfläche - und das bei mir seit über 10 Jahren.
.

Nach den leicht verunglückten opensue 12.1 und .2 und .3 Versionen (und einem totalen Einbruch der Neuinstallationen sowie der Nutzerzahlen) muß es dort im suse Laden (damals noch bei NOVELL) ganz schön gekracht haben. Die suse Sparte bei Novell wurde dann ja weiter verkauft und auf einmal gab es mit der Version 13.1 eine ganz neu gestaltete, schnelle und ordentlich logisch sauber konstruierte Installations-Prozedur - erfreulich einfach und vorbildlich = mustergültig. Davon ist bei dem Hetzner-Image der opensuse Version 13.2 (und auch bei 42.1) nicht viel übrig geblieben. Man muß da etwas in Richtung EDV-Steinzeit umlernen, jedenfalls wenn man (noch) nicht weiß, wie es auch anders (über VNC) geht.

Der Plan :
Ich will also eine XEN DOM-0 Umgebung (also den Hypervisor bzw. das XEN Basis-System) wie folgt haben. Das hatte ich bei mir im Büro sogar mehrfach ausprobiert - extra auf 2 gespiegelten Terrabyte Platten. Und dann erstmal nur die DOM0 hochfahren.

Dazu brauche ich
(1.) 4 Giga "swap",
(2.) 512 Mega für /boot wegen der gespiegelten großen LVM Platten und
(3.) 20 Giga für das root-System ("/").

Das wären jetzt 3 Primärpartitionen und die obige Reihefolge ist wichtig. Die dann sehr große vierte (erweiterte) Partion würde ich aus dem laufenden XEN-Grundsystem (DOM0) heraus anlegen und aufteilen. Ich weiß von meinen Versuchen hier auch, daß das neue boot-System nur noch mit grub2 sauber startet.
.

Mit dem Begriff "rescue" verbindet sich ein fertig erstelltes Boot-Image, das direkt in den RAM Speicher des Servers geladen wird. Die Platte bzw. die Platten werden dabei überhaupt nicht angefaßt. Das kommt erst viel später.
.

In der Hetzner (Verwaltungs-) Weboberfläche kann man das Rescue-Betriebsstem über den Server bzw. dessen aktuelle Installation "drüberbügeln" lassen. Nachtrag : Das war von der Denke her falsch, denn auf die Platte wird ja erstmal gar nichts geschrieben.UNd das rescue System wohnt nur im Speicher, egal, was bislang auf die Platte geschrieben wurde.

Nichts von der alten Installation, die ja meist nicht funktioniert hatte, bleibt übrig, (stimmt so gar nicht, das war ein Denkfehler von mir). Dann kommt ein "Reset" ebenfalls per Weboberfläche und der Rescue-Urzustand ist wieder da. Wenn man nicht aufpasst, ist das zwar gefährlich, (das stimmt auch nicht, denn die Partitionen müssten danach erstmal von hand gemounted werden) und es wird mehrfach abgefragt . Das geht übrigens sehr schön schnell und sieht dann auf dem Bildschirm so aus
.

1. Das Rescue-System wurde erfolgreich aktiviert.
2. Beim nächsten Neustart Ihres Servers wird dieser im Rescue-System hochfahren.
3. Sie können sich auf Ihrem Server als User "root" mit dem folgenden Passwort anmelden: rh3P...12345 (Anmerkung : das hier ist wichtig und das muß man sich unbedingt merken/abspeichern !!!!)
4. Der Reset-Auftrag wurde soeben versendet.

.
um 18.oo Uhr ---- Der Server ist wieder da - im Rescue-Modus und antwortet auch. Sodann das Hetzner config file nochmals korrekt editiert und alle Kommentare entfernt und nochmals kontrolliert und abgespeichert und den Editor verlassen. Die Installation von Hetzner opensuse 13.2 beginnt erneut.

Der (software-) reboot dauert wieder etwas lange - der Server kommt jedoch wieder nicht mehr hoch ??
.

Wieder Rescue aktivieren - das neue Zufalls-Passwort abspeichern und reboot fahren.

Im Config File erneut alle Kommentare entfernen, nur die vorhandenen Beispiel-Zeilen - das sind die ohne LVM - nochmals anpassen und wieder kommt der neue opensuse 13.2 Server nicht hoch. Das wars also nicht.
.

Nach e-mail Rücksprache mit dem Support, es war bereits nach 22.oo Uhr, solle ich doch mal gar nichts an der config ändern. Gesagt - getan, Rescue aktiviert, reboot abgesetzt und neu per puttty eingeloggt und installimage angeworfen.

Der Server kommt wieder nicht mehr hoch.

Der Supporter (nach 24 Uhr) mailte mir dann aber, daß die opensuse 13.2 nicht mehr unterstützt würde. Aber er würde mir die LARA remote console für 3 Stunden aktivieren und ich könne damit ein ISO CD Image nach eigener Wahl installieren.

(Später hatte mir ein Kollege vom Support dann gesagt, daß die opensue 13.2 die Netzwerkkarte dieses Server noch nicht kennt. Doch wir sprechen hier von ein einem speziellen Hetzner Boot-Image, bei dem man diesen Treiber hätte einbinden können - besser gesagt einbinden sollen.)
.

Ich habe auf der Web-Oberfläche wieder Rescue aktiviert, reboot abgesetzt und mich neu per ssh-puttty eingeloggt und "installimage" angeworfen.

Gleichzeitig habe ich mir auf einem Notebook die LARA Console geholt, weil dafür Java notwendig ist, das ich auf keinem meiner Workstations haben möchte.

Dort konnte ich - wie bei iLO - mitverfolgen, was da passiert. Es funktioniert nicht, weil die Dracut Emergency Shell die Platten nicht mehr erkennt und damit startet auch kein opensuse von der lokalen Platte.

Ganz kurz danach tauchten jede Menge "memory errors", "segmentation faults" auf und das wars dann. LARA ist abgestürzt. Ich hatte dem nächtlichen Supporter noch gemailt, daß er sich doch bitte die LARA Console (meines Servers) holen möge und sich die Speicherfehler mal ansehen möchte. Das ginge nicht, wenn er sich per LARA auf meinem Server einloggt, seien alle Screens leer oder unsichtbar oder so ähnlich. Da das auf dem Notebook ablief, war dort keine Screenshot Software vorbereitet.
.

Wieder Rescue und reboot usw. Und damit gar keine Diskussion aufkommt, gleich mal die default config der opensuse 42.1 einfach nur durchlaufen lassen und mal sehen, was da passiert. Und siehe da - oh Wunder - der Server kam wieder hoch. Jetzt zwar mit einer 2 Terrabyte oder noch größeren root Partition, aber unter 42.1 hat dieses ISO Image die Plattenkonfiguration automatisch erfolgreich erkannt und eingeklinkt. Radio Eriwan - im Prinzip funktioniert es. Sodann gleich wieder Rescue aktiviert und ein reboot abgesetzt zum 7. Versuch.
.

Bei der zweiten Installation jetzt von opensuse 42.1 (Hetzner ISO Image) habe ich wieder - wie ganz zu Anfang - die DOM-0 Partition ganz klein konfiguriert :

Dazu brauche ich
.

1. 4G swap
2. 512M für boot
3. 20G für xen root

.
Auch das hat jetzt funktioniert, und das mit absolut den gleichen Einstellungen wie bei der allerersten Änderung der opensuse Version 13.2 Konfiguration im Versuch 1, also alles Default und ohne !!! LVM, es waren genau die (bei mir jeweils protokollierten) Zeilen - wie der Vorschlag dort im Versuch 1.
.

Jetzt wird das Rad der Zeit kräftig zurückgedreht. Was mit der original opensuse 13.2 Net CD oder der 42.1 NET CD und der grafischen YAST2 Installations-Prozedur nur ein paar Klicks bedeutet, dauert hier Stunden um Stunden, weil immer wieder etwas fehlt oder eine Dependancy falsch ist oder fehlt oder eine Lib-Version zu hoch oder zu niedrig ist.
.

Solch eine Installation - sowohl mit der opensuse 13.2 NET CD wie auch der fast baugleichen 42.1 NET CD Prozedur - dauert hier bei mir im Büro ca. 1,5 Stunden, ich habe halt nur DSL 50.000 und die Masse der Programme wird aus dem jeweiligen online Repository von suse geholt. Die meiste Zeit bin ich am Teetrinken und Warten.

Ich installiere (per Klick in der Config) bereits ganz am Anfang also XEN, XEN-tools, X11, Tiger-VNC und icewm per (Initial-) Klick, aktiviere Firewall und ssh und dann gehts wirklich sofort los. Etwa 1,7 Giagbyte werden aus den Repositories geladen und dann geht aber alles, wirklich alles - "like a charm".

Darum hatte ich ja vorher alles bis zum Exzess ausprobiert/geübt, damit es auf dem neuen root-Server auf Anhieb funktioniert. Den ganzen Salmon hatte ich ja ganz bewußt 3 mal (2 x 13.2 und dann nochmal mit der 42.1) auf 3 Server-PCs installiert, um zu wissen, ob ich mich vielleicht doch zu blöd anstelle.
.

Ich installiere also per yast (oder auch per zypper) XEN und die XEN-Tools und möchte nichts weiter, als daß der Server jetzt mit dem XEN Kernel startet. Doch falsch gedacht. Der XEN Kernel wird im grub2 bootmamager gar nicht angezeigt ?? Warum nur ? Weiterhin kann YAST den grub2 bootloader nicht (mehr) abspeichern. Es sei ein Fehler aufgetaucht. Das hatte ich noch nie. Meine nächtliche Begeisterung kennt keine Grenzen.
.

Nach stundenlangem Suchen - ein Tip in den debian !!!! Foren ist gold wert, nämlich den "grub-customizer" installieren. (Suchen Sie nach : openSUSE_Leap_42.1/x86_64/grub-customizer-4.0.6-6.2.x86_64.rpm)

Der zeige den aufgetretenen Fehler an, der dann zu bereinigen wäre. Doch der läuft nur unter einer grafischen Oberfläche mit VNC. VNC läuft, aber icewm und X11 vermissen irgend etwas. Auch yast2 kommt hier auf der Hetzner Installation nicht grafisch hoch.

Nach vielem Suchen und Testinstallieren von diversen Zusätzen läuft der Grafik-Modus endlich und der "grub-customizer" sagt:

Ein Fehler hatte sich in /etc/default/grub in Zeile 9 eingeschlichen, dort stand eine leere Variable ohne Inhalt, über die sowohl yast als auch der grub-customizer gestolpert waren. Das hätte ich nie gefunden und nie zum Laufen bekommen, auch der Support von Hetzner nicht. Wie kommt diese Zeile da rein ? In keinem meiner 3 Muster- und Test-Server ist soetwas aufgetreten. Damit war die halbe Nacht wieder mal rum. Habe sodann meine beiden 42.1 Testserver untersucht und dort diese Zeile nicht gefunden, dafür andere Zeilen, die bei der Hetzner Installation nicht drinnen stehen.
.

Wie ich gelesen hatte, ist im XEN Kernel automatisch der LVM Treiber enthalten, damit ich in der nun folgenden 3,7 TB großen (erweiterten) Partitionen die logischen Partitionen anlegen kann. Der XEN Kernel bootet zwar - mit Fehlern -, aber "libvirt" startet nicht. Damit kann ich den "virt-manager" nicht starten. Beim künstlichen Start von libvirt (also "unerfolgreich" gestartet = dead) kommen mehrere Fehler, die aber nichts aussagen.

In einem anderen XEN-Forum hat jemand vorgeschlagen, qemu auf der DOM0 zu deinstallieren, dann dort auch apamor zu deinstallieren und dann qemu wieder zu installieren und zu starten. Das hatte aber auf meinen anderen 3 Servern alles ohne diese Tricks problemlos funktioniert. Darum kam ich auf solche verqueren Konstrukte nicht. Gesagt - getan, das hatte funktioniert.

Endlich läßt sich libvirt (und damit später auch der virt-manager) auf dem XEN Grundsystem fehlerfei und dauerhaft starten.
.

Auch das ist nicht trivial. Die ersten 3 primären Partitionen hat der Partitionierer alle als RAID1 Platten agelegt. Das müssen Sie bei der sehr großen "erweiterten Partition" jetzt von Hand machen. Ist ja auch ok so, nur, Yast kann es nicht, weil der MBR fehlt. Dazu brauchen Sie "gparted". gparted schlägt als MBR Version "MSDOS" oder "GPT" vor. Sie brauchen "GPT", wenn der gesamte Rest der Platte mit mehr als 2 Terrabyte genutzt werden soll. (Der Rest der Platte wäre dann auf ewig unbenutzbar.)

Selbstverständlich kann man mal einen ersten Test mit der MBR Version und damit nur 1,9 Terrabyte machen. Die beiden Partitionen müssen aber jetzt mit "YAST" erstmal zu einem RAID 1 zusamengebaut werden. Das kann "gparted" nicht, das kann wieder nur "YAST".

Jetzt erst können Sie (für die späteren virtuellen Maschinen) viele kleine unformatierte 60 und 20 Gigabyte (logische) RAW-Paritionen in dieser erweiterten RAID 1 Partition erstellen. - Jedenfalls so funktionert es bei mir auf den Testmaschinen.
.

Wie gesagt, der VNC-Server stellt eine grafische Fernkonsole zur Verfügung, doch die notwendigen wenigen grafischen Programme, es sind nur die unter YAST und der gparted müssen alle Bibliotheken vorfinden.

Der virt-manager startet jetzt und man könnte die erste VM versuchen. Aber jetzt kommen die Kleinigkeiten, die völlig ungewohnt das Leben schwer machen. Es gibt keinen temporären DHCP Server. Den braucht man unbedingt, weil man sonst bei der Installation aus der grafischen YAST2 Oberfläche rausfliegt. Und dann braucht man auch kein suse, sondern kann sich mit debian oder redhat rumquälen.

Doch zur Nutzung des zusätzlichen "/29er" Netzes gibt es (nach längerem Suchen) eine ellenlange (debian konforme) Hetzner-Wiki- XEN-Seite, auf der die Installation von diversen Bridges auf der DOM-0 pro zugeordneter IP beschrieben wird, weil alle IP Nummern des Zusatznetzes erst mal auf die Haupt IP geroutet werden. Dort müsste man sie selbst weiterrouten. Dann könne man sich einen DHCP Server selbst anlegen und sich selbst versorgen.

Doch das ist nicht professionell, das ist Bastelkram für Hobbyprogrammierer.

Die opensuse YAST2 Installation ist darauf ausgelegt, einen DHCP Call erfolgreich abzusetzen und dann (s)ein Linux System komfortabel vorzukonfigurieren und dann aus diversen online-Repositories aufzusetzen.
.
Also das mit dem Installieren der virtuellen Maschinen, den VMs, das bei mir auf den Testmaschinen virtuos und in einem Rutsch geklappt hatte, geht hier auf der Hetzner Installation nicht.
.

Und das war es nicht wert. Da kann das Mieten eines root-Servers noch so preiswert sein, wenn das Drumherum entweder gar nicht stimmt oder so komplex ist, daß man das Ganze nach wenigen Wochen nicht mehr nachvollziehen kann.

Ich setze in einer professionellen Hosting/Housing "root-Server" Umgebung einen DHCP Server einfach voraus.

Des weiteren gehe ich von einer ganz normale Verfügbarkeit der IP Adressen in dem physikalischen Netzwerkstrang aus (das wäre der entsprechende Routerport), in dem der physikalische root-server mit der Haupt-IP-Nummer steht. (Ich habe über 10 Jahre lang unsere Ciso 7500 und 7200er Router betreut und konfiguriert.)

Eigentlich sind es ganz wenige Ecken und Haken, an denen es mangelt. Und dann sollte man zur Erstinstallation gleich die Fernkonsole angeboten bekommen, um ein ganz normales opensuse Standard ISO Image (also ein NET Image) auf der Basis des grafischen YAST2 Konzeptes zu installieren. Und das sollten die Hetzner Mitarbeiter selbst mal ausprobieren. Es ist ein Unding, daß LARA bei der Installation von opensuse 13.2 NET mit Memory Fehlern abstürzt.

Und damit ist die Hetzner root-Server Umgebung vorerst nicht profesionell brauchbar.

Stand vom 5.11.2016.
.

Auf meinem lokalen 42.1 Musterserver sind jetzt 2,4 GB von 20 GB belegt, weil ich es "out of the box" von der 42.1 NET CD (ist nur 90 MB groß) installiert hatte. Auf dem Hetzner-Server sind jetzt ca 4.5 GB von 20 GB belegt mit jeder Menge Test-Müll, damit es irgendwie zum Laufen kommt. Ich weiß auch nicht, was ich weglöschen darf bzw. sollte, um wieder ein schlankes System zu bekommen.
.
Um die Mühe der Hetzner Supporter zu honorieren, die haben diesen Text ja komplett durchgelesen, werde ich nochmal einen Neu-Versuch starten.
.

.

Die nächtlichen Rechtschreibfehler werden in Kürze beseitigt.
.