Outline
- Storage – it’s far expansive and flexible and that means there can be landmines for the inexperienced.
- Linux – ESXi is locked down. Linux under the hood is not nearly so.
- Backup & Disaster Recovery – Actually Easier than vmware thanks to PBS.
- Proxmox Datacenter Manager: Not vCenter — Yet — But You Should Be Using It
- Proxmox SDN: Powerful, Young, and Very Linux
- Memory Deduplication Is On — and You Control It
- Community – What’s YOUR lesson learned?
Storage – The Big One
Understand that the storage layer in Proxmox are usually Linux primitives: ZFS, LVM/LVM-thin (dm-thin), mdraid/lvm-raid, CEPH or possibly NFS/ISCSI
If you’re coming from VMWare, you might be familiar wtih VMFS, VSAN and how storage works there for hyperconvergence.. or perhaps in a general SAN type context.
The first thing to understand is that ZFS is big. And different. It’s not a file system. It’s a full storage stack that does end-to-end checksums (data+metadata), scrubs w/self-heal (less like LSI raidcard scrub more like what IBM or Pure Storage implement in their enterprise products. ZFS has excellent snapshots and replication built in, and is tried-and-true copy-on-write. ZFS (and many of the technologies here) are old open-source technologies.
There are pitfalls with ZFS: There are lots of scenarios where writes can be amplified and this is often the source of significant I/O pressure/stalls and poor performance after migration from another virtualization platform.
As an administrator, one must come to understand some aspects of their storage geometry to understand the failure modes and diagnose performance issues.
VMFS mindset: “My array is sacred; ESXi is a consumer.”
ZFS mindset: “My hypervisor is now part of the storage trust boundary.”
For example, qcow2 virtual machine files on top of ZFS is a double copy-on-write scenario. Instead, a raw zvol block storage device is (generally) best for most workloads.
See also:
ZFS has vastly different performance characteristics depending on if it is RaidZ vs a mirror (or striped mirror), and how many vdevs exist in the overall zfs storage pool.
Storage Migration
I see an alarming number of guides on the internet for migration from vmdk > qcow2 in a zfs context that doesn’t talk about sector misalignment. What’s sector misalignment in this context? Generally, with ZFS, it works in 128k chunks by default (and some use cases make sense for 1mb and other use cases make sense for ~16kb). A given ZFS dataset can be created inside of a ZFS volume with a different record size.
Generally when mapping virtual machine storage there are alignment considerations for both the partition and filesystem clusters in the VM.
Operational consequences VMware admins need to hear:
- Scrubs and SMART matter now (schedule them, alert on them)
- Snapshots/replication are cheap—until they aren’t (snapshot sprawl and retention policy become your job)
- “Just add disks” is not always a free win (recordsize/volblocksize, special vdevs, slog decisions, and ashift permanence)
If VMFS was “a datastore,” ZFS is “a storage system.” Proxmox makes you own that—but then rewards you for it.
Example Migration & Check
# Install tools (Debian/Proxmox host)
apt-get update
apt-get install -y libguestfs-tools virt-v2v
# Convert an OVA to local KVM output (creates disks + XML metadata)
virt-v2v -i ova /path/to/vm.ova -o local -os /var/lib/v2v-out
Example: 200G disk, 16K volblocksize (common starting point; tune per workload).
zfs create -o mountpoint=none tank/vmdata
zfs create -V 200G -b 16K -o volmode=dev tank/vmdata/vm-100-disk-0
# then to convert vmware vmdk
# Source can be VMDK, qcow2, etc.
qemu-img convert -p -f vmdk -O raw /path/to/source.vmdk /dev/zvol/tank/vmdata/vm-100-disk-0
# run sync twice to flush buffers out to disk
sync
sync
Then in proxmox you can do something like:
qm set 100 -scsi0 /dev/zvol/tank/vmdata/vm-100-disk-0,discard=on,ssd=1
assuming you’ve already created a VM id # 100 in proxmox
Note: Ideally the storage is also mapped in your Proxmox host configuration because if you’re using ZFS and a Proxmox cluster ZFS makes it easy to manage snapshots and migrations from one cluster host to another. This example short-circuits Proxmox management a bit and TODO comeback and fix this if there are questions.
The Proxmox Wiki is also useful. Read it.
If you want to learn more about ZFS
Not ready to talk about migrations, tools, and it’s a strange new world for you talking about file system cluster sizes? Not wo worry – we have other threads and external resources:
ZFS Performance Tuning from Klara
ZFS Lessons Learned with Allan Jude and Tom Lawrence
What about Not ZFS for storage on Proxmox?
First, LVM.
On VMWare, it gives you nothing for raid. This sucks because basically every fast nvme raid system out there goes directly through the CPU, not an add-in pcie card, because add-in pcie cards are the bottleneck when your SSDs can manage 15 gigabytes per second transfer.
And ZFS is a lot of overhead. LVM is a volume manager. It can sit on top of almost anything.
mdraid (Linux MD) is the Linux software raid implementation. That can present a raid device, typically /dev/md0, from a number of underlying physical disks.
LVM Raid are built on top of the Linux MD code via device mapper, but it is not really the same as you’d get running the md raid admin tools directly (mdadm). In other words the Raid1/5/6/10 that LVM supports is essentially the same code path as linux MD but.. one gets there a different way. Tried and true code, though).
Intel VROC on Linux is extremely close to mdraid behavior, but one onotable difference is support for plugging the raid5 write-hole via a journal/mailbox style mechanism. GRAID Technology has taken over VROC and this software raid on VMWare natively is the only fast software nvme raid that I know of.
Guest Drivers Storage Performance
Don’t overlook guest driver performance. There is a new storage driver coming for windows that’s better optimized for more threads. I can clear 100k i/ops in a VM easily now.
9gb/sec from NFS over RDMA on Proxmox 9 is entirely possible:
Hyperconvergence?
If you came from vSAN, you’ll be tempted to map 1:1 with CEPH. Don’t. At least until you’re fully read in.
Proxmox supports modern Ceph releases and documents upgrade paths heavily. Understand that, like ZFS, Ceph predates Proxmox.
Success comes from CRUSH/failure domain design, network design, and hardware homogeneity—not from assuming “HCI magic.” Depending on your administrative experience, this could be a blessing or a curse. Or both.
Ceph is quite good in my experience, especially with many (7+) cluster hosts, and can deliver a similar HCI experience
2 - You’re not “in vCenter”; you’re in Linux (and that’s the point)
This storage talk may make it seem like a lot, but this is the power of Linux. It’s still Debian 13 under the hood. I like this because it is less opaque. When vSAN first launched everyone assumed that it would be efficiently locating blocks in the storage pool. Narrator: It was not doing that.
If storage is the first mental model shift for VMware admins, Linux is the second—and bigger—one.
Proxmox is not a sealed appliance like ESXi.
It’s a Debian-based Linux system, and that freedom cuts both ways.
- ESXi: locked-down hypervisor, tightly controlled surface area
- Proxmox: full Linux OS with a web UI on top
- You are an OS administrator again, not just a hypervisor operator
Proxmox deliberately does not re-implement or “own” core technologies:
- ZFS, LVM, mdraid, Ceph, corosync, Open vSwitch
These are upstream Linux projects with long histories
Proxmox integrates them, but does not abstract away their behavior
This is more flexible than VMware—but it assumes you know what you’re doing.
Customizing the host: sometimes good, sometimes a mistake
Because it’s Linux, you can:
- install packages
- tune kernel behavior
- add monitoring agents
- script automation
But you should not treat the Proxmox host like a general-purpose server.
Common pitfall: Docker on the Proxmox host
Docker itself works fine… the problem is networking generally. Docker rewrites iptables / nftables
Proxmox assumes it controls bridges, firewalling, and routing
Result: subtle breakage, hard-to-debug networking issues
Best practice:
Run Docker inside a VM (or container), not on the Proxmox host.
This is not a performance issue—it’s an operational sanity issue.
Containers: Proxmox has something VMware never really did
Proxmox supports:
- Full VMs (KVM/QEMU)
*LXC system containers (not Docker)
LXC:
- very low overhead
- excellent for services, appliances, and hardware access
- often a better fit for things like:
- media servers
- lightweight services
- direct access to host devices (GPUs, encoders, etc.)
VMware never had a clean equivalent here.
Its Kubernetes integrations were .. uh… lacking. And license-driven.
Filesystems and sharing: improving, but still evolving
Running Docker in a VM often means you want filesystem passthrough
- Historically awkward
virtio-fsnow makes this practical!
relatively recent, but works well
This is another example of Proxmox benefiting directly from Linux ecosystem progress
#3 – Backup & Disaster Recovery: Proxmox Gets This Right
This is where Proxmox quietly embarrasses both VMware and Microsoft.
VMware’s historical failure mode
- Early free ESXi had usable snapshot and backup hooks
- VMware deliberately removed or crippled them to force licensing
- This happened well before Broadcom
- VMware’s philosophy prioritized:
- HA
- replication
- complex clustering features
over: - bare-metal restore
- simple, reliable backups
Result:
- Backup became a third-party problem
- This vacuum is exactly why Veeam exploded in popularity
This wasn’t an accident—it was a product decision.
Windows followed the same pattern:
- “We ship the OS, backup is your problem”
- Windows Backup became unreliable sometime around ~2007
- Enterprises stopped trusting it long ago
Proxmox takes the opposite approach
Proxmox Backup Server (PBS) is not an afterthought.
It is:
- a first-class product
- designed alongside Proxmox VE
- focused on backup and restore as core workflows
PBS provides:
- incremental-forever backups
- block-level deduplication
- verified restores
- fast file-level recovery
- native encryption
- hardened authentication
- simple, transparent retention policies
No licensing games. No feature sabotage.
Architecture matters
- PBS works best on bare metal, but can run as a VM
- Designed to scale independently from compute
- Supports self-replication
- makes true 3-2-1 backups trivial
- Explicitly designed to reduce ransomware blast radius
- backup server auth model is isolated from VE hosts
This is the kind of design you get when backup is treated as a primary concern.
“But we already use Veeam”
Good news: Veeam now officially supports Proxmox VE.
That means:
- You don’t lose your existing backup workflows
- You can mix:
- PBS for fast local + replication backups
- Veeam for enterprise workflows, compliance, and cross-platform consistency
This removes one of the last serious blockers for VMware refugees.
#4 - #4 – Proxmox Datacenter Manager: Not vCenter (Yet), But You Should Be Using It
Let’s get this out of the way first:
Proxmox Datacenter Manager is not a vCenter replacement.
And that’s okay.
What it actually is
- A central management plane for:
- multiple Proxmox VE instances
- multiple clusters
- Proxmox Backup Server
- A way to get fleet-level visibility without logging into every cluster
Most real management still happens at the cluster or node level.
Why it exists
Datacenter Manager exists because:
- people run more than one Proxmox cluster
- VMware refugees expect some central visibility
- Proxmox needed a way to scale operational awareness without rebuilding vCenter
And development velocity here is high—largely driven by the influx of VMware users.
What it can do today
- Single UI for multiple Proxmox VE instances
- View:
- cluster health
- node status
- VM and container inventories
- Integrates Proxmox Backup Server
- Supports cross-cluster VM migration
- Provides delegated access / role-based views
Think of it as:
“Unified visibility and light orchestration,” not “full policy-driven automation.”
What it does not do (yet)
- No deep lifecycle automation
- No DRS equivalent
- No advanced policy engines
- Limited built-in health analytics
If you’re expecting:
- automatic load balancing
- aggressive hands-off optimization
you won’t find it here.
That’s still on you.
Monitoring: the missing piece
Proxmox has:
- solid built-in graphs
- good logs
- per-node visibility
What it lacks is rich, opinionated health monitoring.
This is where Linux shines:
- tools like Netdata work extremely well on Proxmox hosts
- real-time visibility into:
- CPU contention
- memory pressure
- I/O stalls
- network saturation
Best practice:
- install monitoring agents on hosts
- bind dashboards to internal networks only
- treat monitoring as infrastructure, not a Proxmox feature request
VMware contrast
- vCenter bundles:
- orchestration
- automation
- policy engines
- telemetry
into one heavy control plane
- Proxmox intentionally avoids this monolith
- Instead, it exposes clean integration points
This is a design choice, not a missing feature. Datacenter manager might someday bridge the gap more, especially for cluster-wide aspects, but not yet.
#5 - Networking Best Practices, SDN and Beyond
#5 – Networking & Proxmox SDN: Powerful, Linux-Native, and Not NSX
Networking is one of the areas where VMware admins bring the most assumptions with them.
Some of those assumptions will hurt you.
Start with the basics: Proxmox cluster networking
Proxmox relies heavily on corosync for:
- cluster membership
- quorum
- fencing coordination
Important clarifications:
- Corosync does not need high bandwidth
- It does need reliability and low jitter
- 1 GbE is fine; bonded 1 GbE is better
- Do not share corosync with:
- live migration
- VM traffic
- storage replication
This should feel familiar if you’ve built VMware clusters—but Proxmox does not enforce this separation for you.
Separate your traffic classes
A sane Proxmox design usually includes:
- Corosync network (reliable, boring)
- Migration network (high bandwidth)
- VM data networks (often VLAN-based)
This can be:
- multiple physical NICs
- bonded NICs
- VLANs over high-speed links
Proxmox gives you the primitives; it does not dictate topology.
Linux networking under the hood
Proxmox networking is built from:
- Linux bridges
- Linux bonding
- Open vSwitch (optional)
- iptables / nftables
- standard Linux routing
Nothing proprietary. Nothing hidden.
This means:
- excellent performance
- predictable behavior
- deep observability
- and zero hand-holding
Proxmox SDN: what it actually is
Proxmox SDN is:
- a management layer over Linux networking
- based on Open vSwitch
- supports:
- VLAN
- Q-in-Q
- routed networks
- NATed private networks
It shines at:
- creating private VM networks
- building lab or tenant isolation
- standardizing network definitions across nodes
What Proxmox SDN is not
This is where VMware admins need to recalibrate expectations.
Proxmox SDN:
- does not configure top-of-rack switches
- does not offload policy to hardware fabrics
- does not have an NSX equivalent
- does not integrate with SmartNICs for policy enforcement
VMware could do some of this because:
- Broadcom owns the switching silicon
- VMware built tight hardware partnerships
Proxmox intentionally stays hardware-agnostic.
Why that’s not a dealbreaker
For most environments:
- VM-level networking
- VLAN segmentation
- NAT isolation
- software routing
are more than sufficient.
And because it’s Linux:
- you can inspect every packet path
- you can debug with tcpdump, ip, ethtool, ovs-vsctl
- you can integrate external networking tools if needed
Proxmox HA is cluster-manager-driven orchestration. It’s powerful, but:
- fencing/watchdog strategy is your responsibility
- shared storage expectations differ depending on ZFS replication vs Ceph vs shared SAN
- you’ll want to design failure domains intentionally rather than expecting “it’ll just do what vSphere does”
#6 – Subtle Knobs & Tunables: Power Tools, Not First Tools
Once storage and networking are sane, Proxmox exposes a class of second-order tunables that VMware mostly hid—or slowly removed.
This is just something I want you to be aware of that can impact performance, but not always.
These knobs matter, but they are not where your first performance problems will be.
Memory deduplication (KSM)
Proxmox uses KSM (Kernel Samepage Merging):
- merges identical memory pages under pressure
- enabled by default
- tunable and observable
It helps when:
- you run many similar VMs
- memory is actually contested
It can hurt:
- CPU-heavy or latency-sensitive workloads
This is the Linux equivalent of VMware’s old TPS—but honest, explicit, and under your control.
Huge pages
Proxmox lets you use:
- 2 MB huge pages
- 1 GB huge pages (hardware permitting)
Benefits:
- fewer TLB misses
- lower page table overhead
- modest but real gains for large, memory-heavy VMs
Costs:
- reduced flexibility
- harder memory overcommit
- planning required
Huge pages are not magic—they’re workload-specific.
CPU topology & scheduling
Unlike VMware, Proxmox makes CPU layout explicit:
- NUMA awareness
- CPU pinning
- host vs passthrough CPU models
- scheduler behavior is Linux, not a black box
This matters for:
- multi-socket systems
- memory-locality-sensitive workloads
- performance consistency
Misuse can make things worse, not better.
I/O tuning outside storage
Beyond ZFS/LVM geometry, you still have:
- virtio queue depth
- multi-queue networking
- interrupt distribution
- I/O thread placement
These are real knobs, but again:
If you’re touching these before fixing storage alignment, you’re optimizing the wrong layer.
