rsync vmdk?

[sgw]

Ich hab eine etwas größere VM unter einem alten ESXi laufen, die ca. 1.6 TB hat. Die Strecke zwischen PVE und ESXi kann aktuell nur 1 GBit/s, dh. ein Import wird einige Stunden dauern (Spätschicht für mich).

Würde es auch klappen, wenn ich die vmdk bereits jetzt im laufenden Betrieb per rsync vorab zu syncen beginne, um dann bei der tatsächlichen Migration nur noch die letzten Changes syncen zu müssen? Vermutlich etwas heikel, aber vielleicht gar nicht so problematisch.

hints welcome ;-)

Ja, ich lese https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Attach_Disk_&_Move_Disk_(minimal_downtime)

 

[sgw]

Ich finde dazu grade das hier: https://www.saturnme.com/zero-downtime-vmware-to-proxmox-ve-9-migration-step-by-step-2025-guide/

und sehe noch nicht ganz, wo er das initiale syncen macht ... mal schauen // EDIT: ah, ich verstehe ... wobei mir der abschliessende Sync da noch nicht ganz klar ist, wie der aussehen soll

 

[sgw]

Und ich knoble grade dran herum, wie ich diese Pipe in ein LV schreiben lasse, statt in ein qcow2-file.
Ich hab lokal den Platz nicht, nur im "LVM-Thin" Storage (außer theoretisch im RAM ).

Das Beispiel von dem verlinkten Artikel schickt das konvertierte Image über ssh an den PVE:

qemu-img convert -f vmdk -O qcow2 /vmfs/volumes/datastore/vmname.vmdk - | ssh root@proxmox "cat > /var/lib/vz/images/101/vm-101-disk-0.qcow2"

Wobei hier auch schon mal die Voraussetzung ist, dass der PVE (mit dem Binary `qemu-img`) auf das vmdk zugreifen kann.

Und wie soll der Sync am Schluss aussehen? Was genau soll da gesynct werden? Wenn ich das vmdk file synce, ändert sich ja nix am qcow2, und wenn ich den Befehl neu starte, geht's ja wohl von vorne los.

Hm, das fühlt sich noch nicht so safe an alles.

 

[sgw]

@news Danke für den Input .. ist hier aber off-topic.

 

[news]

Nun mein Weg wäre auf beiden Seiten 10 GBit/s Datenstream zu haben, dann die VMWare Datendisk "vmname.vmdk" in eine ZFS Datenset überleiten. Darauf kann ich nun zugreifen.
Am Ende der Zeit, kann man auf dem VMWare System ein Rsync aus dem System auf das Proxmox VE Zielsystem mit dem ZFS Datenset machen.

Auch wäre der Weg evtl. über clonezilla lokal VMWare auf ein clonezilla im Netz, auf einem Proxmox VE, denkbar.
Habe ich schon gemacht.
Damit stünde dann alles während der Datenübertragung still.

 

[sgw]

@news Danke für den Input.

Aber das ist eben leider nicht meine Ausgangs-Situation. Hätte ich bereits 10GBit/s im ESXi, wäre das alles deutlich einfacher, dann wäre der Import einfach und schnell. Mit 1GBit/s rechne ich nach Erfahrungswerten mit vielleicht 3-5 Stunden Transfer.

Die Downtime ist dort angekündigt (klarerweise abends ...) und vermutlich ist das der entspannteste Weg, schlicht den Import in der GUI anzuwerfen und abzuwarten ...

Ich bräuchte halt alternativ einen Weg, um aus der vmdk am ESXi (die noch in Betrieb ist), vorab bereits eine VM Disk im LVM-Storage am PVE vorzubereiten .. mit einem abschließenden schnellen Sync.

Ein NAS hab ich noch im Zugriff, von ESXi und PVE aus, aber auch ein altes mit nur 1 GBit/s ... (aber dort wäre ausreichend Platz)

 

[sgw]

Um 17h kann ich den "normalen" Import anwerfen, also wird es mehr und mehr zur theoretischen Frage ;-)

Ich habe hier in einem Kommentar (höflich! klar!) nach Details gefragt, der wurde ohne Kommentar einfach gelöscht.
Auch interessant. Vielleicht ist das auch so eine Art KI-Idee ... ich bin da ja noch skeptisch, weil das ja kein klassischer Sync sein kann bei einer Konvertierung.

Aber klarerweise würde mich eine Lösung interessieren, rein technisch/sportlich.

 

[micneu]

@sgw warum hat dein ESXi kein 10Gbit/s die meisten Server, die ich kennen haben doch Heute Standard mäßig 10Gbit/s.

Selbst mein kleiner Proxmox hat 10Gbit/s
ist dein Setup im Privaten oder geschäftlichen Bereich?

 

[sgw]

Reformstau beim Kunden, deswegen soll der ESXi ja auch weg.
Tut doch nix zur Sache, ist eben die Situation so.

 

[waltar]

Der "saturnme" link in Post #2 ist ja kostlich - selten so gelacht beim Lesen der vielen Beispiele, insbesondere das Nachsyncen einer bereits pre-umkonvertierten Datei, ein Veeam Vollrestore in unter 2min etc, Einfallsreichtum haben sie, das muß ihnen/der Webseite lassen ...

 

[sgw]

Der "saturnme" link in Post #2 ist ja kostlich - selten so gelacht beim Lesen der vielen Beispiele, insbesondere das Nachsyncen einer bereits pre-umkonvertierten Datei, ein Veeam Vollrestore in unter 2min etc, Einfallsreichtum haben sie, das muß ihnen/der Webseite lassen ...

Reihe ich auch eher als Nonsense ein ... sorry, sowas verlinkt zu haben

 

[waltar]

Aber du kannst eine vm auch erstmal im .vmdk format auf einem pve benutzen (initial +last-sync) und später on-the-fly im pve zu raw/qcow2 umziehen.
Bei einer Optimierung eines Vollumstiegs sollte man sich immer erstmal bewußt machen, wo der größte Engpass ist (cpu, I/O, Netzwerk) und danach die beste Umzugsstrategie wählen, zB Umkonvertieren immer auf neuerer cpu, bei rsync ´(file storage) per ssh ist man idR immer bei 100% cpu, wenn man mehr als 1Gbit Netzwerk hat und deswegen zu nfs mit intial "cp" und entweder abschliessendem inplace rsync oder gesplittetem parallelen rsyncs greift etc.

 

[sgw]

@waltar gute Tips, danke. Ich bin grad im ersten Versuch mit dem naiven ESXi-Import am PVE. Könnte sich ausgehen bis morgen früh, ist aber definitiv nicht optimal so. Der ESXi ist in ziemlich allen Belangen ein Engpass

 

[waltar]

Ich bin grad im ersten Versuch mit dem naiven ESXi-Import am PVE.

Du meinst wohl hoffentlich eher mit der nativen ESXi Import ...

 

[sgw]

Du meinst wohl hoffentlich eher mit der nativen ESXi Import ...

Beides: ich bin so naiv, es mal ohne extra Maßnahmen einfach so zu versuchen.

 

[sgw]

Erfolg um 2:20h .. VM bootete problemlos, Umbau auf Virtio klappte auch wunderbar.
Guten Morgen allen (später ).