Fangen wir nochmal an, die (teils sehr ernüchternden) Erfahrungen der letzen Wochen zusammen zu fassen:

1. Ich verwalte seit über 8 Jahren mehrere virtualisierte HP-Server mit opensue 12.3 XEN und 8 opensue virtuellen Maschinen (Produktiv VMs) sowie 2 Reserve VMs.
   
   
2. Alle 8 VMs sollen auf den neuen "dedicated root-Server" geclont werden, auch wieder unter opensue.
   
   
3. Erkenntnis : opensue 42.1 (Hetzner) als DOM 0 bzw. Hypervisor zickt und ist instabil, also unbrauchbar. - opensue 13.2 dagegen ist stabil und wird von Webtropia unterstützt.
   
   
4. Aufgrund der Erfahrung gibt es nur noch die Vorwärts-Strategie. Also einen Muster-Server hier im EDV-Labor in Wiesbaden aufsetzen und diese Konfiguration auf den Ziel-Server in Düsseldorf übertragen.

.

Damit alles so flüssig wie möglich funktioniert, sollte der Musterserver mindestens den gleichen Netzwerk-Chip haben wie der Zielserver.

Auch die 4 Partitionen sollten jetzt schon - wie auf dem Zielserver - eingerichtet werden.

Wenn der Musterserver läuft (das ist hier jetzt der Fall), muß diese Konfiguration (Partitionierung und XEN-Boot-System) auf den Zielserver übertragen werden.
.

Auf dem "Webtropia" Zielserver hatte ich zwar das "default" Opensuse 13.2 System per Klick installiert bekommen, jedoch in einer völlig verqueren Konzeption, die für einen Produktionsbetrieb so überhaupt nicht brauchbar ist. Bis ich kapiert hatte, daß dort RAID0 konfiguriert war, hatte es bereits etwas gedauert. Auf die Idee, daß das angezeigte RAID-Sstem auch ein RAID-0 sein könnte, kam ich im Traum nicht.
.
Also alles killen und neu anfangen. Als Rescue Betriebssystem wird dort ein "grml" (???) gestartet. Davon hatte ich noch nie etwas gehört und war entsprechend skeptisch. Es sei ein debian Derivat oder so ähnlich.
.

In den letzen 10 Jahren hatten wir uns hier in Wiesbaden unsere (suse) Rescue CDs selbst zusammen gestellt und immer mit den Tools ergänzt, die wir gebraucht hatten. Bei Webtropia wurde mir nun dieses "grml"-debian als immer wieder zu bootendes Grundsystem (diese Live-Version wohnt nur im Hauptspeicher) vorgesetzt und ich mußte lernen, erst mal wieder zu lernen = also estmal kein YAST mehr. Der Entwickler von "grml" hat sich einige Gedanken gemacht, wie man an eine zu reparierende Platte herangeht und welche Tools und Module man braucht - und wie man ein Standard-System vorkonfiguriert.

Bespiel: Es soll die vorhandenen Platten-Partitionen (aller Art) "erkennen" aber nicht mounten. Das Suse Rescue mountet auch gleich, das Unmounten ist aber Mehrarbeit.

Ich brauche von Anfang an sowohl den "ssh-server" sowie den "tightvncserver" und "gparted". Die ganzen Command-Line Werkzeuge brauche ich sowieso, dazu den mc, den "midnight commander" und den Editor "joe". Der "Filezilla" wäre super, den kann man aber nachinstallieren.

Das hatte ich auf dem "Webtropia grml" rescue alles bereits ausprobiert und auch dokumentiert. Diese nachinstallierten Porgramme wohnen aber nur so lange im Hauptspeicher, bis ich den Server erneut starte - als Rescue oder dann von seiner eigenen Festplatte mit opensuse.
.

Sinnvollerweise arbeite ich natürlich auch hier auf unserem Inhaus-Musterserver mit grml, dann sind die Abläufe auf dem Musterserver und auf dem Zielserver nahezu identisch. Und sinnvollerweise arbeite auch auch auf dem Musterserver per putty und mit dem VNC Viewer. Denn dann kann ich per Tastendruck Screenshots zur Dokumentation erstellen.

Der USB Stick mit "grml" wäre dann hilfreich, wenn ich im laufenden Betrieb weitere Programme (nach-) installiere, die ja nur im RAM gehalten würden und danach (reboot) wieder weg sind. Es gibt dort den persistent Modus, der aber (bei mir) im Moment noch nicht funktioniert. Also so wenig zusätzliche Programme nachinstallieren wie unbedingt notwendig.
.

Das aktuelle 64 Bit grml ISO Image (grml64-full_2014.11.iso) hat etwa 470 MB Größe und läßt sich mit jeder NERO Express Version bequem auf eine CD brennen. Damit starte ich einen Notebook mit USB Ports und partitioniere den Stick mit dem gparted über VNC. Damit alles Standard bleibt, wird der 8GB Stick in 4GB FAT16 und 4GB ext3 unterteilt - (das sollte später der "persistent" Bereich werden). Ein ganz normaler 4GB Stick mit FAT 32 reicht aber auch aus.
.
Das "grml" von der CD bootet automatisch nach 29 Sekunden oder sofort mit einmal "Return" und endet mit einem Mini-Menue. In diesem Menue tippe ich "d" für Deutsch und dann wähle ich "x" die X-Grafik-Version aus.

Dort starte ich mit einem Rechts-Klick eine ganz normale Text-Konsole (X-Terminal) und tippe "su -" ein. Jetzt bin ich supervisor bzw. root-User und kann (muss) ein Passwort vergeben - für SSH sehr wichtig !!!!!!.
.
Dann den ssh Dienst starten mit : /etc/init.d/ssh start    und fast fertig. Mit "ifconfig" noch die IP-Nummer des SSH Dienstes erfragen.
.

Auf einmal klappt die bislang benutze Prozedur nicht mehr, da stimmt etwas nicht. Das grml wird gar nicht mehr auf den USB-Stick kopiert ?????
.
Also nochmal das Ganze - unter WIN XP mit "unetbootin-win-549.exe" den Stick beschreiben.
.
Es gibt jetzt kein originales pseudografisches "grml-Menu" mehr, das Menu ist jetzt etwas einfacher gestaltet und nur noch alles auf 1 Ebene. Das Linux-Debian System startet nach wie vor automatisch im Default Modus, aber es startet wenigstens !! Am Ende der Boot-Prozedur muß das kleine grml Menü erscheinen.
.
Mit den Buchstaben "d" und "x" landet man auf der X11 Oberfläche und kann eine X-Term Konsole öffnen.
.

Auf unserem Musterserver liste ich jetzt offline mit dem lokalen grml-debian die Eigenschaften der (vorher) unter opensuse angelegten 8 Partitonen (es sind nur 4 - aber jeweils gespiegelt) auf meinen beiden SATA-Platten und dokumentiere das. Die Partitionen sind bislang nicht gemounted. Über den VNC-Viewer lade ich den gparted und erstelle Screenshots.

Auf dem Zielserver lege ich (ebenfalls) mit dem dortigen grml-debian über den VNC-Viewer und gparted diese 8 Partitonen genau spiegelbildlich an und dokumentiere das ebenfalls.

Die 8 neuen Partitionen auf diesen beiden SATA-Platten sda und sdb müssen jetzt mit den 8 Partitionen auf dem Musterserver - UUID usw. absolut exakt übereinstimmen. Mit diversen Command-Line-Tools prüfe ich das nochmals.

Die Befehlszeilen kommen noch ....

Bislang gehe ich davon aus, daß die ganzen UUIDs auf den jeweiligen physikalischen Platten für den späteren Boot-Vorgang keine Rolle spielen (sondern nur die UUIDs der gespiegelten Raid1 Partitionen).

Auf dem Musterserver ist ja opensuse 13.2 bereits bootfähig installiert und es funktioniert auch. Und noch ist auf dem Zielserver kein RAID1 eingerichtet.
.

Der Masterboot-Record des Zielservers (auf beiden Platten) muß ja genau der gleiche sein wie der des Musterservers. Den muß ich also hier von einer der beiden Platten auslesen und !! auf beide physiklischen Platten des Zielservers übertragen.
.
Der MBR besteht aus 446 + 64 + 2 = 512 Byte.
(Wobei 446 bytes = Bootstrap, 64 bytes = Partition table und 2 bytes = Signature bedeuten.)
Ich brauche also nur die 446 Byte Bootstrap Informationen.

also sichern des (gesamten) MBR auf dem Musterserver mit
# dd if=/dev/sda of=/tmp/mbrquell-platte.bak bs=512 count=1

jetzt übertragen der Datei auf den Zielserver in /tmp/

und rücksichern (nur des Bootstrap Teils) auf beide Platten des bereits partitionierten Zielservers
# dd if=/tmp/mbrquell-platte.bak of=/dev/sda bs=446 count=1
und
# dd if=/tmp/mbrquell-platte.bak of=/dev/sdb bs=446 count=1
.

Die Partition 1 (swap) ist unwichtig. Aber die Inhalte von Part. 2 (das ist /boot) und von Part. 3 (das ist /) werden auf dem Musterserver (offline !!!) gepackt und sollen auf den Zielserver übertragen werden.

Dazu müssen aber auf dem Zielserver zuerst die RAID1 Partitionen eingerichtet und aktiviert werden und mit den exakt gleichen UUIDs gelabelt werden.

Wichtig ist auch hier, daß man das 1:1 vergleicht und zwar akribisch vergleicht.
.