Der neue Server hat 2 Sata Platten je 2 Terrabyte und nicht mehr den intelligenten HP-Controller. Damit kann man nur noch ganz gewöhnliche DOS bzw. Windows Partitionen ala "Microsoft Konzeption" erstellen. Das sind bei uns die

• primary Partition 1 als 2 Gigabyte swap und die
• primary Partition 2 als 20 Gigabyte XEN Grundsystem, auch DOM0 genannt.

Als nächste Partition kommt bei uns eine "extended" Partition von den restlichen insgesamt verfügbaren 1,8 Terrabyte dran, die bei uns dann in jede Menge logischer 20 und 60 Gigabyte Partitionen aufgeteilt wird. Diese 20GB und 60GB logischen Partitionen werden als sogenannte RAW-Devices angelegt, nicht formatiert und nicht eingehängt.

Im YAST Festplatten/partition Manager stellt sich das so dar:
.

1. /dev/sda -- 1.82 TiB -- WDC-WD20EFRX-68E
2. /dev/sda1-- 4.00 GiB -- Linux swap -- Swap
3. /dev/sda2-- 20.00 GiB -- Linux native -- Ext4  eingehängt auf / (unsere DOM0)
4. /dev/sda3 -- 1.80 TiB -- Extended
5. /dev/sda5 -- 60.00 GiB -- Linux LVM (hier kommen die 1. DOMU rein)
   
6. /dev/sda6 -- 60.00 GiB -- Linux LVM (hier die zweite)
   
7. /dev/sda7 -- 60.00 GiB -- Linux LVM
8. /dev/sda8 -- 60.00 GiB -- Linux LVM
9. /dev/sda9 -- 60.00 GiB -- Linux LVM
   usw.

.
Eine physikalische Platte kann in der Partition-Tabelle 4 primary Partionen enthalten, hier wären das sda1 bis sda4. Wir haben aber nur 2 primarys. Dann kommt bei uns als 3. Partition die extended Partition mit Nummer 3 und alle weiteren logischen Partitionen innerhalb dieser extended Partition starten jetzt ab Part-Nummer 5, also "sda5" und folgende.

Bei den Platten-Devices ab sda5, das sind die angelegten logischen Partitionen innerhalb der gesamten extended Partition von 1,8 Terrabyte, ist erstmal keine Formatierung angegeben. Das macht XEN bei der Installation der VM.
.

Wenn man jetzt eine neue "Virtuelle Maschine" anlegt, so kann man auch hier (innerhalb dieser VM) die alten bei uns bewährten logischen Partitions-Strukturen erzeugen. Bei uns war und ist das immer
.

1. eine SWAP Partition mit 1 oder 2 GB,
2. eine Linux-System- oder root- Partition von 6, 8 oder 10 GB und
3. eine Datenpartition für unsere Datenbankumgebungen
   mit dem gesamten Rest der "Platte", diesmal also dem Rest der logischen 60 Gigabyte Partition. Ausnahmen gibt es nur bei DNS- und Mail-Servern

.
Der LVM legt (angeblich) in diese 60 Gigabyte Partition eine einzige Datei (oder wie man dieses Konstrukt nennen kann), in der er diese neue Struktur mit den 3 logischen Partitionen ablegt. Damit sind diese inneren drei LVM-Partitionen auf einfache Weise von außen erstmal nicht sichtbar.
.

Wichtig ist, daß man sich bereits beim Anlegen/Erzeugen der virtuellen Maschinen gescheite Namen für die jeweilige VM mit Device und Größe und Funktion ausdenkt. Beispiel : "sda08-60GB-Webserver-www15". Dann sind die VMs im VM-Manger auch gleich richtig sortiert. Und natürlich muß eine Linux Grundinstallation (oder ein "Cloning" einer fertigen Installation) bereits erfolgt sein.

Dann kann man ganz gezielt zum Beispiel an die VM in "/dev/sda5" rangehen.

Die Kommandozeile :  kpartx -l /dev/sda5

zeigt den (bislang) unsichtbaren Inhalt von "sda5" an:
.

1. sda5p1 : 0 2504704 /dev/sda5 2048
2. sda5p2 : 0 20963328 /dev/sda5 2506752
3. sda5p3 : 0 102334464 /dev/sda5 23470080

.
kpartx -l /dev/sda6 zeigt :
.

1. sda6p1 : 0 2471936 /dev/sda6 2048
2. sda6p2 : 0 20965376 /dev/sda6 2473984
3. sda6p3 : 0 102395904 /dev/sda6 23439360

.
kpartx -l /dev/sda7 zeigt :
.

1. sda7p1 : 0 2471936 /dev/sda7 2048
2. sda7p2 : 0 20965376 /dev/sda7 2473984
3. sda7p3 : 0 102395904 /dev/sda7 23439360

.
usw. Das gilt also für alle weiteren virtuellen Maschinen und deren Partitionen. Es ist sicher verwirrend, daß es so viele Versionen/Bedeutungen des Begriffs "Partiton" gibt, die physkalische Partition, die extended Partition und die logische Partition und die virtuelle Partition. Aber das müssen wir zu unterscheiden lernen.

Die Ergebnis-Zeile 3 : sda6p3 : 0 102395904 /dev/sda6 23439360 bedeutet also:

das LVM Device ist sda6 - und dort hat die innere 3. Partition sda6p3 etwa 48 Gigabyte - das sind 23439360 Blocks
.

Es geht mit "ls", weil die XEN-tools bereits installiert sind. Mit ls wird auch die Größe der jeweiligen (inneren) Partition angezeigt.

[xen-2TB-inhaus - root] ~ $ fdisk -l /dev/sda5

Festplatte /dev/sda5: 60 GiB, 64427655168 Bytes, 125835264 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgroesse (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Groesse (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x00052b01

Device      Boot    Start       End   Sectors  Size Id Type

/dev/sda5p1          2048   2506751   2504704  1,2G 82 Linux swap / Solaris
/dev/sda5p2 *     2506752  23470079  20963328   10G 83 Linux
/dev/sda5p3      23470080 125804543 102334464 48,8G 83 Linux

Das Sternchen zeigt bzw. markiert die root-Partition.
.

Bislang haben wir nur gesehen, wie es in der 60 Gigabyte RAW-Partition von sda5 wirklich "aussieht". Vor dem Mounten der beiden für uns wichtigen inneren Devices sda5p2 und sda5p3 müssen wir sie in die /dev/ Liste eintragen bzw. hinzufügen, mappen.

kpartx -a /dev/sda5
und
kpartx -a /dev/sda6
und
kpartx -a /dev/sda7
usw

So werden temporär alle diese virtuellen Partitionen in das temporäre Unterverzeichis "/dev/mapper/" eingetragen.

Das sieht dann in diesem temporären !!! Verzeichnis "/dev/mapper/" so aus (und ist nach einem Neustart des gesamten Servers wieder weg) :

[xen-2TB-inhaus - root] /dev/mapper $ dir
insgesamt 0
crw------- 1 root root 10, 236 24. Okt 11:17 control
lrwxrwxrwx 1 root root       7 24. Okt 13:22 sda5p1 -> ../dm-0
lrwxrwxrwx 1 root root       7 24. Okt 13:22 sda5p2 -> ../dm-1
lrwxrwxrwx 1 root root       7 24. Okt 13:22 sda5p3 -> ../dm-2
lrwxrwxrwx 1 root root       7 24. Okt 13:22 sda6p1 -> ../dm-3
lrwxrwxrwx 1 root root       7 24. Okt 13:22 sda6p2 -> ../dm-4
lrwxrwxrwx 1 root root       7 24. Okt 13:22 sda6p3 -> ../dm-5
lrwxrwxrwx 1 root root       7 24. Okt 13:22 sda7p1 -> ../dm-6
lrwxrwxrwx 1 root root       7 24. Okt 13:22 sda7p2 -> ../dm-7
lrwxrwxrwx 1 root root       7 24. Okt 13:22 sda7p3 -> ../dm-8
lrwxrwxrwx 1 root root       7 24. Okt 13:22 sda8p1 -> ../dm-9
lrwxrwxrwx 1 root root       8 24. Okt 13:22 sda8p2 -> ../dm-10
lrwxrwxrwx 1 root root       8 24. Okt 13:22 sda8p3 -> ../dm-11
[xen-2TB-inhaus - root] /dev/mapper $
.

Grundsätzlich sollten die VMs alle inaktiv, also heruntergefahren sein. Alles Andere birgt eventuelle Gefahren, daß die logischen Partitionen inkonsistent werden könnten.

Ich mache das bei mir so, daß ich mir ein neues völlig eigenes Verzeichnis "/tmp-xen/" anlege, damit ich die Übersicht behalte. Sonst wird es verwirrend. Dort lege ich einzelne Verzeichnisse mit dem jeweiligen Namen der zu bearbeitenden LVM Volumes aus den einzelnen VMS an. Damit habe ich eine vernünftige Übersichtlichkeit, was ich wo bearbeite.
.
mkdir /tmp-xen
cd /tmp-xen

mkdir sda5p2
mkdir sda5p3
mkdir sda6p2
mkdir sda6p3
mkdir sda7p2
mkdir sda7p3
usw.

Dann mounte ich die temporären Device-Einträge auf diese Verzeichnisse.

Beispiel : mount /dev/mapper/sda<partition-num> <mnt point>

bei uns hier (alles absolut adressiert) :

mount /dev/mapper/sda5p2   /tmp-xen/sda5p2
mount /dev/mapper/sda5p3   /tmp-xen/sda5p3

mount /dev/mapper/sda6p2   /tmp-xen/sda6p2
mount /dev/mapper/sda6p3   /tmp-xen/sda6p3

mount /dev/mapper/sda7p2   /tmp-xen/sda7p2
mount /dev/mapper/sda7p3   /tmp-xen/sda7p3

usw. für alle virtuellen Maschinen, die ich jetzt füllen werde. Damit sind die Innereien der virtuellen Maschinen eindeutig benannt und man muß nicht dauernd im Kopf irgendwelche kryptischen Namen substituieren.

Mit dem "Midnight-Commander" prüfe ich das gleichmal mit unserem Beispiel "sda5p2" und siehe, dort ist das gesamte Filesystem der root-Partition meiner ersten virtuellen Maschine zu sehen.
.

Die VMS müssen ! runter gefahren sein. Der bootmanger "grub" kann mit LVMs nichts anfangen, es muß !! grub2 benutzt werden. Vermeiden Sie vorerst BTRF und benutzen Sie überall ext4, sonst starten die neuen VMs nicht, warum auch immer.

Nach der Bearbeitung oder dem Transfer der gepackten Inhalte von meinen anderen Servern muß die IP Nummer kontroliert werden.

Alle Mountpoints müssen vor dem Hochfahren jeder VM wieder entfernt sein. Ob die Mappings auch weg müssen, ist unklar. Ich möchte sie so lange wie möglich aufheben. Nach einem Neustart des gesamten Servers sind sie sowieso weg.
.

Mit den XEN-Tools "clone" und "migration" (aus opensuse 13.2) kann man durchaus virtuelle Maschinen von einem Server an einem Standort auf einen anderen Server an einem anderen Standort durchführen. Doch ich habe nie die vollen 40 Gigabyte belegt und das dauert sowohl inhaus über unseren Gigabit-Switch wie auch nach draußen über das öffentliche Internet ewig. Es wird nämlich Sektor für Sektor übertragen.

So packe ich die beiden Partitionen p2 und p3 der jeweiligen Quell-VM als targz und übertrage sie per sftp auf die DOM0 des Ziel-Servers und entpacke sie in die dort gemappten und gemounteten Zielpartitionen. Auf dem alten Server installiere/aktiviere ich secureftp und auf dem neuen Server benutze ich in der DOM0 den ftp-Client des "Midnight Commanders" zum Abholen

Wichtig ist hierbei, daß ich bei den root-systemen - damals moch mit grub1 - vorsichtig vorgehe, denn die grub2 Bootsequenzen für das neue LVM Partition-System ist jetzt anders. Ich hole mir später nur die Konfig-Dateien aus dem Archiv raus.
.

Unsere Webs laufen fast alle unter Typo3. Wichtig: Wir haben keine interaktiven Webs mit Shops oder sonstigen interaktiven Funktionen, die onlne verändert werden könnten.

Typo3 legt in der mysql/mariadb Datenbank mehrere Cache-Tabellen an, die zumindest bei den Museenseiten enorm groß geworden sind, fast größer als die eigentlichen Quelldaten-Tabellen. Ich leere also alle cache-Tabellen, um in dem komprimierten tar File keine redundanten Daten zu speichern.
.

Für unsere online-Datensicherung haben wir einen shell-script geschrieben, der das alles automatisch macht. Die rücksicherbare komplette Datensicherung der Museenseiten mit allen Tabellen und Bildern umfaßt inzwischen etwa 3 Gigabyte. Hierbei müssen aber das root-Filesystem bereits installiert und die Datenbanken auf einem eventuellen Reserve-Server vor der Rücksicherung erstmal neu angelegt werden. Das spart in der Sicherungsdatei viel Platz.
.

Hier beim Umzug packe ich den gesamten von redundanten Daten entlasteten Bereich samt aller Verzeichnisse und Rechte in einen Transferfile. Den benenne ich gleich nach der zukünftigen Partition auf dem Zielserver. Auch so werden Irrümer vermieden. Da sich bei diesem Umzug alle IP-Nummern ändern, verbleibt der Primary DNS-Server bis zuletzt in der alten Umgebung und die jeweilige Änderung wird dort Zug um Zug korrigiert.

Auf den Secondary DNS werde ich im Moment keinen Wert legen, neue Domains stehen keine an. Das kommt dann ganz am Ende des Umzugs dran.

Die Linux root Partition der alten virteullen Maschine kann ich so sowieso nicht benutzen. Trotzdem werde ich die runter fahren und offline über die DOM0 komplett packen und auf das Zielsystem übertragen.

Die Daten-Partition ist bei uns immer auf /vol2/ gemountet und wir ebenfalls offline gepackt und transferiert.
.

.

1. Auf der DOM0 des Quell-Servers sftp aktivieren. sftp Port in der Firewall freigeben.
2. Die jeweilige Quell-VM mit dem Virt-Manager stoppen oder mit putty ein "shutdown now" absetzen.
3. Die beiden Partitionen innerhalb der DOM0 mounten.
4. mit df -h den Füllstand des Dateisystems überprüfen und die Größe der beiden tar Dateien abschätzen.
5. Reicht der Platz auf der DOM0 für beide tar-Files aus oder muß ich das hintereinander packen und transferieren. Eventuell eine freie Partition ganz am Ende der physikalischen Platte anlegen und in der DOM0 als temporären Transferspeicherplatz benutzen.
6. Die beiden Partitionen packen und für den Hilfsuser freigeben (chown) - der root-User ist bei uns immer geblockt !!!
7. Die gepackten Files über ftp mit dem Hilfsuser auf das Zielsystem abholen
8. Das spätere Löschen der beiden tar Files nicht vergessen.
9. Die beiden Partitionen auf dem Quellserver wieder "ent-"mounten (umount) und die VM wieder starten und im Browser überprüfen.

.

.