Darum beschreibe ich hier den letzten Hoffnungslauf bei Hetzner, also, wie die Supporter die Installation des XEN Grundsystems (den Hypervisor) DOM-0 vorschlagen: (die Vorgeschichte steht hier.)
.

Der Support schreibt :

* Grafische YAST Installation kann über das Menü VNC gestartet werden.
https://wiki.hetzner.de/index.php/VNC-Installationen

* Minimal Images vs. NET CD
-> unsere Images sind bewusst minimal gehalten, um möglichst wenig Angriffsfläche zu bieten. So ist auch eine grafische Oberfläche nicht standardmäßig enthalten, da die Administration der Systeme in der Regel via SSH bzw. Putty erfolgt.
.
Und das probiere ich jetzt aus:
.

Weiter oben sammle ich die Hetzner-WIKI Einträge und die e-mail Vorschläge des Suports zusammen und probiere das dann aus, bevor ich "die Flinte ins Korn werfe". Den so leicht gebe ich ja nicht auf.
.
Und zuvor sichere ich den gesamten "/etc/" und /boot/ Bereich zu mir lokal auf mein NAS ins Büro nach Wiesbaden .
.
Also, wie bereits vielfach geübt, das Rescue-System aktivieren, das jeweils neue Passwort vom Bildschirm ab-protokolliert und ein "reboot" starten. Wie auch immer, das hatte ich aber so gar nicht gebraucht - ich soll doch das mit dem VNC probieren - siehe nächsten Absatz.
.

Auf der Hetzner Server- Web-Oberfläche für den einzelnen root-Server gibt es einen VNC Tab, den man sehr leicht "verkennt". Dabei wird dort mit einem Klick ein rudimentäres opensuse Startimage samt VNC Zugang funktionsfähig ins RAM expandiert und die ganz normale grafische YAST2 Installationsroutine aufgerufen. Weiterhin gibt es ein VNC root Passwort, mit dem man mit einem VNC Client (Viewer) auf die Konsole des Servers kommt.
.
Die Installation kann beginnen, wirklich wie bei der Installation einer lokalen opensuse- Net-CD direkt an dem PC-Bildschirm des Servers.
.

Dieses grafische VNC Feature - also der VNC Server - geht (bei Hetzner über das Webinterface) nur mit opensuse und centOS und fedora, aber Hauptsache, das geht mit opensuse.

Die Installation läuft wie gewohnt ganz normal ab, beide als RAID1 gespiegelte 4TB Festplatten sind (jedenfalls bei mir hier) bereits leidlich vorkonfiguriert wegen der vielen vorherigen (unerfolgreichen) Versuche, man könnte es aber auch von Grund auf nachholen.

Die drei primären RAID Partitionen sind also bereits vorhanden und müssen nur neu zugeordnet werden. YAST2 schlägt da wieder etwas "Krummes" vor, das ich so nicht haben möchte. Ich möchte

(1) 4GB swap,
(2) 500MB für /boot und
(3) 20 Giga für den XEN Hypervisor, die DOM-0 haben.
.

Der Hetzner opensuse Mirror ist offensichtlich über 1 Gigabit/s angebunden und wird nicht gebremst. Es geht innerhalb des Hetzner RZ wirklich gut ab. Ich spezifiziere bei der Softwareauswahl - wie immer bei der DOM-0 - zusätzlich das minimale X-Window System sowie die XEN Hostserver-Module. Das wären dann etwa 2,3 Gigabyte an opensuse Download.

Die Netzwerk Konfiguration geht wie von selbst und die Server-IP wird über ein spezielles DHCP Konzept abgerufen und einer einzigen (Haupt-) IP-Nummer zugeordnet, samt der Netmaske, der Gateway- Adresse und sogar drei DNS Servern.

Auch der Standard-Bootloader (noch ohne XEN) sowie das initrd Bootimage werden generiert und (diesmal fehlerfrei) gespeichert und dann kommt der erste (automatische Neustart) Reboot.
.

Der Server kommt klaglos (und schnell) wieder hoch und bekommt gleich noch etwas mehr Software installiert. Zuerst wird "zypper up" aufgerufen, um das gesamte System auf den neuesten Stand zu bringen, das kommt jetzt von einem externen Suse Server und dauert daher etwas länger (480 MB).

Aus Erfahrung gibts noch etwas mehr an Software,

den grub-customizer,
den File-Zilla samt seiner Module und
den file-roller, die XEN-Tools und
den XEN-Hypervisor und
noch ein paar Verschönerungen in /etc/profile.local.
.

Und das ist auch wieder nicht so einfach. Für den XEN Hypervisor habe ich bereits 3 primäre Partitionen vergeben. Es gibt ja auch auf den Servern sowieso nur 4 Partitionen, davon sind 3 x Primary und 1 mal Extended.

Die 4. (erweiterte) Partition soll damit die gesamte restliche Platte (für die späteren virtuellen Maschinen) überspannen und der DOS MBR verträgt maximal 2 TB. Also muß ein alternativer MBR her, der "GPT" und den bekommen wir am schnellsten (oder nur) mit dem "gparted" auf diesen Teil der Platte.

Alles sehr komplex, aber mit "gparted" funktioniert es am schnellsten, mit dem YAST2 "Partitioner" nicht so komfortabel. Danach kann ich aber mit YAST2 diese große erweiterte Partition in kleine 60GB Parts aufteilen, alles unformatierte RAW Partitionen. Und es funktioniert. (Die Installation der Software RAIDs geht wiederum nur mit YAST2, nicht mit gparted.)

So weit so gut. Der Server läuft und ich komme mit VNC auf alle grafischen Hilfsprogramme drauf. Jetzt brauche ich für die Installation der ersten VM temporär einen aktiven DHCP Server und eine temporäre IP Nummer entweder aus den zusätzlichen IPV4 Adressen oder aus dem Hetzner Pool.
.

Was im ganz normalen Hosting- oder Rechenzentrum seit 20 Jahren völlig normal ist, ist hier gänzlich anders. Die Haupt-IP wird sowieso dem Ethernet-Port am physikalischen Server zwangsweise zugeordnet.

Aber alle weiteren zusätzlichen IP-Adressen werden bei Hetzner dann auf diese Haupt-IP geroutet, ohne Wenn und Aber. - Will man diese zusätzlichen IPs verwenden, muß (bzw.müsste) man auf der Hypervisor- Ebene diverse Bridges und/oder statische Routen erstellen.

Was also bei uns seit 20 Jahren extrem simpel und verständlich ist, einfach und vor allem sehr übersichtlich pflegbar, (wir brauchen soetwas Komplexes alles nicht), - ist hier ein komplexes Gebilde aus Routen und Bridges.

Nach meiner Erfahrung hat man bereits nach 4 Wochen den Überblick verloren, warum welche IP wohin geroutet worden war und vor allem, wenn es gekracht hat, warum es auf einmal nicht mehr geht. Bei der kleinsten Veränderung oder Ergänzung einer IP Adresse oder aber eine "Mißkonfiguration" im Netzwerkbereich des Hypervisors muß das dortige Netzwerk neu gestartet werden, - und warum auch immer - ist immer wieder das Netzwerk down und dann kommt der Hypervisor nicht mehr hoch und der ganze Server mit allen seinen virtuellen Masachinen ist damit platt.

Dann geht die ganze Sucherei von vorne los, im offline Modus natürlich, Rescue System anklicken - Passwort merken, Reset anklicken - alles zum Glück mit einem zwar recht gut funktionierenden Rescue System (nämlich nur im RAM). Doch es ist extrem mühselig.

Facit : Diese Tricks und Workarounds mit den zusätzlichen IP-Nummern haben im Hypervisor absolut nichts zu suchen.
.

Das ganze Konzept der XEN Virtualisierung ist ja, daß ich um keinen Preis der Welt den Hypervisor irgendwo irgendwie anfassen muß oder gar herunter fahren und neu starten muß, wenn ich einzelne VMs erstellen oder konfigurieren oder migrieren will oder muß.

Der Hypervisor (nach dem der Hetzner Vorschlag) als Routing-Bridge für die VMs ist ein anfälliges Wackelgebilde bzw. eine Krampflösung, die das XEN-Konzept von Grund auf kontakariert.

Ganz allgemein bedingt das Virtualisierungs-Konzept die absolute Stabilität des Hypervisors - also der DOM-0 - ohne Wenn und Aber

Der Hypervisor (die unterste Linux-Platform auf der DOM-0) bekommt ausschließlich seine eigene Server-IP, eine Gateway-IP und eine Netzmaske. Ich brauche nicht mal irgendwelche DNS Server-Einträge.

Damit ist der Hypervisor völlig autark und läuft auch dann noch, wenn die VMs der Reihe nach abstürzen würden oder sollten. Die einzelnen VMs sind bezüglich ihrer eigenen IP (und der entsprechenden Gateway-IP) auch autark. Instaliert werden die VMs aus dem "virt-manager" heraus mit einer temporären DHCP Adresse (die also verfügbar sein muß) und die wird natürlich sofort nach der (erfolgreichen) Installation in eine statische IP umgewandelt.
.

Natürlich habe ich rein aus Ehrgeiz versucht, dieses Routing-Modell oder das Bridging-Modell auf Basis der Vorlagen im Hetzner-Wiki sowie der Supportkollegen mal testweise nachzubauen. (Wer gibt denn gleich auf ?)

Doch die Wiki-Vorlagen sind mit der opensuse 42.1 nicht zu realisieren. Jeweils nach dem Neustart der Netzwerk-Umgebung ist der Server dann im Nirwana verschwunden und mußte per Rescue-System wieder "repariert" werden. Weder per YAST2 noch händisch ist es mir bei mindestens 5 Versuchen (das waren Versuch 9 bis Versuch 14) gelungen, auch nur mal eine einzige zusätzliche IP Adresse zu aktivieren.

Die Netzwerk-Konfiguration der DOM-0 mit oder ohne YAST ist bei Leap 42.1 also empfindlich und instabil und das ist für eine geplante Produktions-Umgebung nicht akzeptabel. Auf unseren HP-DL385er Servern habe ich unter opensuse 12.3 sogar 4 Netzwerkschnittstellen (eth0 bis eth3) mit 4 Bridges (br-0 bis br-3) den verschiedenen VMs zur Verfügung gestellt. Das klappt leidlich, weil man dabei schon sehr genau aufpassen muß, ist aber heutzutage bei einer Gigabit Anbindung (für uns) nicht mehr notwendig.
.

Davon sind ganz normal nur 6 IP-Nummern nutzbar, die erste Nummer und die letzte Nummer (jedweder IP-Netze und Subnetze - mehr steht hier) sind nicht nutzbar. Das ist bekannt und das muß man akzeptieren.

Mit Stand vom 6.12.2016 habe ich jetzt bei Hetzner angefragt, ob es ein ganz normales Routing dieses 8er IP-Subnetzes in diesen Netzwerk-Strang (oder das virtuelle Netz meines Servers) gibt oder nicht. Damit steht und fällt die Nutzung dieses Root-Servers als Basis von virtuellen Maschinen unter opensuse.
.

Nach einem letzten Versuch, die zusätzlichen 6 IP-Nummern auf den physikalischen Netzwerk-Port (und nicht auf die IP Nummer) geroutet zu bekommen, habe ich die Notbremse gezogen und bin von diesem Miet-Vertrag zurückgetreten. -  Und Hetzner hat bezüglich Verfügbarkeit und Geschwindigkeit - und auch bezüglich Support - wirklich gute Referenzen.

Den alternativen Serveranbieter hatte ich inzwischen vorab mit den entsprechenden Fragen beschäftigt, nachdem ich jetzt weiß, was bei der Virtualisierung von Servern die wichtigen unabdingbaren Eigenschaften sind.

Ich muß natürlich eingestehen, daß ich mir über solche Tricks und Workarounds wie jetzt hier bei Hetzner nie Gedanken zu machen brauchte, weil ich ja seit fast 20 Jahren ein ganzes Class C Netz mit 255 Adressen zur Verfügung habe. Auf solche Ideen bin ich dabei gar nicht gekommen.

Auch bei den Gesprächen mit Server-Admins großer Konzerne mit hunderten von Servern - über mehrere Länder verteilt - sind mir solche IPV4 Adress-Routing- Tricks auf Hypervisor- Ebene nie zu Ohren gekommen.
.

Es sehr schade, daß das bei Hetzner mit einem virtualisierten opensuse Server so nicht funktioniert, warum auch immer. Ich wäre gerne dort geblieben. Auch mustergültig war, daß de Buchhaltung die abgebuchten Beträge promt rückerstattet hatte. Und das ist bei den ganz großen Providern wirklich kein Standard - siehe die diversen Berichte in der "ct" im Herbst 2016.
.

Dezember 2016 - Nach Rücksprache mit dem webtropia Support werden dort die zusätzlichen IP-Nummern wahlweise auf die Haupt-IP - also auf den eigentlichen physikalischen Server - gelenkt oder sie sind alternativ für Virtualisierung eingestellt. Dort ist das Problem offensichtlich erkannt.
.