In diesem Kapitel wird nun endlich nach den vielen Vorbereitungen in der VM zu Hause der Server bei STRATO mit dem Image installiert. Nach der installation befindet sich der Proxmox Server auf dem gemieteten Server im Internet und nicht mehr zu Hause in einer VirtualBox VM. Diese Prozedur erfordert einige Schritte. Einige Einstellungen konnten in der VM noch nicht eingestellt werden, da sie in ihrer Umgebung nicht funktioniert hätten. Hier werden die Einstellungen nun nachgezogen, um den Proxmox auf dem echten Server betreiben zu können.
Am Anfang der gezeigten Vorbereitung wurde darauf hingewiesen, den Server bei STRATO Einzurichten. Es wurden einige Einstellungen von dem STRATO Setup übernommen, da sie auf dem Proxmox System übertragen sein müssen, wenn
dieses auf den echten Server kommt. Ferner lässt STRATO den Zugriff auf den Server erst zu, wenn dieser einmal installiert wurde.
Für die Vorbereitung eines Proxmox Images wurde eine virtuelle Maschine aufgesetzt. Diese muss nun ausgeschaltet werden, damit die nächsten Schritte durchgeführt werden. Unten wird ein Schritt gezeigt, wo das Image über
SSH auf den gemieteten Server kopiert wird. Dieser Schritt wird für VirtualBox gezeigt, da hier für die Vorbereitungen VirtualBox für die VM verwendet wurde. Grundsätzlich kann das gezeigte auch mit anderen
Softwarelösungen gemacht werden. Hier zu erwähnen sei: Wenn eine andere Software keine vergleichbare Funktion für den Image Zugriff anbietet, wie er hier per VirtualBox möglich ist, kann auch aus der VM heraus die VM zum
echten Server per SSH kopiert werden. In diesem Fall wird nun die VM mit einem Linux (Desktop / Textkonsole) neugestartet, anstatt heruntergefahren. Dies muss gemacht werden, damit der Proxmox nicht im laufenden Zustand kopiert wird.
Der Server soll mit einem SSH Tunnel 1:1 auf den STRATO Server kopiert werden. Das benötigt zwei Schritte, die Parallel durchgeführt werden können.
Hinweis: Diese Anleitung basiert auf dem Setup des ersten Servers mit 1xSSD ohne RAID und 2xHDD mit RAID.
Auf der Seite des Servers bei STRATO muss auf das Rescue Boot des Servers gewechselt werden. Dazu muss man sich auf der Server-Login Seite für den eigenen Server anmelden, bzw. sich vom Kunden-Login dorthin weiterleiten lassen.
Man Navigiert im Menü zu "Backup & Recovery" und wählt den Menüpunkt "Rescue Boot". Auf der Auswahl kann man auswählen, welche Quelle der Server für das Betriebssystem wählen soll.
Nebenbei erklärt: Das kann von außen unabhängig umgestellt werden. Der Bootloader auf den Datenträgern ist dafür nicht relevant. Der Server versucht zuerst immer vom Netzwerk von STRATO zu starten. Hat man den
Server auf "Standard OS" eingestellt, lenkt der Bootloader vom STRATO Netzwerk den Start um auf die Festplatte(n) oder SSD(s) die im Server installiert sind. Stellt man den Server in der Ansicht des Server-Login um auf das
"Rescue OS" wird im Netzwerk von STRATO eine andere Bootloader Einstellung angelegt, die das Rescue OS aus dem STRATO Netzwerk lädt.
Das Rescue OS wird nun benötigt, um einen unabhängigen Zugriff auf den Server zu haben. Man wählt die Einstellung "Rescue OS" aus. Bei der unteren Auswahl kann man bestimmen, ob der Server durch Trennen der
Stromverbindung neugestartet wird oder man ihn per manuellem Befehl auf der Konsole neu starten möchte. Streng genommen ist das zu diesem Zeitpunkt egal, was man wählt, denn das System, welches aktuell läuft, wird hier als
nächstes überschrieben. Der Umstellungsprozess dauert bis zu 10 Minuten. Erst wenn das abgeschlossen ist, kann der Server von Hand neugestartet werden, wenn "Soft Reboot" ausgewählt wurde. In dieser Zeit kann mit
dem nächsten Schritt begonnen werden.
Bitte spätestens wenn der Server im Rescue OS von STRATO angekommen ist, Konfigurationsdateien sichern, die unten bearbeitet werden. Entweder man lädt sich diese herunter oder kopiert den Inhalt in einen Editor. Ich hatte einen Vorteil und hatte die Festplatten, die hier nicht angefasst werden. Auf diesen habe ich ein Diskdump und ein Tar Archiv vom STRATO Debian gespeichert. Dieses habe ich später auf die Proxmox Installation ausgepackt und von dort die Konfigurationsdateien bezogen.
Die VM zu Hause wurde mit VirtualBox vorbereitet. VirtualBox bietet dem Nutzer für virtuelle Festplatten die Dateiformate ".vhd", "vdi" und ".vmdk" an. Diese Dateien enthalten etwas mehr als die
Datenblöcke der virtuellen Festplatte. Der Upload über eine SSH Verbindung erfordert nun dass man diese Dateien entweder als Datenträger im Host einbinden kann oder eine Konvertierung in eine Rohdaten- Imagedatei. So kann die
virtuelle Festplatte nicht als Image auf die Festplatte / SSD des Servers bei STRATO entpackt werden.
Als Tool soll hier "dd" die Imagedatei auf dem Host einlesen und die Ausgabe durch eine SSH Pipe schicken. Auf dem Server wird gleichzeitig auch "dd" verwendet um aus dem SSH Pipe die Daten zu nehmen und auf die
Festplatte / SSD des Servers zu schreiben. Anpassungen wegen der Unterschiede der VM zu dem "echten" Server werden danach vorgenommen.
Um die virtuelle Festplatte zu konvertieren, muss man leider die UUID der Datei wissen. Das ist kein Wert, der einfach mal so ins Auge fällt. Außerdem kann man den Befehl um die Datei zu konvertieren nur auf der Kommandozeile
absetzen. Das geht dann aber genau so, wie unter anderen OS auf denen VirtualBox läuft. Unter Windows muss man lediglich vorher eine Eingabeaufforderung / Power-Shell öffnen und in das Installationsverzeichnis von VirtualBox
wechseln. Im unveränderten Fall lautet das Kommando für den Windows Nutzer cd C:\Program Files\Oracle\VirtualBox\. In jedem Fall muss nun die UUID der virtuellen Festplatte gefunden werden. Eine
UUID ist Typischerweise in geschweiften Klammern geschrieben und besteht aus Hexadezimalen Zahlen mit Bindestrichen. Man Findet die UUID der Festplatte in dem man im Management Fenster in der linken Hälfte bei "Werkzeuge" auf
die Menüfunktion klickt und dann auf "Medien" (Bild 1). Man aktiviert rechts die Anzeige von Eigenschaften und wählt im untersten Teil den Reiter "Informationen" aus (Bild 2). In der Mitte werden alle Disks
aufgelistet. Man kann jeweils am Namen erkennen (vgl. VM Information) welche Festplatte man Braucht. Ich habe in meinem Setup nach jedem Schritt einen Snapshot der VM gemacht. Daher fächert sich bei mir die Auflistung in mehrere
Einträge auf. Man braucht von der untersten Datei die UUID. Diese lässt ich mit einem klick auswählen und per Rechtsklick kopieren.
Der Befehl, der zum konvertieren benötigt wird, den habe ich unten eingefügt mit der UUID der Festplatte in meinem Setup. Man Schreibt diesen Befehl in die Eingabe, mit entsprechender Anpassung der UUID. Es wird dabei eine weitere
8GB große Datei erzeugt.
VBoxManage clonemedium {d0765395-081b-4fe2-a31a-32b73cc65269} \
pveProv.img --format RAW
Zum Zoomen klicken.
Bild 1: VirtualBox - Menüauswahl Diskauflistung
Bild 2: VirtualBox - Anzeige der UUID für die VM Disk zum Konvertieren
Für den nun folgenden Schritt muss der Server von STRATO im Rescue Boot angekommen sein. Einloggen kann man sich dort mit dem Nutzer Root. Der SSH Server läuft auf dem Standardport 22. Das Passwort für den Nutzer ist
generiert worden und findet sich im Server-Login unter "Serverdaten". Man verschafft sich am besten mit lsblk einen Überblick, wie die Festplatten / SSDs bezeichnet werden. Man bekommt je
nachdem wie viele Geräte im Server existieren eine verschieden lange Auflistung. Ich habe einen Server mit 1x SSD, auf der das STRATO Debian installiert wurde und 2x Festplatte. Die Platten sind zum einen Größer und für
Soft-Raid mit einer großen Partition bespielt. Anhand der vorhandenen Partitionen konnte ich sehen, dass die Platten nicht mein Ziel sind. Auf der SSD sind mehrere Partitionen angelegt, womit mir klar war, dass dort das OS installiert
ist. Den Gerätenamen (/dev/sda) musste ich mir kurz merken.
Mit dem unten gezeigten Befehl habe ich dann die gerade konvertierte Image-Datei auf die SSD des Servers geschrieben. Genutzt wird hier dd für die Verarbeitung der Imagedatei und um diese auf die SSD
zu schreiben. Der Datenstrom wird durch SSH von zu Hause zu dem Server im Internet getunnelt. Um den Upload zu beschleunigen wird gzip mit hoher Komprimierung dazwischen geschaltet. Schickt man den Befehl
ab, wird man zuerst nach dem Passwort für den Nutzer root am Server gefragt. Hier also erneut das Passwort aus dem Server-Login einfügen. Daraufhin zeigt einem der Prozess zu Hause die übertragenen Daten an. Die SSD auf dem
Server wird nun überschrieben. Das Proxmox OS muss im Übrigen auf die SSD, weil der Server nur dort nach einem startbaren OS suchen wird. Wenn der Prozess fertig ist, ist die Arbeit zu Hause fertig. Die im Vorherigen erstellte
Imagedatei kann weg. Weiter geht es nun ausschließlich auf dem gemieteten Server.
dd if=pveProv.img status=progress | gzip -c -9 | ssh stratoserver \
'gzip -d | dd of=/dev/sda'
Mit dem Abschluss der Kopieraktion ist Prinzipiell der Proxmox auf dem Server angekommen. Alle weiteren Schritte erfolgen nun auf dem Server bei STRATO. Grundsätzlich hat der Kopiervorgang nur die Daten des Proxmox, samt Partitionierung übertragen. Alles ist noch auf dem Zustand der angepasst war auf die Vorbereitung in der VM. Um die nachgelagerte Anpassung an den Echten Server geht es nun.
Um die Übertragung der Imagedatei auf den Server zu beschleunigen, wurde für die VM nur eine 8GB große virtuelle Festplatte angelegt. Das hat nun den Nachteil, dass obwohl die SSD 128GB groß ist, nur 8GB verwendet
werden. Deswegen wird nun "root" auf die gesamte SSD vergrößert. Es wäre zwar auch möglich den Platz zu lassen und ihn für VMs des neuen Proxmox zu verwenden, jedoch macht dieses Setup hier keinen Sinn.
Für die VMs sollen die Festplatten verwendet werden.
Nach dem Übertragen von zu Hause hat der LVM sofort erkannt, dass es neue Volumen gibt und hat diese Aktiviert. Das verhindert das Vergrößern. Man deaktiviert die Verwendung der Volumen mit dem Befehl vgchange -a n. Im Anschluss wird fdisk mit der SSD fdisk /dev/sda aufgerufen. Es gibt einige Warnungen aus (siehe Bild 3). Diese sind aber OK und hängen mit dem Transport
der VM zusammen. Um nun die Partition zu vergrößern, muss zu erst die Partition vergrößert werden, die das LVM PV enthält. Denn "root" liegt dort drin. Dies wird fdisk durch Löschen und erneutem
Anlegen mit maximaler Größe erklärt. Zu den gemachten Eingaben habe ich mal einen Screenshot (Bild 4) angelegt. Hat man das fertig, gibt man ein "w" ein und drückt Enter. "fdisk" Ändert nun die
Partitionen bis zum Ende der SSD.
Man muss leider den Server nun neu starten. So verarbeitet der Kernel und der LVM die Änderungen. Der Neustart kann einfach per reboot erfolgen. Das Passwort für "root" bleibt das
gleiche.
Ist der Server wieder im Rescue OS gestartet und man eingeloggt, muss noch ein Befehl eingegeben werden. Dieser steht unten. Man vergrößert das LV für das "root" Volumen. Wenn der Befehl seine Arbeit mit Erfolg
beendet hat, sorgt er implizit für das Aufrufen einer weiteren Vergrößerung des ext4 Dateisystems auf die volle Größe.
lvextend -r -l 100%FREE /dev/pve/root
Zum Zoomen klicken.
Bild 3: Warnhinweis von fdisk wenn man nach Import es aufruft.
Bild 4: Schritte in fdisk zum Vergößern des LVM PV
Aus der Vorbereitung in der VirtualBox Umgebung sind noch ein Paar Einstellungen offen, die jetzt eingestellt werden müssen, bevor der Server das erste Mal den Proxmox auf dem STRATO Server startet. Das ist zum Teil wichtig, damit der Server korrekt in der neuen Umgebung läuft und erreichbar ist. Der Server sollte von der Anpassung der Diskgröße noch im Rescue OS von STRATO sein. Um nun die Schritte unten ausführen zu können, wird ein "Change-Root (chroot)" in das Proxmox OS gemacht. Im folgenden eine Liste an Befehlen, die das "chroot" einrichtet und in eine Shell darin wechselt. Die Befehle gelten so, dass wie in meinem Fall der Proxmox auf "sda" installiert ist. Für das Boot-Setup von Proxmox OS speziell: Es muss weder eine Bootpartition noch eine EFI-Partition eingebunden werden!
mount /dev/pve/root /mnt
mount --bind /dev /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
mount --bind /run /mnt/run
chroot /mnt /bin/bash
Im Kapitel 02 wurden Die Netzwerkeinstellungen für den Server angeschaut. Ferner wurden einige Einstellungen gesetzt, wie das Ändern der "vmbr0" und des "enp0s3" für den NAT-Modus betrieb. Dort mussten IP-Adresse und Subnetz (CIDR-Notation), sowie das Gateway auf den Einstellungen des Netzwerks aus VirtualBox belassen werden. Jetzt müssen diese Einstellungen auf den "echten" Server angepasst werden. Ferner änderte sich in dem Fall die Benennung der Netzwerkschnittstelle, weshalb auch hierfür die Datei angepasst werden musste. Hinweis: Unter "vmbr0" befindet sich die Anweisung "bridge-ports ...", welche im Beispiel unten nicht gezeigt wird. Wenn diese Einstellung nicht auf "... none" steht, bitte die selbe Bezeichnung der Netzwerkschnittstelle hier eintragen (im Beispiel "eno1").
Änderung von:
auto enp0s3
iface enp0s3 inet static
address 192.168.55.4/24
gateway 192.168.55.1
Änderung zu: (Daten zu Demozwecken geändert)
auto eno1
iface eno1 inet static
address 85.214.5.42/32
gateway 85.214.254.42
Im Kapitel 02 wurde die Ausgabe der Hostnamen Einstellung und der sog. "Hosts"-Datei gezeigt. Für die Vorbereitung in der VM war hier keine Anpassung nötig. Jetzt muss dies aber geändert
werden.
In der Datei /etc/hostname steht der Hostname ohne Domäne drin. Hier muss lediglich an den Eintrag (h0000000) ein ".stratoserver.net" angehangen werden.
In der Datei /etc/hosts stehen die Domänen korrekt drin. Jedoch steht davor die IP-Adresse aus der VM von VirtualBox. Hier wird die IP geändert zu der IP-Adresse, die der Server wirklich hat.
Der Server hat in der Datei /etc/resolv.conf die Einstellungen für den DNS-Server, den er befragen soll. Außerdem wird dort die Domäne des Servers Festgelegt. Man sollte hier die Werte aus
der Datei des STRATO Debians beibehalten. Wenn man einen anderen DNS-Server aus dem Internet (z.B. CloudFlare oder Google) setzen möchte, kann dort die IP-Adressen der Server eingetragen haben.
Im Kapitel 04 wurde gezeigt, wozu die serielle Konsole sinnvoll ist und diese für VirtualBox als VE getestet. Jedoch war mein rat nach dem Test vorläufig die serielle Konsole wieder zu
deaktivieren. Wer das so getan hat, sollte diese nun wieder aktivieren.
In der Datei /etc/default/grub wurden die Einträge GRUB_CMDLINE_LINUX_DEFAULT , GRUB_SERIAL_COMMAND und GRUB_TERMINAL auskommentiert für den Upload belassen und eine Zeile (Kernel Parameter) lediglich für die Variante ohne Konsole kopiert und geändert hinterlassen. Nun wird wieder alles umgestellt.
Die Zeile mit den Kernel Parametern muss nun wieder die Werte für die serielle Konsole enthalten und die beiden anderen Zeilen müssen ohne Kommentierung da stehen. So wird diese Datei gespeichert.
Um die Änderung zu übernehmen, ist das ausführen des Befehls update-grub nötig. Eventuell wird man nun zwischendurch gefragt, wo Grub2 installiert werden soll. Das liegt an der neuen
Installation auf dem Server. Hier in dem Fall einfach das gleiche Gerät auswählen, auf dem man vorher das Image von zu Hause hat schreiben lassen. In meinem Fall war das die SSD, also "dev/sda".
Ich empfehle im Server-Login den Konsolen-Server zu aktivieren und den SSH Befehl zum Verbinden, der im Server-Login angezeigt wird, zu verwenden. Man kann so gleich testen, ob die Einstellungen zur Konsole korrekt sind, und sieht den
Server starten. Falls dabei bereits etwas nicht passt, sieht man es gleich. Weiterer Hinweis: Den Konsolen-Server Zugang im Server-Login wieder deaktivieren, nachdem man fertig ist und die Konsolen-Shell mit exit beenden!
Nachdem die oben gezeigten Änderungen Nachgezogen wurden, kann der Server nun endlich das Proxmox OS starten. Ist man noch im "chroot" wird dieses mit einem exit verlassen und alle mount Befehle von oben in der Umgekehrten Reihenfolge mit einem umount /....../..... zurückgenommen. Nun im Server-Login unter "Rescue OS" zurückstellen auf "Standard Betriebssystem". Bitte hierbei bei der unteren Einstellung "Kein Hard-Reboot" verwenden, damit die Proxmox installation nicht beschädigt wird. Ferner im SSH angemeldet bleiben. Man muss wieder 1-10 min. warten, bis die Umstellung erfolgt ist. Sobald der Server-Login die Umstellung als erfolgt anzeigt, mit einem reboot den Server neu starten lassen. Nun sollte dieser das Proxmox OS starten und man sollte auf der seriellen Konsole sehen, dass der Proxmox nun unter Hostname und Port 8006 erreichbar sei. Das stimmt nur fast, denn im Kapitel 03 wurde die Firewall so eingestellt, dass nur per SSH zugegriffen werden kann. Stellt man wie in diesem Kapitel gezeigt die SSH Konfiguration für den Server auf den Hostnamen des "echten" Servers, sollte man sich a) per SSH verbinden können und sodann auch b) auf "https://localhost:8006" zugreifen können. Dann ist der Proxmox auf dem Server bei STRATO angekommen.
Mein erster Server hatte neben der SSD auf der nun der Proxmox installiert war auch zwei Festplatten. Diese sind so vorgesehen als RAID Verbund und als Soft-RAID aufgesetzt gewesen. Ich habe die Festplatten für die VMs vorgesehen. Da die von der vorherigen Installation bereits als Soft-RAID mit einem ext4 Dateisystem eingerichtet sind, muss ich diese neu Formatieren. Man kann zwar auf ein einfaches Dateisystem auch VMs installieren, aber das ist nicht die bevorzugte Variante. Das Linux-MD-RAID ist auch nicht empfohlen. Jedoch ist es für Festplatten in einem Server empfohlen, die Festplatten im RAID zu betreiben. Es gibt eine Möglichkeit die Festplatten mit zfs zu Formatieren und diese im RAID zu haben. Hierbei wird "zfs-mirror" gemeint. Der Einsatz von zfs wird auch von Proxmox unterstützt und lässt sich einfach über die Weboberfläche einrichten.
Das Formatieren der Festplatten geht aus dem Proxmox heraus. Das unangenehme dabei ist natürlich, dass man Aufpassen muss, welches Linux Gerät man auswählt. Typischerweise macht einem das Setup einfach, da die Festplatten im
Normalfall gleich groß und üblicherweise die gleichen Modelle sind vom gleichen Hersteller. Im Bild 5 ist die Übersicht über alle Geräte zu sehen. Man kommt zu der Ansicht, in dem man links den Proxmox Server in
der Baumstruktur anwählt und im Nebenmenü "Disks" anklickt. Man erkennt die SSD mit dem OS nicht nur an ihrem verräterischen Bezeichner. Die vorhandenen 3 Partitionen (BIOS-Boot, EFI, LVM) geben den Hinweis, dass
auf der Disk das Proxmox OS installiert ist. Die Platten haben jeweils nur eine Partition.
Man wählt nun jeweils die Festplatte an (nicht ggf. erkannte Partitionen, also "/dev/sdb" und "/dev/sdc") und drückt pro Festplatte über der Tabelle auf den Button "Formatieren". Man wird noch
einmal zur Sicherheit gefragt, ob man sich sicher ist. Wenn man das Bestätigt, wird das aus dem alten STRATO Image stammende Linux-MD-RAID mit samt alter Partition entfernt. Etwas neues angelegt wird noch nicht. Eine neue
Partitionstabelle anlegen muss man nicht extra. Das passiert im nächsten Schritt automatisch.
Ist im Seitenmenü bei "Disks" das Submenü aufgeklappt (kleines Dreieck) findet man unten "ZFS" und klickt drauf. Man wechselt auf einen am Anfang noch leeren Tabellenbereich wo oben drüber wieder Buttons sind. Mit einem Klick auf den Button "Erstelle: ZFS" kommt man zu dem Dialog aus Bild 6. Dieser hat wieder eine Tabelle und sollte (im Gegensatz zum Bild) unten die Festplatten anzeigen. Beide werden per Haken ausgewählt und bei der Einstellung "RAID-Level" wird "mirror" eingestellt. Somit hat man ein klassisches RAID-1, wie es vorher auch war, nur auf ZFS Basis. Nur wer Erfahrungen mit "RAIDz" hat und es aus bestimmten Gründen möchte, kann es natürlich dort auch auswählen. Bei "Name" wird eingetragen, wie das ZFS (und damit der Proxmox Storage) heißen soll. Die anderen Einstellungen habe ich belassen und bestätigt. Dann legt Proxmox auf den Platten GPT Partitionierung an und erstellt aus beiden den ZFS Pool mit mirror. Danach sieht die "Disks" Tabelle in etwa so aus, wie in Bild 5. Nun kann man VMs, Container, etc. auf den Festplatten speichern.
Zum Zoomen klicken.
Bild 5: Disk Tabellenübersicht des Proxmox Servers
Bild 6: Dialog von Proxmox zum Anlegen eines neuen ZFS