Wenn der Leidensdruck steigt und sich Denkfehler zeigen
- Das Gesicht unserer Server
- Ein älterer Screen-Shot unserer virtualisierten Server VMs) auf unserem Hauptserver
Sept. 2025 - Ein Umzug wird geplant. -- Einführung : Unser Server ist virtualisiert. Das bedeutet, auf diesem Server (einem eigentlich ganz normalen PC) laufen mehrere sogenannte virtuelle Maschinen ("VM"s genannt). Das sind bei uns logistisch eigenständige Server auf diesem PC mit eigenständigen Festplatten-Partitionen auf den gemeinsamen (gespiegelten RAID 1) SSDs (und das sind 2 gespiegelte 1 Terabyte SSDs).
Jetzt dimensioniert der Softwerker vorab diese einzelnen Platten-Partitionen nach der späteren Nutzung bzw. dem Gebrauch bzw. den später eingesetzten Funktionen. Hat sich aber der Planungs-Ingenieur damit etwas vertan, sind also einzelnen Partitionen für den Betrieb z.B. viel zu groß (= etwas zu großzügig) angelegt, ist ein eigentlich nur ein Umzug in eine kleinere Partition angesagt.
Angeblich ist das "ganz ganz" einfach, denn dazu gibt es die Verwaltungs-Funktion des sogenannten "Klonens" (ein Duplikat erzeugen). Im sogenannten "Virt-Manager"- Programm für die vorhandenen virtuellen Maschinen ist eine Klone-Funktion drinnen eingebaut, die angeblich mit (fast nur) einem einzigen Klick eine vorhandene aber abgeschaltete "VM" in eine neu angelegte Partition dupliziert. So jedenfalls steht es im Handbuch.
.
Das XEN/KVM Handbuch ist sehr geduldig - denn die Ecken und Kanten und Stolperfallen kommen noch
Die Ziel-Partition soll(te) identisch zur Quell-Partition sein oder eher etwas größer werden. Muß sie jedoch kleiner werden, weil das ja überhaupt der ganze Grund für den Umzug ist, fängt der ganze Trubel an.
.
Unsere Quell-Partition ist aktuell leider 300 GB groß, und damit viel zu groß für den Root-Bereich der SFTP Server-Installation, bei der die eigentlichen Download- Daten (Dateien) auf einer anderen völlig separaten 2 Terabyte großen SSD-Platte liegen.
.
Beim Verkleinern der Partition einer "VM" fängt es an .....
Für den Verwaltungs- und Programm-Bereich (also das sogenannte Root-Laufwerk) des SFTP-Servers benötige ich real etwa 6 GB - sogar mit etwas Reserve. Die ehemaligen 30GB sind viel zu groß. Und das ist die 3. Sub-Partition auf dem aktuellen SFTP Server. Davor kommt eine 8MB EFI Sub-Partition und eine 2 GB Swap Sub-Partition und hinten dran eine ungenutzte leere 260GB Daten- Sub-Partition, die aber bereits gelöscht war. Um aber die 3. (root) Sub-Partition von 30GB auf 12GB zu verkleinern, muß zuerst das EXT4 Dateisystem verkleinert bzw. reduziert werden. Vorher läßt das "Gparted" Programm das Verkleinern der Sub-Partition nicht zu.
Wenn Sie diese Hürde nach vielem Ausprobieren genommen haben, also das Filesystem verkleinert haben, ist die benutzte Größe der gesamten Quell-Partition mit den 3 Sub-Partitionen jetzt (von den ehemals 30 GB) noch etwa 14 GB groß. Und diese "Festplatte" mit den 3 enthaltenen Sub-Partitionen soll dann in eine neue frische 20 GB Raw-Partion (die ist bislang "nackt" und "unformatiert") geklont werden.
.
Die Klone-Funktion des Virt-Managers ist buggy - feherhaft .....
... oder nicht ausgereift .... Angeblich braucht es nur einen Klick. Also nochmal mit "Gparted" prüfen, wie groß die Quelle ist. Das sind jetzt 3 Sub-Partitionen mit insgesamt ca. 14 GB. Die Ziel-Platte ist 20 GB groß. Damit wären die Bedingungen erfüllt - aber leider nur oberflächlich.
Was immer da nicht funktioniert, nach 2 Tagen Suchen fällt auf, das Klone- Programm ignoriert die neuen UUIDs der 3 neu angelegten Festplatten- Sub-Partitonen und in der speziellen Datei /etc/fstab und vermutlich noch anderen Boot-Configurationen stehen die alten, aber gar nicht mehr gültigen UUIDs drinnen. Das mit den abgeänderten Ports kapiert das Klone -Programm auch nicht, die sind alle weg.
Facit : Die geklonte VM startet nicht. Und das ist Mist, denn es sind jetzt 2 Tage mit Suchmaschinen und opensuse Foren rum - einfach nur verplempert.
.
Leider : doch der uralte konventionelle Weg - die Neuinstallation
Zuerst wird auf der 20GB Zielpartitipn alles an Resten der bisherigen Versuche ausradiert, was dort drinnen verblieben war.
Mit dem Image der aktuellen "Leap 15.6 NET ISO" wird innerhalb von 15 Minuten ein neues Linux mit den 3 Sub-Partitionen auf der 20GB Platte installiert.
Die Netzwerk IPV4 Adresse holt sich diese Neu-Installation vorerst vom DHCP Server und somit kann ich die eigentlich wenigen Konfigurationsdaten von der Quelle, der alten 14GB VM in die neue 20GB VM übertragen.
.
Es fehlen eigentlich nur noch die Konfig-Dateien mit den bislang angelegten etwa 28 Benutzern, die Zuordnung der separaten Daten-SSD-Platte mit den bislang schon gefüllten Daten-Dateien und eine (die alte) feste IPV4 Nummer. -
Dann wäre alles perfekt. Also die Nacht ist ja noch lang.
.
Es fehlte aber noch mehr in dieser Neuinstallation
Das mit dem Verkleinern der Quell-VM mit all den kleinen Ösen und Haken war alles zeitaufwendiger Unsinn - leider, wirklich vertane Zeit. Eine neue saubere opensuse Leap 15.6 mit der NET-ISO aufsetzen als textorientierter Server dauert etwa 15 Minuten, keine 2 Tage.
Das Übertragen der Daten erfolgt über die DOM 0, auf der ich Hilfsverzeichnisse anlege und die entsprechenden Sub-Volumen der heruntergefahrenen Quell-VM sowie des Ziels mounte.
In meinem Beispiel hier die Root-Partitionen bzw.die Sub-Partition der alten Quelle :
mkdir /mnt/md9p3
mount /dev/md9p3 /mnt/md9p3
und hier die neue Sub-Partition der Neuinstallation :
mkdir /mnt/md7p3
mount /dev/md7p3 /mnt/md7p3
.
Kopiert werden die folgende alten Dateien in das neue /tmp/ Verzeichnis:
(1) - /etc/passwd - contains various pieces of information for each user account.
(2) - /etc/shadow - contains the encrypted password information for user’s accounts and optional the password aging information.
(3) - /etc/group - defines the current groups to which users belong
Diese Dateien hier brauchen wir als Vorlage und dazu die alte Netzwerk- Konfiguration, wobei diese Dateien nur zur Kontrolle dienen.
Die Neuinstallation muß über YAST eingestellt werden, weil sonst die Firewall alles blockt.
(4) - /etc/sshd/sshd-conf (muß entsprechen der Vorlage ergänzt !!! werden - also nicht mit der geretteten alten Datei überschrieben werden - das klappt nicht.)
(5) - /etc/sysconfig/network/ifcfg-eth0 und routes
In der Quell-VM sind natürlich abweichend von der Deafault-Konfig andere Ports offen - und schon gar nicht der Port 22 und auch nicht 80 und 443, so werden die allermeisten Einbruchsversuche in diesen SFTP-Server elemeniert.
(6) - Weiterhin muß das SFTP Protokoll nach-instaliert werden.
(7) - In der Firewall wird mit YAST aufgeräumt. Alle Ports werden gekillt / gelöscht und nur ein einziger neuer Port - unser von Port 22 abweichender SSH Port im fünfstelligen Bereich wird im TCP Bereich "public" neu aufgemacht.
.
Das war nur eine rudimentäre Anleitung
Weitere Hilfen gibts per E-mail über unsere Kontakformulare.
.
