Performance ESXi Importer

[Falk R.]

Hi,
gibt es hier Leute, die ihre Erfahrung mit der Performance des ESXi Importer teilen können?

In meiner kleinen Testumgebung läuft es OK, was vermutlich von den günstigen SSDs gebremst wird.

Ich habe bei zwei Kunden versuch mittels dem ESXi Importer zu migrieren, aber das haben wir aufgrund der schlechten Performance verworfen.
Ein Beispiel: Eine kleine VM mit 60GB hat zum migrieren 50 Minuten gebraucht und eine Livemigration war nicht benutzbar.
Zur gleichen Zeit habe ich auf einem zweiten identischen Host eine 2,2 TB VM ganz klassisch über den NFS Migrationsweg in 40 Minuten migriert.
Das Verhalten war mit einer weiteren VM auf dem zweiten Host, welcher schnell kopiert hatte, identisch.
Ich habe das bei einem Kunden mit aktuellen Xeon Scalable 4th Generation und beim anderen Kunden auf Epyc Zen3 getestet. Beide male hatten wir auch schnelles Netzwerk, einmal LACP mit 2x 10 GBIt und einmal LACP mit 2x 25 GBit. Da der klassische Weg über NFS schnell funktioniert, schließe ich mal die Hardware aus.

Wie ist denn eure Erfahrung?

 

[Der Harry]

Ich habe den ESXi export beim ersten Mal auch total und vollkommen unterschätzt.

Wir hatten viele TB Daten, die wir von Frankfurt nach Helsinki kopiert haben.

- wir haben das ohne den Proxmox Importer gemacht (der ist immer noch nicht 1000%)
- wir haben die VMs auf ESXi kopiert (jeweils immer eine, mit VMware Tools, mit entsprechendem Platz) und haben die erstmal einzeln mit rclone/rsync kopiert
- alleine dieses Kopieren hat ~ 1.5 - 2 Tage gebraucht.

Im nächsten Step haben wir einen Plan gemacht wie wir migrieren wollen (und wo man ggf. IPs, Netze, ... umbiegen muss)

- dann jeweils eine Maschine herunterfahren
- nochmal rsync/rclone gegenüber dem Teil auf dem Proxmox machen, der schon mal geklont war (90% hatten wir ja schon kopiert)
- dann auf Promox alle Maschinen mit einem Script (analog diesem hier anlegen: https://forum.proxmox.com/threads/m...oxve-8-with-nfs-data-store.146900/post-663342)

Erfahrungen:

- man muss rsync auf Proxmox kompilieren - dafür gibts nen Docker container (ping mich an wenn du das brauchst)
- kopieren über HTTPS ist (ggf) schneller wie scp/rclone/rsync - das ist aber (meiner Meinung nach) ein "alles oder nichts"... wenn zwischendrin mal dein Netz 5min zickt (Redo from start...)
- der Proxmox Importer ist eine der genialsten Marketing Maßnahmen der Proxmox GmbH - das Prädikat "funktioniert immer und für alles" bekommt es von mir nicht.
- Wenn du Skripten kannst, bist du immer flexibler. Bei Windows VMs musst du extrem viel mehr den Affen machen, wie bei Linux VMs. Der Proxmox Importer hat nicht den Anspruch Windows zu verbessern

Ich ESXi -> NFS -> Proxmox ist im lokalen Lan fixer (hatten wir aber nicht).

Je nach Storage Konzept (wenn du die VMs auf lokalen Platten haben willst) kannst du natürlich auch (nur zum kopieren von den ESXi VMs) auch einen lokalen Proxmox NFS aufmachen (oder in einen LCX Container). Du musst ja nur die GBs über das Lan rüber bekommen.

- 60GB direkt per NFS kopieren (und dann die VM manuell anlegen) ist 1000x fixer.


Ach ja VMs in ESXi immer herunterfahren (ggf. einfach die ESXi VM auf ESXi klonen und die dann herunterfahren).

Pitfalls waren bei der "qm import" Methode VMs mit snapshots. Die mussten wir auf ESXi löschen.

 

[Falk R.]

Ich migriere seit Jahren mit der zuletzt in die Doku aufgenommene Methode über NFS. Das funktioniert immer sauber, aber die VM Hüllen zu bauen und die Pfade auf der CLI anpassen, kostet schon etwas Zeit und bei mehreren Hundert VMs ist das nervig.
Ich bekomme mit meinen geringen Scripterfahrungen leider das ganz nicht automatisiert. Eine Mischung aus dem Migration Wizard und der NFS Methode wäre genial.
Falls jemand sagt, soetwas lässt sich einfach Scripten, ich unterstütze gerne und teste das auch.

 

[Der Harry]

Ich bekomme mit meinen geringen Scripterfahrungen leider das ganz nicht automatisiert. Eine Mischung aus dem Migration Wizard und der NFS Methode wäre genial.

Das müsste Proxmox machen.

Der Wizard müsste ja wissen "Hei, zieh die Daten nicht über https://esxi.... herunter - sondern - die identische VM ist unter /mnt/nfs <esxi> und unter /mnt/miezekatze/nfs <proxmox>".

Good luck bei dem Feature Request - ggf. arbeitet jemand schon an dem. Hypothese - als Produktmanager würde ich maximal noch Bugfixing an dem aktuellen ESXi Konverter machen - warum? Ab 2025 sind entweder alle alten ESXi kunden migriert oder explodiert (sorry...)

Wenn du 500 Maschinen hast, könnte man sich da schon hinsetzen und etwas entwickeln:

- "Spezfifikation der ESXi VM -> Proxmox QM create Komandos"
- cp / qemu-img convert -f vmdk ... aufrufe

Ideal wenn man das auch parallelisieren könnte oder nur ein Tool hätte was die Skripte dafür schreibt.

Mir schwebt etwas mit n8n (https://n8n.io/) vor, damit man "sieht" was der macht und damit man eingreifen kann.

Das ist nicht Rocket Sciences. Ich habe kein Stress soetwas zu entwickelen, wenn ihr Digitale Schmerzen (entsprechender Größe) habt.


"Opensource" dürberschreiben - hätte auch was. "Brauchen" tu ich es gerade nicht für meine Needs, weil wir immer rclone/rsync machen.

Schreib mich einfach mal an.

 

[Falk R.]

Ich betreue viele mittelständische Unternehmen. Da ist selten eine VM wie die andere. Die Kunden mit bis zu 60 VMs migriere ich an einem Tag, aber bei einem Kunden mit 500 VMs zieht sich das schon gewaltig. Ich möchte auch keine Bastellösung für mich, sondern gern was richtiges für jedermann.
Eventuell kennt ja jemand einen Trick wie der importer etwas schneller wird.

 

[Der Harry]

Ich betreue viele mittelständische Unternehmen. Da ist selten eine VM wie die andere. Die Kunden mit bis zu 60 VMs migriere ich an einem Tag, aber bei einem Kunden mit 500 VMs zieht sich das schon gewaltig. Ich möchte auch keine Bastellösung für mich, sondern gern was richtiges für jedermann.
Eventuell kennt ja jemand einen Trick wie der importer etwas schneller wird.

1) Der Importer arbeitet auf dem https:// - der kann nicht wissen, schmecken, riechen, hören oder erkennen - dass der Storage Punkt ggf. noch einem Proxmox Rechner noch "anders" erreichbar ist.

2) Das hier einzubauen ist auch schwierig - weil - der ESXi ja ein "vSphere Client" aus VMWare sicht sein kann.

Du hast keine Möglichkeit zu riechen/schmecken/hören ob der konkrete ESXi A auch das gleiche nfs dingens gemountet hat wie ESXi B.

3) Meinung: Der Marketing Aspekt "ESXi Importer" ist höherprior intern bei Proxmox wie der Aspekt "Realworld Edgecases" bei (Semi-)Professionellen Anwendern. Im Prinzip sparst du dir ja "nur" Zeit.


Würde man hier jetzt ein Tool bauen, dass per SSH mit den einzelnen ESXi Servern kommuniziert, könnte man ggf. unter Zuhilfename des ESXi Codes / qm generators / VMWare Machine Parsers - das Problem lösen. Ich würde da nicht nur NFS machen, sondern auch den Teil rsync/rclone mit einbauen. Ggf. will man ja nicht "nur" von ESXI -> Proxmox sondern hat hier komplexere Szenarien.


Wie gesagt - ich kann sowas bauen - ich brauche es nicht. Vermutlich wirst es von Proxmox nicht bekommen (weil die "generische" Lösung betriebswirtschaftlich irrelevant ist - sie spart ja nur DEINE Zeit und bringt nicht mehr Kunden).






(Bild von hier: https://docs.vmware.com/de/VMware-vSphere/index.html)

 

[Falk R.]

Wenn der Importer aber unbenutzbar langsam ist und daraufhin der Live Import nicht nutzbar, dann kostet das Kunden. In meiner Testumgebung bootet die VM in 2 Minuten, welche auf dem ESXi ca. 30 Sekunden gebraucht hat. Bei meinen Kunden waren das VMs die in unter 15 Sekunden starten. Als Live Import hat der Boot 10-30 Minuten gedauert und die VM war nicht benutzbar.
So ist der Importer nur Marketing ohne Nutzen und das will ja wirklich niemand.

 

[Der Harry]

Wenn der Importer aber unbenutzbar langsam ist und daraufhin der Live Import nicht nutzbar, dann kostet das Kunden. In meiner Testumgebung bootet die VM in 2 Minuten, welche auf dem ESXi ca. 30 Sekunden gebraucht hat. Bei meinen Kunden waren das VMs die in unter 15 Sekunden starten. Als Live Import hat der Boot 10-30 Minuten gedauert und die VM war nicht benutzbar.
So ist der Importer nur Marketing ohne Nutzen und das will ja wirklich niemand.

Meine Meinung dazu steht oben.

Der Marketing Aspekt - der Impact auf Entscheider "ESXi -> Proxmox j/n" wird durch "Es gibt einen ESXi importer" ja 100% bedient.

Der Anspruch "geht in 100% der Fälle und zu den Erwartungshaltung der Anwender" - ne das ist nicht der Fall

- > (Fun Fact - Office von Microsoft gibt es seit 1990 und da ist das auch nicht der Fall).


Das hier nicht die "optimale" beste NFS<->NFS Verbindung genommen werden kann (oder rsync/rclone/...) liegt am vSphere Endpunkt - nicht am Importer.

Ich mein wenn du wirklich digitale Infrastruktur machst - brauchst ja nicht mal den Importer Du schreibt deinen Ansible/Teraform Provider um. Der nimmt nicht mehr ESXi sondern Proxmox. Dann generierst du einfach deine VMs neu, kopierst die Daten und fertig. So sieht bei mir die Welt zu 99% aus.

 

[Falk R.]

In größeren Umgebungen läuft das so, aber der ganze Windows Leagacy Kram im Mittelstand kann man nicht automatisieren.
Deshalb brauche ich die VM Disks unverändert und das geht derzeit über NFS am besten. VMware supportet ja nur VMFS oder NFS.

 

[Der Harry]

In größeren Umgebungen läuft das so, aber der ganze Windows Leagacy Kram im Mittelstand kann man nicht automatisieren.
Deshalb brauche ich die VM Disks unverändert und das geht derzeit über NFS am besten. VMware supportet ja nur VMFS oder NFS.

Ja eben - was machst denn mit riesigen Clustern, die iSCSI Platten haben? Da musst dich dann Temporär per SSH einloggen und deinen NFS Rüssel aufmachen - oder halt rclone/rsync.

Das da niemand bei Proxmox diese Art von Converter zum Klicken bauen will, das verstehe ich halt schon

Wie gesagt - in 6-12 Monaten sind die ESXi Kunden alle umgezogen, verstorben oder im Zustand wo sie niemals den Converter brauchen.

 

[floh8]

Ein kleiner Wermutstropfen: Der Importer von xcp-ng zeigt auch Performanceprobleme. Man vermutet die VMWare-API ist schuld. Allerdings sind dort die Erfahrungswerte größer als 20 MB/s. Die liegen bei 100 MB/s und mehr.

 

[Der Harry]

Ein kleiner Wermutstropfen: Der Importer von xcp-ng zeigt auch Performanceprobleme. Man vermutet die VMWare-API ist schuld. Allerdings sind dort die Erfahrungswerte größer als 20 MB/s. Die liegen bei 100 MB/s und mehr.

Entweder du rüsselst es durch https durch oder durch scp.

- oder - du kannst nen nfs mount machen.

Den NFS mount kann keiner der Importer riechen, schmecken, hören, raten, regentanzen oder gläserrücken - Gründe stehen oben

 

[floh8]

Wenn man einfach die Platte abwählen könnte und nur die VM-Konfig generieren, wäre das wirklich schon eine Hilfe. Ich stimme Falk zu. Wenn schon sollte eine Lösung auch praktikabel sein. Eine einzige für alle Anwendungsfälle gibt es wohl nie.

 

[Der Harry]

Wenn man einfach die Platte abwählen könnte und nur die VM-Konfig generieren, wäre das wirklich schon eine Hilfe. Ich stimme Falk zu. Wenn schon sollte eine Lösung auch praktikabel sein. Eine einzige für alle Anwendungsfälle gibt es wohl nie.

Das Problem stellt sich bei mir in der echten Welt nicht! Wirklich.

Die VMs sind nicht alle "Mit Liebe individualisiert worden" sondern es gibt sie wie die Pommes bei Mc Donalds in

• Klein
• Mittel
• Groß

Dafür habe ich 3 Skripte. Fertig.

Die Platten der ESXi VM "ziehe" ich entweder mit rclone/rsync (über ssh) - oder ich drücke sie über rclone auf vmware / esxi dann auf "cloud speicher" - S3, CIFS, zur not verschlüsselt - macht Rclone alles). Das performed auch ganz ordentlich (die Threads von 4 auf 8 heben - https://rclone.org/docs/#transfers-n) und dann ist man am Limit der ESXi Physik oder am Limit vom Netz.

Wie gesagt - für 500 Maschinen, würde ich mit n8n (oder was ähnlichem) mir ein Tool bauen, das individuelle Pommes macht, skripte baut, ... Ich brauche das nicht. Wenn es jemand braucht gerne fragen, dann machen wir etwas das Opensource ist.

Die Skripte oder die VMs anpassen ist auch nie im Leben das Problem - bei mir war es immer die reine Kopierzeit der Daten. Die ist halt über über die Hardware und über das Netz limitiert. AUch der Plan wann welche VMs runtergefahren werde oder ggf. über ESXi clone erstellt werden (um dann nochmal final zu syncen etc.) da ist der Gehirnschmalz.

 

[Ramalama]

Der ESXI-Import Wizard, ist lahm das stimmt.
Nicht destotrotz hab ich mit dem ungefähr 20 VM's migriert über ein Wochenende. Sind so 8TB an Daten insgesamt.

Also gings doch trotz ersteindruck relativ schnell, was mir aufgefallen ist, das manche VM's lahm migrieren, andere wiederum schnell, das variiert etwas. Jedenfalls hab ich dann aber einen "Trick" rausgefunden....

Am Anfang hab ich auf jedenfall auch gedacht, kake das wird nix, ich muss nfs weg machen oder halt über ovftool migrieren.
Dann hab ich einfach noch einen Import gestartet und mir ist aufgefallen das der speed sich verdoppelt hat.
Also mit "btop" kann mann ja netzwerkspeed sehen.

Dann habe ich 6 VMs auf einmal mit dem Import-Wizard migriert und der transfer speed war ungefähr 5x schneller als nur mit einer VM.
Läuft auch alles seit 3 Wochen oder so Produktiv auf PVE, also war der Import auch erfolgreich.

Keine Ahnung womit das zusammenhängt, aber ihr solltet auf jedenfall mehrere VM's auf einmal importieren, wenns ein ESXI-Cluster ist, dann am besten gleich 2VM's pro Esxi-node.

LG

 

[Falk R.]

Das Problem stellt sich bei mir in der echten Welt nicht! Wirklich.

Die VMs sind nicht alle "Mit Liebe individualisiert worden" sondern es gibt sie wie die Pommes bei Mc Donalds in

• Klein
• Mittel
• Groß

Dafür habe ich 3 Skripte. Fertig.

Die Platten der ESXi VM "ziehe" ich entweder mit rclone/rsync (über ssh) - oder ich drücke sie über rclone auf vmware / esxi dann auf "cloud speicher" - S3, CIFS, zur not verschlüsselt - macht Rclone alles). Das performed auch ganz ordentlich (die Threads von 4 auf 8 heben - https://rclone.org/docs/#transfers-n) und dann ist man am Limit der ESXi Physik oder am Limit vom Netz.

Wie gesagt - für 500 Maschinen, würde ich mit n8n (oder was ähnlichem) mir ein Tool bauen, das individuelle Pommes macht, skripte baut, ... Ich brauche das nicht. Wenn es jemand braucht gerne fragen, dann machen wir etwas das Opensource ist.

Die Skripte oder die VMs anpassen ist auch nie im Leben das Problem - bei mir war es immer die reine Kopierzeit der Daten. Die ist halt über über die Hardware und über das Netz limitiert. AUch der Plan wann welche VMs runtergefahren werde oder ggf. über ESXi clone erstellt werden (um dann nochmal final zu syncen etc.) da ist der Gehirnschmalz.

Das ist deine Welt, aber die Welt der vielen Mittelständler da draußen, sieht genau anders herum aus. Da sucht man VMs die gleich sind.

 

[Falk R.]

Der ESXI-Import Wizard, ist lahm das stimmt.
Nicht destotrotz hab ich mit dem ungefähr 20 VM's migriert über ein Wochenende. Sind so 8TB an Daten insgesamt.

Also gings doch trotz ersteindruck relativ schnell, was mir aufgefallen ist, das manche VM's lahm migrieren, andere wiederum schnell, das variiert etwas. Jedenfalls hab ich dann aber einen "Trick" rausgefunden....

Am Anfang hab ich auf jedenfall auch gedacht, kake das wird nix, ich muss nfs weg machen oder halt über ovftool migrieren.
Dann hab ich einfach noch einen Import gestartet und mir ist aufgefallen das der speed sich verdoppelt hat.
Also mit "btop" kann mann ja netzwerkspeed sehen.

Dann habe ich 6 VMs auf einmal mit dem Import-Wizard migriert und der transfer speed war ungefähr 5x schneller als nur mit einer VM.
Läuft auch alles seit 3 Wochen oder so Produktiv auf PVE, also war der Import auch erfolgreich.

Keine Ahnung womit das zusammenhängt, aber ihr solltet auf jedenfall mehrere VM's auf einmal importieren, wenns ein ESXI-Cluster ist, dann am besten gleich 2VM's pro Esxi-node.

LG

Das löst aber nicht das Problem, dass eine einzele VM sehr lange zum migrieren braucht, was eine lange Downtime bedeutet. Bei den langsamen Übertragungsraten ist es auch nicht möglich den Live Import zu nutzen, wo die VM direkt auf PVE gestartet wird, wenn der Import beginnt.
Das läuft wiederum in meiner kleinen Testumgebung, aber nirgendwo auf Enterprise Hardware. Zumindest, diese welche ich in die Finger bekommen habe.