Nein es geht nicht ums Prinzip, da nicht jede Virtualisierungslösung eine Konvertierung bietet. VMware hat so einen Converter aber auch das geht nicht völlig nahtlos. Starten der Konvertierung und irgendwann musst du Bleck herunter und VM hoch fahren. Aus Erfahrung kann ich dir sagen, dass Datenbanken und Linux und der VMware Converter Glückssache sein können.
Warum du als Programmierer den Job eines Admins machst will ich gar nicht wissen aber vermutlich warst du einfach der Dienstleister mit dem billigsten Angebot
Anstatt die komplette VM zu klonen/migrieren würde ich die Dienste umziehen. Das lässt sich ggf. schneller/besser realisieren.
Wenn es sich wirklich um eine DB wie z.B. mariadb oder mysql handelt könntest du zwischen Blech und neuer VM einen Cluster einrichten. Musst natürlich vorher testen ob du eine bestehende Instanz zu einem Cluster umwandeln kannst. Falls ja: Cluster einrichten, jetzige IP des Systems zur virtual (floating) IP des Clusters ändern wobei auch das schon eine kurze Dienstunterbrechung von ein paar Sekunden bringen kann aber natürlich testest du dies vorher als gewissenhafter Dienstleister. Wenn der Zugriff über die Cluster-IP funktioniert und die Replication zur neuen VM steht machst einen klassischen Failover und die VM wird der neue Master. Dann wieder den Cluster "zurück bauen", ggf. erneute kurze Dienstunterbrechung.
Hast du außer der VM mehrere Dienste ist vermutlich pacemaker/corosync die bessere Wahl wobei du da noch irgendwie den Storage syncen musst. DRBD wäre eine Option aber nicht mehr nachträglich. Aber auch corosync/pacemaker hat beim Schwenk eine kurze Downtime.
Oder eben eine VM parallel aufsetzen mit anderer IP, Daten per rsync over ssh migrieren, Datenbank per sql-dump. Migrationszeitpunkt bzw. Fenster bestimmen und vorher regelmäßig Daten wieder syncen sodass nur noch ein kleiner Diff da ist. Wenn Migration erfolgen soll: Stopp der laufenden Dienste auf altem Server, erneuten sql-dump & rsync und wenn alles i.O. ist alten Server herunter fahren oder Netzwerk abklemmen und an neuer VM die IP des alten Servers sowie Hostname übernehmen. Lässt sich in vielen Teilen verskripten sodass man die Downtime auf vermutlich 5 Minuten oder weniger drücken kann aber es wird sie geben.
Grundsätzlich musst du dem Auftraggeber jedoch klar machen, dass man einen einzelnen physikalischen Server niemals mit zero Downtime betreiben kann und er dies einsehen muss(!). Alle anderen, die dies versprechen verkaufen ihm Luftschlösser oder machen dies nachts um 3 Uhr "heimlich" und schieben es auch andere Dinge sollte es auffallen, z.B. "Netzwerk" oder "Backup" als Ausrede.
Überlege dir einen Weg, teste diesen, schlage dies dem Auftraggeber am Ende vor, weise explizit auf kurze Unterbrechung hin und lasse dir dies schriftlich oder per Mail bestätigen.
edit: Jetzt erst gesehen, dass es nur zum testen ist und keine Migration geplant ist. Dann nimm das letzte Backup und mach eine Wiederherstellung in eine VM (ohne Netzwerkadapter). Nach Restore per Konsole die IP ändern, dann Netzwerkadapter hinzufügen/aktivieren. Gibt es kein Backup dann bleibt dir nur eine neue VM erstellen, sprich altes SUSE 11 ISO besorgen, per zypper oder rpm alle installieren Pakete im Server anzeigen lassen und auf deiner VM installieren, Daten per rsync over ssh holen und von der DB einen Dump ziehen, ebenfalls per rsync zur VM bringen, Dump importieren. Vom DB-Serverdienst Config prüfen auf welcher IP der ggf. starten will und sonstige Parameter wie hostname, permissions, etc. usw. anpassen.
![[ChAoZ]](https://pics.computerbase.de/forum/avatars/s/491/491529.jpg?1618073566){kind=avatar}
