Anfängerfragen Storage und Netz - Migration von ESXi/Vcenter

philippms

New Member
Nov 6, 2025
4
1
3
Hallo zusammen,

ich hoffe ich nerve hier im Forum nicht mit absoluten Anfängerfragen, hoffe aber, dass man mir vielleicht die richtigen Google-Links geben kann. Ich habe schon einiges gesucht, aber die Frage ist immer, ob die Infos noch aktuell sind und ob sie auch im produktiven Umfeld gut performen und nicht nur auf einem Einzel-Host mit wenig Anforderungen.

Aktuell setzen wir VMWare ein mit 5 ESXi Hosts und 3 TrueNas (Core und Scale) Storages. Die TrueNAS-Datasets sind aktuell per (Multipath-)NFS mit den ESXi verbunden.

Was empfiehlt sich hier? Weiter NFS, auch wenn es wenn ich das richtig sehe unter Proxmox nicht Multipath und damit nicht redundant ist? Da wir auch noch TrueNas Core einsetzen (um Multipath mit VMWare zu nutzen) können wir auf den Filern das Proxmox-Truenas-Plugin wohl nicht nutzen, oder?

Zum Netz:

Jeder der ESXi-Hosts ist mit 2 NICs mit dem Intra/Internet verbunden und mit 2 NICs mit einem abgetrennten Netz mit den Storages.

Auf dem externen Netz liegen mehrere Netzbereiche per VLAN an, im internen abgetrennten Netz liegen einzelne VLANs an, die wir für VLANs für die Kommunikation unter einigen VMs nutzen.

Im VMWare hatten wir einen virtuellen Switch für die externe Kommunikaiton und einen für die interne Kommunikation, jeweils mit den beiden 2 NICs. Auf den Virtual Switches waren dann für jedes bediente VLAN eine Virtual Machine Port Group eingerichtet, jeweils mit einer der NICs als Haupt-NIC und die andere als Failover. (Wir haben keinen Konfigurations-Zugriff auf den Switch, echtes Port Bonding ist da nicht so einfach möglich).

Brauche ich für eine ähnliche Konfiguration unter Proxmox die OpenvSwitches oder geht das auch mit den nativen Network-Settings?
Wie ließe sich die Einstellung "je nach VLAN mal NIC 1 und mal NIC2, aber jeweils die andere NIC als Fail-Over" realisieren?

Vielen Dank vorab schon einmal für die Denkanstöße....

Viele Grüße
Philipp
 
Hi Philipp,

wir haben eine sehr ähnliche Umgebung hinter uns (Migration von VMware auf Proxmox VE 9, Storage über Pure Storage via iSCSI + Multipath). Ein paar Erfahrungen aus der Praxis, vielleicht hilft dir das bei der Einordnung:

Unter Proxmox funktioniert NFS weiterhin stabil, aber Multipath gibt es dafür nicht – das ist ein Limit des Linux-NFS-Stacks, nicht von Proxmox. Wenn du Redundanz brauchst, ist iSCSI + Multipath die deutlich bessere Wahl, wird nativ unterstützt und läuft absolut zuverlässig. Ceph wäre eine Alternative, ist aber für kleinere Setups schnell zu komplex. TrueNAS CORE kannst du mit Proxmox über klassische iSCSI-Targets problemlos anbinden; das TrueNAS-Plugin funktioniert nur mit SCALE wegen der API-Erweiterung.

Zum Netzwerk: Du brauchst nicht zwingend Open vSwitch. Für die meisten produktiven Umgebungen reicht die Standard-Linux-Bridge völlig aus. VLAN-Trennung funktioniert über VLAN-aware Bridges. Deine VMware-Failover-Logik („je nach VLAN mal NIC 1, mal NIC 2“) kannst du mit klassischem Bonding im Modus active-backup umsetzen. Das klappt ohne Switch-Konfiguration und verhält sich ähnlich wie deine Port-Group-Failover-Regeln.

Zu den neueren Features in Proxmox 9: LVM-thick unterstützt inzwischen Snapshots als Volume-Chain. Wir nutzen das aktiv auf iSCSI-Storage mit Multipath – funktioniert stabil, ist aber offiziell noch Tech Preview. Backups (vzdump) und Live-Migration sind davon unabhängig und vollständig unterstützt. In der Praxis läuft das Setup bei uns zuverlässig und performant, auch unter hoher I/O-Last.

Kurz gesagt:
– NFS läuft, aber ohne Multipath
– iSCSI + Multipath ist aktuell die stabilste Lösung mit TrueNAS CORE
– Linux-Bridges reichen in der Regel aus, OVS nur bei SDN-/VXLAN-Bedarf
– Snapshots als Volume-Chain sind nutzbar, aber noch kein GA-Feature


Viele Grüße
Jan
 
Cool, vielen lieben Dank für deinen Input, das hilft mir sehr weiter! D.H. du hast ein großes zvol per Dataset in Truenas dann per iSCSI freigegeben, von allen Hosts eingebunden und legst dann einzelne VMs in LVM-LVs an (über die Automatik in Proxmox)?

Zum Netzwerk: Du brauchst nicht zwingend Open vSwitch. Für die meisten produktiven Umgebungen reicht die Standard-Linux-Bridge völlig aus. VLAN-Trennung funktioniert über VLAN-aware Bridges. Deine VMware-Failover-Logik („je nach VLAN mal NIC 1, mal NIC 2“) kannst du mit klassischem Bonding im Modus active-backup umsetzen. Das klappt ohne Switch-Konfiguration und verhält sich ähnlich wie deine Port-Group-Failover-Regeln.

Die VMWare-Failover-Logik unterscheidet sich je nach VLAN. Wenn beide NICs Link haben soll er für das eine VLAN NIC1 nehmen, für das andere VLAN NIC2. Nur im Fehlerfall, soll er jeweils schwenken. Da habe ich mit dem Standard-Bonding das Problem, dass ein Interface ja in maximal einem Bonding konfiguriert werden kann...
 
Was ich jetzt als "schwierig" in der Umsetzung sehe, ist ganz klar der Punkt wie ihr euer Failover in VMWare gebaut habt und ob es portierbar ist.

1762864998836.pngStandardmäßig kannst du bei Proxmox ein
"Bond" (versch. Möglichkeiten) und darauf eine Bridge und darauf dann SDN-VLans setzen (was sehr komfortable ist)
GGf. hilft es hier den Bereich zu überdenken, sofern es die Anzahl an Interfaces zu lässt.

Mit den Bord-Eigenen Tools ist mir kein NIC-Teaming (ich meine so hieß das?) bekannt.

Wichtig ist nur: keine Bridge direkt auf zwei Interfaces legen und dann beide Kabel in einem Switch stecken - das gibt ein Loop.






kleine Randnotiz:
TrueNAS CORE wird vermutlich auf lange Sicht kein bestehen mehr haben, da IX ihr Truenas Scale ausbaut und auch seit 2021 keine (ernsthafte) Pflege mehr betreibt.
 
  • Like
Reactions: Johannes S
Cool, vielen lieben Dank für deinen Input, das hilft mir sehr weiter! D.H. du hast ein großes zvol per Dataset in Truenas dann per iSCSI freigegeben, von allen Hosts eingebunden und legst dann einzelne VMs in LVM-LVs an (über die Automatik in Proxmox)?

Ja, wir nutzen eine Pure-Station – der Ablauf ist aber ähnlich:
  1. iSCSI und Multipath installieren
  2. iSCSI-Initiatornamen (IQN) veröffentlichen und eintragen
  3. Multipath-Konfiguration prüfen und neue Geräte erkennen
  4. WWID-Alias in der Multipath-Konfiguration hinterlegen
  5. Physical Volume (PV) und Volume Group (VG) erstellen
  6. Über die GUI als LVM hinzufügen – dabei „Shared“ und „Snapshots aktivieren“ auswählen.

Den Failover würde ich dementsprechend nochmal wirklich überdenken. Aktuell nutzen wir Active Passiv als Bond (später LACP) mit Vlans und machen daraus eine Bridge die wir an die VMs durchreichen. Klappt super!

1762867431965.png
 
Zuerst einmal: Super vielen Dank an euch beiden, das beantwortet alle meine Fragen und hilft mir extrem weiter.

Das mit der Loop habe ich im Hinterkopf - das macht man tatsächlich nur ein einziges Mal ;-)

Die Migration von Truenas Core weg ist bereits angedacht. Aktuell noch unersetzbar wegen anständigem Multipath NFS unter VMWare, aber wenn da eh weg migriert wird....


@j.gelissen warum hast du denn Bonds mit nur einem Port jeweils?
 
  • Like
Reactions: Johannes S
Guten Morgen @j.gelissen,

nutzt du auch in deiner Konfig auch die "neuere" SDN-Funktion auf einer Bridge?
Oder hast du alle VLANS über die Interfaces abgebildet (pre Proxmox 8?), gibt es dafür ein Grund, das z.B. nfs/ iscsi nicht über SDNs geht?

@philippms
Die SDN Funktion kommt (wenn meine Erinnerungen noch passen) den Distributed-Switchen zumindest nahe.
Dabei muss zumindest die Namensgebung der Bridge - auf der du die SDN-Konfig ausrollst - identisch sein. Ob der Unterbau verschieden sein darf weiß ich jedoch nicht.
(sprich die BOND Konfig etc.)
Zusammengekürzte Konfig - die meinen Umständen entsprechend funktioniert, aber auf kein Fall "als gut" angesehen werden sollte und ebenfalls durch learning-by-doing entstanden sind.
bond10 nutzen die Proxmox für Backend & Backup (Hier würde ich auch NFS etc. sehen.
bond 20 ist VM- und Clientkommunikation
auf der vmbr0 sind die SDNs konfiguriert.
1762934417525.png

Danach kann man dann unter DATACENTER->SDN eine VLAN-Zone definieren
Bsp.:
1762934756824.png
Und dann ein VNET
1762934855649.png



Einfach mal aus dem blauen heraus - ich habe es NICHT getestet in Zusammenhang mit Multipath etc.
Ich nutze es grundsätzlich für die VM-Verfügbarkeit.
 
  • Like
Reactions: Johannes S
Hallo zusammen,

ich hoffe ich nerve hier im Forum nicht mit absoluten Anfängerfragen, hoffe aber, dass man mir vielleicht die richtigen Google-Links geben kann. Ich habe schon einiges gesucht, aber die Frage ist immer, ob die Infos noch aktuell sind und ob sie auch im produktiven Umfeld gut performen und nicht nur auf einem Einzel-Host mit wenig Anforderungen.

Aktuell setzen wir VMWare ein mit 5 ESXi Hosts und 3 TrueNas (Core und Scale) Storages. Die TrueNAS-Datasets sind aktuell per (Multipath-)NFS mit den ESXi verbunden.

Was empfiehlt sich hier? Weiter NFS, auch wenn es wenn ich das richtig sehe unter Proxmox nicht Multipath und damit nicht redundant ist? Da wir auch noch TrueNas Core einsetzen (um Multipath mit VMWare zu nutzen) können wir auf den Filern das Proxmox-Truenas-Plugin wohl nicht nutzen, oder?

Zum Netz:

Jeder der ESXi-Hosts ist mit 2 NICs mit dem Intra/Internet verbunden und mit 2 NICs mit einem abgetrennten Netz mit den Storages.

Auf dem externen Netz liegen mehrere Netzbereiche per VLAN an, im internen abgetrennten Netz liegen einzelne VLANs an, die wir für VLANs für die Kommunikation unter einigen VMs nutzen.

Im VMWare hatten wir einen virtuellen Switch für die externe Kommunikaiton und einen für die interne Kommunikation, jeweils mit den beiden 2 NICs. Auf den Virtual Switches waren dann für jedes bediente VLAN eine Virtual Machine Port Group eingerichtet, jeweils mit einer der NICs als Haupt-NIC und die andere als Failover. (Wir haben keinen Konfigurations-Zugriff auf den Switch, echtes Port Bonding ist da nicht so einfach möglich).

Brauche ich für eine ähnliche Konfiguration unter Proxmox die OpenvSwitches oder geht das auch mit den nativen Network-Settings?
Wie ließe sich die Einstellung "je nach VLAN mal NIC 1 und mal NIC2, aber jeweils die andere NIC als Fail-Over" realisieren?

Vielen Dank vorab schon einmal für die Denkanstöße....

Viele Grüße
Philipp
Hi, wenn du dein Netzwerk redundant aufbaust (LACP z.B.) dann brauchst du kein NFS Multipath, das funktioniert dann auch so sehr stabil.
Mit NFS4.1 kannst du über nconnect auch mehr Zugriffe parallelisieren. Wenn du jetzt NFS nutzt würde ich die von iSCSI unbedingt abraten, das erhöht die Komplexität extrem. Die Multipath Konfiguration musst du von Hand machen und auf dem Multipath Device das LV manuell erzeugen. Erst dann kannst du daraus einen Datastore bauen. Außerdem hast du in der GUI keinerlei Kontrollmöglichkeiten für das Multipathing. Wer das nicht schon ein paar mal gemacht hat, sollte produktiv die Finger davon lassen.
 
Guten Morgen @j.gelissen,

nutzt du auch in deiner Konfig auch die "neuere" SDN-Funktion auf einer Bridge?
Oder hast du alle VLANS über die Interfaces abgebildet (pre Proxmox 8?), gibt es dafür ein Grund, das z.B. nfs/ iscsi nicht über SDNs geht?
Ne, wir haben aktuell nur drei produktive Server (ohne die alten Nutanix-Nodes), daher habe ich das Netzwerk klassisch manuell über die Interfaces konfiguriert. Proxmox war für uns im Enterprise-Umfeld zunächst Neuland, und ich wollte zum Einstieg nicht gleich zu viele der "Magie"-Funktionen einsetzen.
:)
 
  • Like
Reactions: proxmrmomba
Hi, wenn du dein Netzwerk redundant aufbaust (LACP z.B.) dann brauchst du kein NFS Multipath, das funktioniert dann auch so sehr stabil.
Joa, da habe ich aktuell das Problem, dass die Hypervisor-Server bei uns 2 NICs haben, die jeweils auf einen Switch gehen. Die Filer haben auch zwei NICs und gehen auch jeweils auf beide Switche. So haben wir zwei Netze.

Die Switche sind gebridged, so dass wir zwischen jedem Hypervisor und jedem Filer theoretisch 4 Verbindungen hätten. Praktisch 2, die aber dann auf die jeweils andere Verbindung schalten könnten.

Naja, mit einem Active/Backup auf beiden Seiten käme ich nur auf eine Verbindung, die aber trotz dessen sowohl den Ausfall einer NIC am Hypervisor, eines Switches oder einer NIC am Filer verkraften könnte. Das wäre schon nicht schlecht....
 
Joa, da habe ich aktuell das Problem, dass die Hypervisor-Server bei uns 2 NICs haben, die jeweils auf einen Switch gehen. Die Filer haben auch zwei NICs und gehen auch jeweils auf beide Switche. So haben wir zwei Netze.

Die Switche sind gebridged, so dass wir zwischen jedem Hypervisor und jedem Filer theoretisch 4 Verbindungen hätten. Praktisch 2, die aber dann auf die jeweils andere Verbindung schalten könnten.

Naja, mit einem Active/Backup auf beiden Seiten käme ich nur auf eine Verbindung, die aber trotz dessen sowohl den Ausfall einer NIC am Hypervisor, eines Switches oder einer NIC am Filer verkraften könnte. Das wäre schon nicht schlecht....
Und wenn die Switches MLAG können, dann kann man einfach die Konfiguration erweitern und dann auch LACP nutzen. ;)