Ich habe folgendes Problem: Wir haben einen dedizierten (Bare Metal) Hardwareserver (Debian 10), auf den wir keinen direkten physikalischen Zugriff haben. Nun möchte ich alle Daten und Anwendungen, die auf diesem Server liegen, auf eine VM übertragen und diese auf einem KVM-Host ausführen.
Warum installiere ich die Anwendung nicht direkt in der VM? Die Installation dieser Anwendung (Perl-Zeug mit Apache-Webserver, läuft seit ca. 10 Jahren auf demselben Server) ist so komplex, dass man lieber etwas kaputt machen würde. Deshalb traut sich niemand. Aber jetzt müssen wir umziehen und aus diesem Grund brauchen wir irgendeine Art von cleverem Workaround.
Ich habe darüber nachgedacht, alle Perl- und Apache-Dienste abzuschalten und die Festplatte über dddas Netzwerk zu übertragen – das Problem besteht jedoch darin, dass der Ziel-KVM-Host weniger Speicherplatz hat als sdader Bare-Metal-Server groß ist (letztendlich verwendet er weniger Speicherplatz als verfügbar ist, sdaist also einfach überdimensioniert).
Die zweite Möglichkeit wäre, die gleichen Pakete mit exakt den gleichen Versionsnummern (gemäß dpkg --list) auf dem KVM zu installieren, alle Dienste auf dem Bare-Metal-Server zu deaktivieren (um die Datenkonsistenz zu wahren) und /etc, /var/, /usrund alles andere Wichtige vom Bare-Metal-Server in ein Tarball zu packen und dieses dann einfach auf dem KVM zu entpacken. Natürlich könnte ich das auch über rsync machen, aber das Prinzip ist mehr oder weniger dasselbe.
Was halten Sie von der letzten Idee?
Habt ihr noch weitere Ideen?
Wie würden Sie bei einer solchen Aufgabe vorgehen?
Antwort1
Alsanxhat mich gebeten, es zu tun, ich werde meine eigene Frage beantworten :) Meine Lösung war nicht so ausgefeilt undanx's, aber ich möchte es trotzdem mit Ihnen teilen.
Tatsächlich habe ich zunächst die Inode- und Blockgrößen auf beiden Dateisystemen überprüft, um sicherzustellen, dass sie identisch sind (mithilfe von tune2fs).
Dann habe ich alle Dienste deaktiviert, außer den existenziellen wie SSHd.
Nachdem ich das getan hatte, entschied ich mich, die Pakete und Binärdateien zu verwenden apt-cloneund nicht von einer Maschine auf eine andere zu kopieren:
# on the physical machine:
apt-get install apt-clone
apt-clone clone packages
# on the virtual machine:
apt-get install apt-clone
apt-clone clone packages.apt-clone.tar.gz
# check on the VM:
vimdiff <(dpkg --list) physical_mchine_packages.txt
Als nächstes habe ich die Daten mit synchronisiert rsync. Die Verzeichnisse, die ich synchronisiert habe:
/root/etc(Ich habe Dateien wiehostname,fstab,/default/grub,/network/interfacesund eine Reihe anderer Verzeichnisse im Zusammenhang mit Kernel/Initram/LVM ausgeschlossen.)/usr(nicht alle, hängt von der verwendeten Software ab)/var(nicht alle, hängt von der verwendeten Software ab)
Der letzte Schritt bestand darin, zu überprüfen, ob der Hostname oder die IP-Adresse der alten physischen Maschine in einigen Konfigurationsdateien eingetragen ist:
find . ! \( -path "*proc*" -o -path "*sys*" -o -path "*var/mail*" -o -path "*var/spool/mqueue*" -o -path "*var/log*" \) -type f -exec grep -iH -- "x.x.x.x" {} \;
Das ist alles. Alles funktioniert jetzt in der VM. Ich hoffe, ich konnte irgendwem helfen :)
Antwort2
(Diese Antwort diskutiert dieBlockgeräteebeneAlternativ ist es am besten geeignet, wenn Sie die Partitionierung und die Boot-Manager-Konfiguration bei der Migration auf virtuell beibehalten möchten)
Das von Ihnen beschriebene Problem tritt in der Praxis nicht unbedingt auf.versehentlichdies kürzlich vermieden:
Das Problem ist jedoch, dass der Ziel-KVM-Host weniger Speicherplatz hat als der SDA vom Bare-Metal-Server
Es ist vollkommen zulässig, Partitionen in einemspärlichDatei, die (sogar wesentlich) größer ist als das Host-Dateisystem – solange Sie nicht tatsächlich Daten in die übersprungenen Bereiche der Datei schreiben.
Ich habe ungefähr Folgendes gemacht fstrim / && systemctl stop appserver && mount -o remount,ro / && sync && dd bs=64k if=/dev/nvme0n1 | ssh vmhost dd bs=64k conv=sparse of=..: . Dann losetuphabe ich das Image auf dem VM-Host verfügbar gemacht fdiskund resize2fsseine (virtuelle) Größe geändert. Da das Image an den meisten Stellen bereits nur Nullen enthielt, haben meine Operationen seine tatsächliche Größe nicht wesentlich vergrößert.
Der Speicherplatzbedarf für diesen einfachsten Ansatz würde im schlimmsten Fall dreimal so hoch sein wie der Dateninhalt des alten Servers. Einmal, um das Sparse-Image zu kopieren, einmal, um die Größe zu ändern (d. h., um den gesamten Inhalt an den Anfang zu verschieben, ohne neue Löcher in das Ende zu stanzen) und dann noch einmal, um das Raw-Disk-Image in das Format zu konvertieren (oder um das dann dateibasierte Image auf sein eigenes logisches Volume zu verschieben), das von der Verwaltung der virtuellen Maschine verwendet wird.
Einige Dinge, die Sie beachten sollten:
- Die Art und Weise, wie Sie diesen Vorgang durchführen, sollte von der Software / dem Setup der geplanten Virtualisierung abhängen (wenn Ihr aktuelles System beispielsweise über EFI bootet, Ihre Virtualisierung dies jedoch nicht bevorzugt, welchen Sinn hat dann die Durchführung einesDatenträgerkopiewann müssen Sie Bootloader-bezogene Dinge sowieso wiederholen?)
- fstrim (insbesondere in Kombination mit fehlerhaften SSDs oder RAID) kann gefährlich sein und Datenverluste verursachen. Wenn Sie nicht sicher sind, ob dies bei Ihrem Setup ein sicherer Vorgang ist, führen Sie die folgenden Schritte aus.Schreiben einer riesigen Datei, die nur Nullbytes enthältAlternative: Uns ist nur wichtig, dass nicht verwendete Bereiche erkannt werden (auf Null gesetzt werden), nicht, ob die Festplatte davon Kenntnis hat.
- Durch einfaches Setzen des root-readonly wird die Arbeit erledigt, aber das Ergebnisals ob der Server vor dem Neustart auf der virtuellen Maschine abgestürzt wäre. Wenn Sie das Image kopieren, nachdem Sie Ihre Anwendungen beendet haben, kann diesgut genug: Schließlich gehen Sie davon aus, dass Ihr Server auch nach einem Absturz weiterarbeiten kann.