"Where's vMotion?" — The Question That Reveals the Real Learning Curve When Moving From VMware to Proxmox

# “Where’s vMotion?” — The Question That Reveals the Real Learning Curve When Moving From VMware to Proxmox ## The Migration Question That Starts It All When VMware administrators first begin exploring Proxmox, the conversation almost always starts with the same question: what replaces the familiar VMware features? vMotion. Distributed switches. DRS. Cluster networking. These tools aren’t just features in VMware environments—they shape how administrators design infrastructure. Remove them, and suddenly the entire mental model changes. One engineer recently captured that exact moment while planning a transition from ESXi and vCenter to Proxmox. Their environment would include three or four hosts, with one node containing specialized hardware requiring PCIe passthrough. Because those VMs depend on physical devices, moving them between hosts could cause serious issues. The engineer’s question was simple but revealing: should those hosts still be placed into a cluster, or should the infrastructure be designed differently? That question triggered a surprisingly detailed discussion about how Proxmox approaches virtualization differently from VMware. ## Live Migration Exists — But the Philosophy Is Different One of the first responses clarified the most important concern: yes, Proxmox supports live migration. Virtual machines and containers can move between hosts inside a cluster without shutting down, similar to VMware’s vMotion. But the automation layer behaves differently. In VMware environments, Distributed Resource Scheduler constantly analyzes host resource usage and may rebalance workloads automatically. Proxmox takes a lighter approach. Cluster Resource Scheduling—often referred to by administrators as CRS—focuses primarily on high availability events rather than constant optimization. Administrators typically create host priority groups and assign VMs intentionally across nodes. The cluster then ensures availability during failures rather than continually shifting workloads based on CPU or memory pressure. Some engineers like this simplicity. Others miss VMware’s automated balancing. That difference alone often shapes how teams design their Proxmox clusters. ## Distributed Switches Become a Networking Puzzle Networking quickly became the second major topic in the conversation. VMware administrators frequently rely on vSphere Distributed Switches to manage VLANs, port groups, and network configuration centrally across multiple hosts. Proxmox doesn’t replicate that feature directly. Instead, it builds networking on top of Linux primitives like bridges, bonding, and optional Open vSwitch configurations. For administrators expecting a centralized “switch interface,” this can feel unfamiliar at first. Several engineers suggested that Proxmox’s Software Defined Networking system provides the closest equivalent. The idea works like this: Administrators create an SDN zone, attach it to a Linux bridge shared across hosts, and then define virtual networks—called VNets—that represent individual VLAN-backed networks. Once the SDN policy is applied, those networks appear across every host in the cluster. In practice, VNets function similarly to VMware port groups. VM builders simply select the network they want when attaching a virtual NIC. ## Some Engineers Still Prefer Open vSwitch Not everyone agreed that SDN is the best approach. Another engineer argued that Open vSwitch might be a better match for organizations managing large numbers of VMs or complex VLAN setups. In that model, VLANs are configured directly on the switch layer rather than through Proxmox’s SDN abstraction. Their reasoning was straightforward. Some environments contain thousands of VMs. Configuring VLAN tags individually at the VM level becomes tedious. A more traditional switch model may reduce operational overhead. That perspective highlights something important about Proxmox networking: multiple architectures can work. There’s no single prescribed model. ## The Linux Networking Layer Is Still Visible Another part of the discussion revealed how deeply Linux networking concepts influence Proxmox infrastructure. One engineer described their production environment using six physical interfaces: Two 1Gb ports bonded for management traffic, connected to separate switches for redundancy. Two 25Gb interfaces handling trunk traffic for virtual machines, carrying multiple VLANs. And another pair of 25Gb connections dedicated to shared storage. Their networking chain looked like this: Physical interface → Linux bond → Linux VLAN → Linux bridge. Once configured, VM builders simply choose the appropriate bridge corresponding to the desired network. It’s a system that works well, but it requires administrators to understand Linux networking fundamentals more deeply than many VMware environments demand. ## Hardware Passthrough Adds Another Constraint The original concern about PCIe passthrough also received practical answers. Virtual machines using VFIO device passthrough—such as GPUs or specialized network cards—cannot easily migrate between hosts without shutting down. That limitation exists in most hypervisors. The suggested solution was straightforward. Simply avoid attaching those VMs to high-availability migration rules. The cluster can still manage the hosts normally, while the hardware-dependent VMs remain pinned to their specific nodes. Administrators can still configure startup order, delayed boot sequences, and shutdown behavior at the host level. It’s not fundamentally different from how many VMware environments handle similar workloads. ## Storage Architecture Still Shapes Everything Another engineer pointed out that storage architecture may ultimately determine whether clustering makes sense. Live migration works best when multiple hosts share access to the same VM disks. In VMware environments, that usually means SAN or NAS storage. Proxmox environments often replace SAN appliances with distributed storage systems like Ceph. With Ceph, the same nodes running virtual machines can also contribute disks to a shared storage pool. The cluster replicates data across nodes automatically, allowing VMs to move between hosts without needing centralized storage hardware. But Ceph also introduces new design considerations: network bandwidth, disk balancing, and cluster health become tightly connected. For teams used to SAN-based environments, that shift can require a different mindset. ## The Real Lesson Hidden in the Discussion What started as a simple question about distributed switches ended up covering nearly every core part of virtualization infrastructure. Live migration. Cluster scheduling. Networking models. Storage architecture. Hardware passthrough. And the conversation revealed something deeper. Many of the features VMware administrators depend on still exist in Proxmox. But they’re implemented differently, often exposing more of the Linux foundation beneath the platform. VMware hides complexity behind polished abstractions. Proxmox exposes the building blocks. For some engineers, that transparency is empowering. For others, it means a learning curve that goes beyond simply replacing one hypervisor with another.