VMware to Proxmox Migration: Two-Node Clusters and Fibre Channel
An IT team managing 10 clusters and 21 hosts across global sites is migrating its entire VMware infrastructure to Proxmox, navigating architectural constraints and storage complexities that don't appear in vendor documentation.
The infrastructure isn't small: 10 clusters spread across worldwide locations, 21 hosts total, production workloads managed through a single vCenter. Storage varies by site (Pure Storage arrays, Dell PowerStore, Dell Unity), with some connected via Fibre Channel and others through iSCSI.
The environment evolved over time rather than following a unified architectural plan. Different hardware budgets, site autonomy, and successive server generations created what one engineer described as "the usual enterprise patchwork."
Now the plan is to move everything to Proxmox, with help from a partner firm. The internal team is new to the platform, though, and questions are mounting.
Two-node clusters present quorum challenges
VMware handles two-node clusters without issue, while Proxmox requires more careful planning. Proxmox uses corosync for cluster quorum, and two nodes alone create split-brain risk. If one node fails, the remaining host lacks quorum and can't perform cluster operations.
The current proposal involves adding a Raspberry Pi as a quorum device for each cluster. Proxmox supports external quorum devices, making this technically valid. Multiple engineers questioned the approach, however, suggesting consolidation into 3 to 7 node clusters instead. With 21 hosts total, the math works.
The obstacle is geography. Sites are global, and workloads must remain local for latency reasons. Fibre Channel storage doesn't extend across continents, which rules out a single consolidated cluster.
"Sometimes you're not designing from scratch. You're inheriting," one engineer said.
Storage configuration requires Linux expertise
Storage, more than compute, is the most complex aspect of the migration. The mix includes Pure Storage arrays, Dell PowerStore and Dell Unity, with IBM FlashSystem in some environments. Some locations use Fibre Channel at 16Gb, and others use iSCSI with multiple active paths. Proxmox behaves differently from VMware here.
LVM management becomes necessary
With Proxmox, Fibre Channel LUNs typically require LVM (Logical Volume Manager). That means administrators need to understand pvcreate, vgcreate, lvcreate, lvs, and vgs commands.
For teams accustomed to vCenter's abstraction layer, this represents a shift. VMware hides much of the underlying Linux storage stack, and Proxmox exposes it.
One engineer running IBM FlashSystem over 16Gb Fibre Channel said it "worked like a charm, after knowing how LVM works." The qualifier is significant.
Thin provisioning creates monitoring confusion
On Pure Storage arrays, LUNs are thin provisioned and deduplicated at the SAN level, but LVM on the Proxmox side shows them as fully allocated.
The Proxmox dashboard reports 100% allocation while the SAN indicates actual usage remains low due to deduplication and thin provisioning. Without understanding this discrepancy, capacity planning becomes difficult and can trigger false alarms.
Multipath configuration must precede LUN access
Whether using iSCSI or Fibre Channel, multipath I/O configuration matters. If MPIO isn't configured before claiming LUNs on Proxmox nodes, duplicate LUN IDs can appear.
Engineers recommend scripting MPIO configuration, applying it to every node before accessing any LUNs, and making that standard procedure. Every new LUN requires a WWID entry in the MPIO config on each node.
For deployments using multiple active storage NICs, engineers emphasized testing failure scenarios by bringing down a port to verify I/O continuity.
Migration approaches: import tool vs. backup restoration
Proxmox includes an import tool for VMware VMs. It works by mounting ESXi storage through the ESXi hosts and importing powered-off VMs. For small VMs, it works adequately. For large production workloads, some engineers report it's slow.
Many teams are using Veeam instead: back up the VM from VMware, restore directly into Proxmox, power it on, then storage migrate if needed. This approach is faster, familiar, and provides a rollback strategy.
"When you're touching production across global sites, speed is nice. Safety is better," one engineer said.
VMware Tools removal required before migration
Failing to uninstall VMware Tools before migrating Windows VMs can create problems. The uninstaller may fail once the VM is no longer on ESXi, leaving broken VMware Tools in the Proxmox VM.
The correct sequence:
- Uninstall VMware Tools
- Install VirtIO drivers
- Install QEMU agent
- Shut down VM
- Convert
- Power up in Proxmox
Following this process, VMs typically adapt to the hypervisor change without issues. Skipping steps can mean driver cleanup at inconvenient times.
Network configuration changes after migration
When VMs move from VMware to Proxmox, the virtual NIC hardware changes, and guest operating systems often treat this as new hardware. Static IP configurations can disappear. Windows may assign a new interface, and Linux might change interface naming.
The issue is predictable but not obvious. Planning for post-migration network reconfiguration, including documenting which VMs have static assignments, prevents confusion when VMs appear to lose network connectivity after migration.
Proof of concept deployment planned
The team isn't planning an immediate full migration. A proof of concept cluster will be deployed first, followed by a staging environment and controlled migrations.
Here that approach is a necessity. Even with partner support and experienced engineers, Proxmox operates differently from VMware. It's Linux-first, requiring administrators to own more of the stack.
Cluster architecture remains under discussion
There's an unresolved architectural question: should the environment use fewer, larger clusters or maintain clusters grouped by SAN, hardware generation, and geography?
Fewer, larger clusters are easier to manage and upgrade consistently. With globally distributed sites, though, local clusters keep workloads local and prevent WAN latency from affecting HA behavior. They also isolate risk.
One engineer noted that large clusters concentrate risk during major upgrades. If all 21 hosts run in one cluster and a Proxmox upgrade encounters issues, every VM is affected. Smaller clusters allow staggered upgrades with testing on less critical clusters first.
There's no universal answer; the choice depends on understanding the tradeoffs.
Platform shift reflects changing enterprise priorities
This migration is a move from a commercial, heavily abstracted ecosystem to an open, transparent, Linux-native platform, which makes it more than a hypervisor swap. Administrators see more of the system, configure more components directly, and sit closer to the infrastructure. Some teams find that empowering, and others find it uncomfortable.
In environments where hardware costs matter, licensing models are shifting, and flexibility is increasingly important, Proxmox is emerging as a viable enterprise platform, particularly when deployed on enterprise storage like Pure Storage and Dell SANs.
Technical considerations
Teams planning similar migrations should monitor:
- Cluster design decisions made before migration, not after
- MPIO configuration before claiming any LUNs
- How LVM presents thin-provisioned storage
- VMware Tools removal before conversion
- Correct VirtIO and QEMU agent installation
- Network adapter hardware changes
- Storage path failure testing
- Proof of concept deployment
None of these are glamorous, but they separate a successful migration from emergency troubleshooting.
Moving away from established infrastructure
Teams making this transition show calculated confidence based on assessed risk rather than blind optimism. Proxmox is past the experimental stage and runs production workloads on enterprise storage in serious deployments.
Still, migrating 10 clusters across the globe off a platform that's been the infrastructure backbone for years requires careful preparation. Check your procedures twice, make sure oversight is in place, and then execute. In 2026, with VMware's licensing changes driving migration decisions, staying with existing infrastructure isn't always the lowest-risk option.