Blockbridge Lab Notes · Proxmox VE
Benchmarks, internals, and production tuning for Proxmox VE, written by the storage engineers at Blockbridge. Every number below comes from a published lab report with enough configuration detail to reproduce it.
We've supported enterprise Proxmox deployments since 2018. Our customers run demanding environments that need reliability, availability, and performance. Since 2021 we've been sharing what we can with the community. Most of it concentrates in the corner of the storage landscape where the choices are hardest.
Proxmox VE supports everything from local ZFS to Ceph. Our territory is enterprise shared block storage of the kind a SAN provides. Getting the best out of it means deeply understanding the internals. We take apart the protocol on the wire, the LVM layer Proxmox uses to share legacy SANs, and the QEMU plumbing on top. Then we test rather than guess. The sections below organize our work by theme.
A note on method: our benchmarks use Blockbridge as the storage backend unless stated otherwise. Relative results like protocol against protocol travel well to other fast storage. Absolute numbers depend on your backend, network, and CPUs.
The factors that dominate Proxmox storage performance: protocol choice, QEMU I/O plumbing, and host tuning, with data at every step.
Head-to-head comparison of the two Ethernet SAN protocols on Proxmox across block sizes and queue depths: IOPS, latency, and bandwidth.
technote/proxmox-iscsi-vs-nvmetcp/ BenchmarkProxmox exposes several storage I/O knobs. What each one does, which to pick for your storage type, and which combinations cost IOPS.
technote/proxmox-aio-vs-iouring/ TuningHost, KVM, and QEMU tuning that takes QD1 guest latency down as much as 40%, with bare-metal numbers as the reference line.
technote/proxmox-tuning-low-latency-storage/How Proxmox storage actually works under the hood, and where the sharp edges are.
How multiple PVE nodes safely share one LVM volume group without a clustered volume manager: benefits, limits, and setup.
technote/proxmox-lvm-shared-storage/ Deep diveWhat cache=none really means in QEMU, why QCOW2 metadata is exposed, and how flush and barrier handling affect data safety.
technote/proxmox-qemu-cache-none-qcow2/ Deep diveArchitecture, behavior, and limitations of Proxmox VE 9's new snapshot support for legacy SANs, currently a technology preview.
technote/proxmox-qcow-snapshots-on-lvm/Evaluating Proxmox as a VMware replacement: performance numbers first, then the DR feature mapping.
Same hardware and storage under both hypervisors: Proxmox peaks at 12.8 GB/s to ESXi's 9.3, with the gap varying by queue depth.
technote/proxmox-vs-vmware-nvmetcp/ Deep diveSRM equivalents, vSphere Replication vs pvesr and pve-zsync, PBS, stretched clusters, and what has no analog yet.
technote/proxmox-vmware-disaster-recovery/Day-2 work: reliable concurrent migration, Windows guest storage performance, and fast disposable test images.
A four-part measurement campaign on Windows guest storage performance: virtio, drivers, and configuration that matters.
pt.1 pt.2 pt.3 pt.4Secure vs insecure migration paths, why parallel migrations stall, and settings for moving many VMs at once, reliably.
technote/proxmox-concurrent-vm-migration/ How-toBoot tiny CirrOS cloud images on Proxmox with CloudInit metadata: the fastest way to a disposable test VM.
technote/proxmox-cirros/The questions that come up again and again on the Proxmox forum. Short answers up front, measurements and working threads behind every link.
picking-storage/
Excluding hyperconverged Ceph, the primary external options are FC, iSCSI, and NVMe/TCP, with NFS as the file-storage alternative. FC and iSCSI are supported out of the box; NVMe/TCP has no native PVE storage plugin, so you can attach devices by hand and layer LVM on top, but cluster-managed provisioning takes a vendor integration. Which one fits depends on availability needs, capacity, and budget; the options get a practical airing in this small-clusters thread.
For a home lab, maybe; for production, no. Quorum needs a third vote: a full third node or a qdevice hosted outside the cluster it votes for. The reasoning comes up constantly, for example in this shared-storage thread.
Ceph is the hyperconverged analog and the only clustered storage fully integrated into PVE; the alternative is reusing or deploying external SAN storage over FC, iSCSI, or NVMe/TCP. We compare the paths in vSAN or Ceph?, and the DR side of the move in Mapping VMware DR to Proxmox VE.
san-mechanics/
LVM-thin is not cluster-safe, so sharing a legacy SAN means thick LVM; thin provisioning has to come from the array side. Snapshots on shared thick LVM arrived in PVE 9 as QCOW volume chains (currently a technology preview); we analyzed the mechanism in Inside PVE 9 SAN snapshot support and field variants of the question in threads like this one.
Yes, as a technology preview: VE 9 introduced snapshot support for legacy SAN configurations using QCOW-on-LVM, with caveats on performance and allocation. How it works, how it behaves under load, and its limitations are analyzed in Inside PVE 9 SAN snapshot support.
more threads: the tutorial thread
Proxmox coordinates LVM metadata changes at the cluster level rather than using a clustered filesystem. What makes that safe, and what its limits are, is explained in Understanding LVM shared storage.
Multipath only works when raw devices are presented to the kernel: sessions established via iscsiadm, no base option needed in the LVM storage definition, and the multipath device consumed directly. A working setup, from device discovery through enabling device-mapper multipath, is in Understanding LVM shared storage.
more threads: iSCSI network best practices
There are metadata-integrity considerations. cache=none bypasses the host page cache but does not change how QCOW2 orders its own metadata updates. The failure modes and when RAW is the better choice are covered in QCOW2 risks with cache=none.
performance/
For raw block storage, aio=native paired with an IOThread was our top pick. For thin-LVM and file-based storage, io_uring is the safer choice, because aio=native can block in those configurations. The measurements behind that rule are from PVE 7.2, so re-verify on current releases before standardizing. The full matrix is in iothreads, aio & io_uring.
more threads: the benchmark thread
Over NVMe/TCP on identical hardware, yes: Proxmox peaked at 12.8 GB/s versus 9.3 GB/s for ESXi, about 38% higher bandwidth at peak load. The picture is protocol-dependent, though: with iSCSI, out-of-the-box results are less clear-cut and host tuning matters. The NVMe/TCP breakdown is in Proxmox vs VMware ESXi over NVMe/TCP.
more threads: PVE vs ESXi: tuning iSCSI
day-2/
Usually the migration transport: secure and insecure paths behave very differently under parallel load. Settings for moving many VMs at once reliably are in Stable concurrent VM migration.
Almost always basic plumbing before anything Proxmox-specific: MTU mismatches on jumbo-frame networks, IP conflicts, interface errors, a bad cable or switch port, or an export ACL that quietly omits one node. A worked diagnosis, from checklist to root cause, is in this troubleshooting thread.
There is no single drop-in equivalent: pvesr, pve-zsync, and Proxmox Backup Server each cover part of the surface. The feature-by-feature mapping, including what has no analog, is in Mapping VMware DR to Proxmox VE.
You'll find us answering storage questions every day on the Proxmox forum and on r/Proxmox as bbgeek17. Behind the account is a team of Blockbridge experts. Most of it has nothing to sell: a node that's lost its NAS, storage options for small clusters, multipath for whatever SAN you already own. Several of the lab notes above started as forum [TUTORIAL] threads where follow-up questions get answered inline for years. We've also reported and helped fix bugs in Veeam, iscsiadm, sg3_utils, multipath-tools, Proxmox VE, and Datacenter Manager.
tutorials/
discussions/
upstream-bugs/
elsewhere/
Many of the lab notes above document the legacy path: manual multipath configuration and LVM coordination, host tuning and careful failure handling. That path works, and we help people on the forum run it. Blockbridge is storage designed for Proxmox: array-side snapshots and thin clones, automatic multipath NVMe/TCP and iSCSI, adaptive tuning and always-on encryption. The same team that answers the forum backs the product with 24×7×365 emergency support. In operation since 2010, Blockbridge is an official Proxmox partner and has supported mission-critical Proxmox deployments since 2018.
Blockbridge Native Plugin Docs → Explore the Full Solution →