November 2016 - Eigentlich ist alles ganz ganz einfach. Es gibt da im XEN virt-manager die Funktion "migrate", deren Beschreibung sich hervorragend liest. Aber ganz am Ende stehen dann doch jede Menge "Abers", was man alles beachten solle und vor allem, wann es nicht geht. Die beiden XEN Grund-Versionen in der DOM-0 (Quelle und Ziel) müssen zum Beispiel zwingend identisch sein.

Alleine das funktioniert schon mal nicht, weil man ja meistens mit den VMs umzieht, um das Linux samt XEN Grundsystem der DOM-0 auf eine aktuelle Platform zu hieven. Dann muß man weiterhin jede Menge allgemein bekannter Ports öffnen und der Transfer dauert auch noch recht lange, teilweise sogar Stunden mit all den offenen Ports, weil Sektor für Sektor übertragen wird. In den XEN Foren wird von mehreren Stunden für 40 Giga gesprochen. Da ich den einen oder alle diese Transfer(s) auf beiden Produktiv-Servern innerhalb der XEN Grundsysteme DOM-0 laufen lasse, ist mir das mit den zusätzlichen offenen Ports zu gefährlich.

Das alles macht aus meiner Sicht nur wenig Sinn. Zumal bei den ganzen VMs erst mal das alte Betriebssystem weiter laufen muß, schon wegen der bei uns für Typo3 jeweils benutzen PHP- und mysql- Version, die lange nicht alle abwärts kompatibel sind.
.

Welche Linux-Tools brauche ich auf dem 64bit XEN Grundsystem in der DOM-0 ?

Zusätzlich zu unserer minimalen grafischen opensuse Oberfläche - die minimale Grafik brauchen wir sowieso in der XEN-DOM-0 für YAST2 und für den virt-manager und für die ganzen XEN-tools - sind aus meiner Sicht die folgenden Programme sinnvoll :
.

1. gparted 0.14.1 (der ist anders als der "partitioner" von YAST2)
2. thunar 1.61 mit verbesserten Archive-Optionen (der mc und der joe sind sowieso immer dabei).
3. filezilla 3.7.3 ist für mich der komfortablere und übersichtliche ftp Explorer

.
Mit "gparted" sieht man die Laufwerke und Partitionen der einzelnen virtuellen Maschinen deutlich besser als mit YAST.

Mit "thunar" haben wir einen Filemanager, der ählich wie der mc ganze Verzeichnisse packen und komprimieren kann, aber mehrere Kompressionsarten übersichtlich anbietet.

Mit "filezilla" übertragen wir die jeweiligen gepackten Archive vom XEN-Grundsystem DOM-0 auf einen interims ftp Servers (oder aber gleich auf den neuen XEN Zielserver).
.

Je nach Menge der Daten auf der (den) VM(s) ist es sinnvoll, dem XEN Grundssystem DOM0 eine extra (Transfer-) Datenpartition dauerhaft zuzuordnen. Bei mir war eine 28 Giga Partition unbenutzt und die habe ich der DOM-0 zugeordnet und über das neue Hilfs-Verzeichnis "temp-data" eingeklinkt. Dort lagere ich die komprimierten Archive für den ausgehenden Transfer. Gleiches gilt natürlich auch für die Ziel-Maschine. Auch dort brauche ich ein temporäres "Zwischenlager".
.

Bislang hatte ich die jeweils heruntergefahrenen Partitionen komplett mit dem Unix "tar" Programm auf Kommandozeilen-Ebene in Archive vom Typ z. B. "www12-2016-11-root.tar.gz" und "www12-2016-11-data.tar.gz"gepackt.

Aber beim Entpacken solcher mit "tar" gepackten Partitionen mitsamt der Typo3 Umgebungen ab Version 4.2 werden auf dem Zielsystem an den Zeilenenden Buchstaben abgeschnitten, zwar wenige nur, aber oft sogar die gesamten "*.php" Endungen, manchmalauch nur das letzte" p" von "php". Und dann startet Typo3 gar nicht mehr. Sowohl das Frontend wie auch das Backend sind volkommen weiß, der index.html source-code im Browser ist total leer. Es ist ein Problem der sogenannten "command line length".
.

In den Linux-Logfiles (messages, apache-error usw.) findet man dann die Meldungen, welche der Module bzw. php-Dateien vom aufrufenden Programm nicht gefunden werden. Man übersieht bei der Recherche ganz leicht, daß die zwar da zu sein scheinen, doch die Endungen oder nur Teile davon - oft gerade mal der letze Buchstabe - sind weg. - Wenn man auf solche blöden Fehler nicht gleich kommt, sucht man sich dämlich. Das Programm phpinfo.php ist da nicht hilfreich, weil php ja sauber funktioniert.

Linux kann seit Anbeginn Dateinamen samt der voran gestellten absoluten Verzeichnisse mit einer Länge von 255 Characters speichern, das "tar" Programm anscheinend nur bis etwa 100 Buchstaben. Genaues hatte ich noch nicht recherchiert - auf jeden Fall zu wenig, die Zeilen werden am Ende gekappt. Es könnte aber auch am "midnight commander" und an dessen Entpack-Modul liegen, darum werden wir auf den grafischen Dateimanager "thunar" umsteigen.

Es betrifft nicht nur die Typo3 Sourcen, es betrifft auch installierte Extensions mit überlangen Dateinamen, deren Dateien im jeweiligen lokalen "typo3conf/ext/....." abgelegt werden und die dann nicht mehr gefunden werden.

Das mit den angehackten Zeilenden betrifft aber NICHT das Linux root Filesystem. Dort nämlich sind die Verzeichnisse mit den Programmnamen erheblich kürzer.

Eigenschaften eines "zip" Archives :
Ganz wichtig : Sie brauchen also sicherheitshalber beides, das "tar" Archiv und das "zip"-Archiv. In den ZIP-Files sind keine symbolischen Links und auch keine Owner und Groups enthalten. Wenn die fehlen, bootet die VM nicht. Hier brauchen wir unbedingt die .tar.gz Archivierung zum Nachbessern.
.

Die jeweilige VM (virtuelle Maschine) muss runter gefahren werden bzw. bereits unten sein.

"shutdown now" hilft immer.

Innerhalb der XEN DOM0 werden 2 (Hilfs-) Verzeichnisse angelegt, die dem Partitionsaufbau unserer VM entsprechen

unsere VMs haben seit über 10 Jahren immer folgende Partitionen (es hat sich glänzend bewährt) :
.

1. swap mit zwischen 1 und 4G (bezüglich Archiv nicht beachten)
   
2. root mit 8 bis 10 GB
3. Typo3/mysql/data mit zwischen 28 und 50GB

.

Bei uns sind das "als Beispiel" die Hilfsverzeichnisse auf "root" Level, die (später) auf den Inhalt der jeweiligen Partition zeigen:
.
/z-c0d2p2
/z-c0d2p3
.
Im YAST-Partitioner werden in die beiden zu archivierenden Partitionen der jeweils herunter gefahrenen VM (also der jeweiligen Quelle) diese Verzeichnisse eingeklinkt und damit in der DOM-0 sichtbar gemacht. (Mit den gemounteten Verzeichnissen kann diese VM so nicht mehr gestartet werden, beide Verzeichnisse müssen nach dem Archivieren wieder mit "umount" gelöst werden.
.

Vom für alle VMs gemeinsamen XEN Grundsystem kann ich jetzt auf die beiden eingeklinkten Platten des VM-Gastsystems ganz normal zugreifen. Alle virtuellen Devices des Gastsystems, die temporären "mounts" und die sonstigen temporären Variablen sind jetzt nicht mehr da, ich kann also diese beiden Partitionen archivieren und natürlich komprimieren. Bei den mysql Datenbanken ist das ganz enorm, wie die Inhalte geschrumpft werden. Gerade die riesengroßen "innodb"- Tabellen sind innen fast leer.

Um mein XEN Grundsystem nicht gegen die Wand zu fahren (hurrah, die Platte ist voll), hatte ich mir am Ende der physikalischen 500 Giga oder 4 Terra Platte eine Partition für temporäre Daten-Ablagerungen mit "ext4" formattiert und ebenfalls - aber auf Dauer - gemontet. Dorthin dirigiere ich die Archive aller virtuellen Maschinen zum Transfer, bis der Server (am Ende) ausser Betrieb geht.

Nach dem Packen der beiden Partitionen der jeweiligen VM kann ich die beiden Hilfs-Verzeichnisse wieder ausklinken und die VM wieder starten. So lange, wie die Partitionen einer VM im XEN Grundsystem gemountet sind, kann die VM die eigenen Platten nicht ansprechen.
.

Da der "alte" (physikalische) Server ja immer noch (bis zur letzten aktiven VM) im produktiven Betrieb läuft, ist es gefährlich, auf einem XEN-Grundsystem einen vsftp Server zu starten. Ich jedenfalls möchte das nicht. Eine eigene kleine virtuelle Maschine als temporärer ftp Server ist da unkritisch bzw. ungefährlich. Wenn das XEN Grundsystem abgeschossen würde, wäre dieser Server "im Eimer".

Aber auch mit den ftp Clients gibt es Hinkefüße, die Leben nicht gerade erleichtern. Mehr dazu kommt noch.

Ein Test - Der uralte ftpx Explorer unter Windows :
Erfreulich, der uralte ftpx Explorer (Version 1.0 aus 1996). Dieser ftp-Client funktioniert unter allen bekannten Windows Versionen ab WIN98. Da muß man nichts einstellen, einfach nur die IP Nummer eingeben, dazu Benutzer und Kennwort und los gehts.

In der gleichen Windows Umgebung (2000, XP WIN7 usw.) tut sich der Filezilla Version 3.3.5.1 bereits sehr schwer. Er kann das Server-Verzeichnis nicht anzeigen. Da muß mehr konfiguriert werden. Es ist aber mühsam, das herauszufinden.

Doch das alles dient ja nur zur Prüfung, ob dieser temporäre vsftp Server "von Draußen" überhaupt est mal zugänglich ist. Denn ich will sowohl vom Quell-Server wie auch vom Ziel-Server (jeweils als Client) auf diesen (nicht anonymen) ftp-Server zugreifen.
.

Die Linux Partition (in jeder VM die Part. 2) packen wir mit dem "thunar" in eine tar.gz rein, jedoch die Typo3/mysql Partition (Part. 3) in einen ZIP File UND einen .tar.gz File. Das alles geht mit dem Programm "thunar" deutlich besser als mit dem mc. Im "tar" Archiv wird mit manchen langen Dateinamen von der Länge her nämlich Schindluder getrieben, es wird von manchen Dateinamen am Ende etwas abgetrennt. Es müsste nicht sein, ist aber so und Sie suchen sich später tot.

Das Programm "thunar" ist eigentlich ein Filemanager mit der "archive" Extension. Manche Funktionen sind etwas schwer zu verstehen, am Anfang sind sicher mehrere Versuche notwendig, um das Ergebnis (also das Archiv) auf der gewünschten Daten-Partition des XEN-Grundsystems abzulegen. Sie sollten diese Transfer-Archive nie in der XEN DOM-0 root- Partiton ablegen, denn irgendwann ist diese Platte voll.
.

Auch das Bedienen des "filezilla" unter Linux ist lernbedürftig. Auf dem ftp Server sind die typischen ftp Ports (20, 21, 22) in der Firewall zu öffnen. Das macht man mit yast, indem man ganz einfach den "ftp"-Dienst frei gibt.

Unser Quellserver (und auch später der Zielserver) ist aber jetzt der Client und dort sind (neuerdings) auch ein paar neue Ports zu öffnen. Auf dem ftp Server gibt es in /etc/ die Datei vsftpd.conf, in der man die zusätzlich benötigten Ports für den eigentlichen ftp Daten-Transfer angeben muß. Bei uns ist das der Portbereich 60000 bis 60010.

Warum man im ftp Client Computer diese Port-Range ebenfalls öffnen muß, ist mir ein Rätsel geblieben. Und warum es früher unter suse 11.x und 12.x ohne diesen Klimmzug ging, ist ebenfalls ein Rätsel.
.
Im Filezilla müssen Sie auf jeden Fall die Verzeichnisse beider "Enden" sehen, also die lokalen Verzeichnisse Ihres Clients und die ftp-Server- (Remote-) Verzeichnisse. Sehen Sie die Remote-Verzeichnisse auf dem ftp-Server nicht, ist etwas schief gelaufen.
.

Zu diesem Zeitpunkt könnten Sie die herunter gefahrene und bereits archivierte virtuelle Maschine wieder hoch fahren, sofern die Webs möglichst schnell online sein müssen und etwaige (spätere) Änderungen nicht relevant sind.

(Anmerkung : Bei den Typo3 Webs setze ich alle Backend-Benutzer beim Beginn der ganzen Prozeduren auf inaktiv. Damit können die Redakteure nichts mehr ändern.)

Auf der DOM-0 des Zielservers - jetzt auch als ftp-Client - gelten während des weiteren Transfers die gleichen Port-Voraussetzungen wie auf dem Quell-Server, der Portbereich von 60000 bis 60010 muß geöffnet werden. Ebenfalls mit dem dortigen "fielzilla" holen Sie die Transfer-Archive vom ftp Remote-Server ab und speichern die auf der vorbereiteten lokalen Datenpartition.
.

(Anmerkung : Eigentlich mache ich das Folgende bereits vorher.) Bei uns waren auf dem Quellserver insgesamt 8 virtuelle Maschinen aktiv, jedoch 14 VMs passiv vorbereitet, wobei nur die aktiven VMs auf de Zielserver portiert/migriert werden sollen und dort wieder laufen sollen.

Diese neuen virtuellen Maschinen müssen oder sollten vorher gut und logisch vorbereitet (initialisiert) sein. Nur somit ist die Bootfähigkeit jeder einzelnen VM gewährleistet. Wichtiger ist jedoch die saubere Benennung jeder VM, sonst kommen Sie schnell durcheinander.

Bei uns sind die logischen Partitonen sowie die jeweilige Größe der sogenannten RAW- Partition (die ist anfänglich unformatiert) die Grundlage der Bezeichnung.

Ein Beispiel von unseren HP Servern :

Der HP-DL385 SCSI Controller wird als Device mit dem cciss Treiber angesprochen. Damit sind alle Partitonen unter /dev/cciss aufgelistet.

Beispiel der (unformatierten) Raw-Partition "c0d4", die mit Yast oder gparted in 3 logische Partitionen aufgeteilt wurde :

/dev/cciss/c0d4 (unformatiert)
/dev/cciss/c0d4p1 (ist bei uns swp)
/dev/cciss/c0d4p2 (ist bei uns das Linux System - mit ext4)
/dev/cciss/c0d4p3 (dort wohnen die Daten, die Webs und mysql - auch ext4)

Die Raw-Partition "c0d4" ist zum Beispiel insgesamt 40 Giga groß, beim Anlegen der virtuellen Maschine hatte ich dann unter YAST folgende Aufteilung konfiguriert: 1GB für swap, 8 GB für Linux und 30 GB für Typo3 und mysql bestimmt.

Zur Benennung der VM ist für mich aber nur der Device-Name der RAW Partition wichtig, - dann kommt die Größe und dann kommt die eigentliche Bezeichnung der Funktion (mail oder web oder ftp oder DNS.

Wieder ein Beispiel : c0d04-40GB-Webserver-www18

Beachten Sie, daß ich bei der Bezeichnung aus "c0d4" dann mit "c0d04" eine 0 hinzugefügt habe. Damit werden die VMs im XEN virt-Manager in der sauberen Reihenfolge aufgelistet. Ordnung ist das halbe Leben, damit Sie nach 6 Monaten noch oder wieder durchblicken - das ist meine Erfahrung.
.
Haben Sie eine Muster-Partition (also eine Muster VM) dann mit dem Betriebssystem Ihrer Wahl und einer DHCP Netzwerkadresse gefüttert, können Sie die Partition mit dem virt-manager beliebig oft clonen (und dabei gleich richtig benennen). Damit ist jede VM nachweislich bootfähig. Das ist wichtig, damit der MBR korrekt gefüttert wird. Clonen geht erheblich schneller als jede VM einzeln zu installieren.
.

Hier gilt es aufzupassen, daß man je nach Bedarf die "tar" oder die "zip" Archive zum Rücksichern nutzt. Wie weiter oben bereits gesagt, erstelle ich inzwischen aus bitterer Erfahrung beide !! Archive doppelt (also tar und zip), auch wenn die Datenmenge dann doppelt so groß wird.

In den ".tar.gz" Archiven sind die Verzeichnis- und Datei-Attribute sowie symbolische Links enthalten. Dafür sind leider die Verzeichnis- und Datei- Zeilen-Längen begrenzt. Und das merken Sie erst , wenn diese VM nicht wieder hoch fährt. Und Sie suchen und suchen den Fehler, weil es ja so blöde einfach ist.

In den "zip"-Archiven sind keinerlei Verzeichnis- und Datei Attribute enthalten.
Dafür sind die Verzeichnisse und Dateien ungekürzt in voller Länge wieder da. Ganz wichtig ist, wenn Sie einen Zip-File entpacken, haben alle ausgepackten Dateien und Verzeichnisse "root:root" als user und als gruppe.

Der gesamte Web-Bereich , auf den der apache Zugriff haben muß, muß unter opensuse dann nochmals per chown auf wwwrun:www gesetzt werden und der gesamte mysql Bereich auf mysql:mysql. Und dann geht es auf einmal wie von alleine.
.

Wie nicht anders zu erwarten, hat jetzt dieser Clone die gleiche IP Nummer wie die noch laufende alte VM. Die muß !!! unbedingt runter gefahren werden, "bevor" die Neue virtuelle Maschine gestartet wird. Ich habe noch nicht ausprobiert, was passiert, wenn zwei Interfaces die gleichen IPs haben.
.

Wie ganz oben geschrieben, habe ich natürlich solch eine Prozedur erst mal an einer unkritischen Maschine ausprobiert. Das hatte nach 2 Tagen Evaluierung der Macken ganz gut geklappt. Die zweite VM wollte aber gar nicht, weil dort wiederum alles etwas anders war. Das liegt bei uns an der historischen Aufeinanderfolge der Installationen.

Planen Sie immer Reserven ein, wenn Sie dem Kunden versprechen, das geht in xx Stunden. Allermeist dann klappt es nämlich nicht. Die dritte VM war wieder verschieden und hatte sich mit Händen und Füßen gewehrt, nach dem Transfer wieder "aufzutauchen".
.

das wird dann korrigert oder nachgetragen.
.