Proxmox Clusters and SANs: A Storage Surprise When Leaving VMware

Leaving VMware feels like ripping off a Band-Aid. It's painful, sure, but everyone tells you it's worth it. Licensing fatigue, cost blowups, and contracts that suddenly feel hostile are familiar reasons. Proxmox shows up looking calm, open, and refreshingly honest, promising clustering, HA, live migration, and a future where you're not negotiating with a sales rep every renewal cycle.

So you do what seems obvious. You take the architecture you've trusted for a decade, a small cluster backed by a SAN, and you plug Proxmox into it. Same storage, new hypervisor. Easy, right?

That's where things start to get weird. SAN-backed Proxmox does not behave like SAN-backed VMware, even when everything technically "works," and nobody warns you about it. The gap is mostly one of expectations, and it catches a lot of teams flat-footed.

The VMware muscle memory problem

Most VMware environments trained admins to think in a very specific way. Shared block storage is the center of the universe, snapshots are cheap, and thin provisioning is invisible. You overcommit storage with confidence and deal with consequences later, which usually means never.

VMFS absorbs the complexity without making a fuss, the SAN does its magic, and the hypervisor stays out of the way. When people jump to Proxmox, they often assume that same division of labor still applies: the SAN handles storage intelligence and the hypervisor just consumes it.

Proxmox doesn't hide storage decisions from you, though. It makes you own them.

Shared LVM: the first surprise

Most SAN-based Proxmox clusters start with shared LVM over iSCSI or Fibre Channel. It's supported, documented, and stable, and on paper it checks the VMware replacement box. It does work, too: live migration, HA, and multipath all function.

Then the questions start. Why are disks thick provisioned? Why are snapshots missing or dangerous? Why does deleting a VM not give space back? This is where VMware muscle memory breaks down.

Shared LVM in Proxmox is intentionally conservative. Volumes want guaranteed space. Snapshots are heavy, full copy-on-write structures that can balloon instantly. A 1TB virtual disk snapshot can mean 1TB of space pressure even if nothing changes.

SAN-level thin provisioning doesn't magically fix this, because the hypervisor doesn't see it. Proxmox plans storage as if it's real, reserved, and finite, since from its point of view, it is. Admins expect flexibility, and Proxmox gives them predictability instead.

"But the SAN does thin provisioning"

This comes up a lot, and it's technically true. Many modern SANs handle thin provisioning, deduplication, and compression beautifully. They reclaim blocks efficiently and lie, politely, about capacity.

The problem is visibility. With shared LVM, Proxmox doesn't understand how the SAN is cheating physics on your behalf. It still sees a big, fixed LUN. When you snapshot a disk, Proxmox prepares for worst-case growth. When you delete a VM, the SAN might not reclaim anything unless discard is configured perfectly.

That mismatch creates a false sense of safety. Things look fine… until they're not, and when they go wrong, they go wrong fast.

NFS: the option everyone resists (then uses anyway)

At some point in almost every migration, someone says it out loud: "What if we just use NFS?" This is usually followed by silence, mild horror, and a few jokes about performance.

Yet NFS is often the least surprising way to run shared storage on Proxmox. File-based storage unlocks qcow2 disks, which means thin provisioning that Proxmox actually understands. Snapshots live inside the disk file instead of consuming entire logical volumes, and space usage becomes visible, predictable, and recoverable.

It's not as fast as raw block storage or as elegant, and it doesn't do multipath the way Fibre Channel does. But it behaves, and when you're migrating off VMware, behavior matters more than benchmarks.

The snapshot reality check

Snapshots are where expectations really collide with reality.

In VMware, snapshots are dangerous but deceptively easy. Everyone knows they're not backups, and everyone still uses them, because they're quick, flexible, and usually fine.

In Proxmox with shared LVM, snapshots feel like a trap. They exist, but they don't feel safe, they don't scale well, and they can blow up your storage math in ways VMware never exposed.

That forces a cultural shift. Teams start treating VMs like cattle again, with immutable images, external backups, short-lived snapshots if any, and recovery through restore instead of rewind. That's a different way of working rather than a worse one, but different is uncomfortable during a migration.

"Why not just use Ceph?"

Once SAN pain sets in, Ceph enters the chat. It's native, integrated, and designed for Proxmox clusters from the ground up. It scales, it self-heals, and it makes shared storage a first-class citizen instead of an external dependency.

Ceph isn't free, though, whether you count hardware, networking, or operational complexity. For small 2 to 3 node clusters, it often feels like overkill. It wants RAM, fast disks, and clean networks, and it rewards discipline over shortcuts.

Some teams love it, and others bounce off hard. Ceph is a different philosophy entirely, so don't expect it to cure SAN disappointment.

Assumptions cause more trouble than storage

Here's the part nobody says out loud during planning meetings: most of the trouble comes from assumptions carried over from VMware, and much less from the SAN itself.

VMware trained admins to stop thinking about storage mechanics, and Proxmox brings those mechanics back to the surface. It doesn't protect you from bad math or mask risk behind friendly defaults.

That feels like a downgrade until you see what you gain: transparency, control, and fewer hidden cliffs. It only helps if you're ready for it.

What successful migrations have in common

Teams that come out of SAN-backed Proxmox migrations happy tend to share a few traits. They accept that not everything maps one-to-one from VMware, and they design storage around Proxmox's strengths instead of VMware nostalgia. They treat snapshots as tools rather than safety nets, and they plan capacity like it actually matters, because it does again.

Some land on NFS. Some stick with shared LVM and adjust expectations. Some go all-in on Ceph. A few mix local storage with replication and stop chasing centralized perfection altogether.

None of those choices are wrong. The mistake is assuming Proxmox will behave like VMware if you squint hard enough.

The exit is worth it, just not painless

Proxmox isn't broken, SANs aren't obsolete, and migrating away from VMware doesn't mean lowering standards. It does mean relearning where the guardrails are.

The teams that struggle usually have plenty of technical skill. What trips them up is expecting the storage layer to stay invisible. Proxmox doesn't do invisible; it does honest. Once you stop fighting that, the whole stack starts to make a lot more sense.