Fibre Channel (FC-SAN) support

[sys92]

Are there any plans to introduce native Fibre Channel (FC-SAN) support with full snapshot and shared storage capabilities in upcoming Proxmox VE releases?

Currently, it’s possible to work with FC using multipath and LVM, but the lack of snapshot support and true shared storage integration limits its usefulness in enterprise environments—especially when compared to VMware and similar platforms.

This enhancement would significantly increase Proxmox's competitiveness in virtualization setups where high-performance SAN infrastructure is already in place.

Any insights or roadmap details would be appreciated.

Thanks!!!

 

[bbgeek17]

Hi @sys92, welcome to the forum.

native Fibre Channel (FC-SAN) support

If by “native” you mean vendor-specific FC integrations, then no - there are currently no plans in that direction.
If you’re referring to native FC support within Proxmox VE itself, any developments in this area would likely remain in test or no-subscription repositories for the foreseeable future - so not recommended for production use just yet.

compared to VMware and similar platforms.

VMware relies on VMFS - a proprietary, clustered file system specifically engineered for shared FC-based storage. There’s no directly comparable, production-ready alternative in the PVE ecosystem today.

This enhancement would significantly increase Proxmox's competitiveness in virtualization setups where high-performance SAN infrastructure is already in place.

Proxmox has steadily grown by focusing on its core strengths and capturing a specific segment of the virtualization market. Rushing to implement complex storage functionality, especially one that touches core components like snapshotting and cluster coherency would go against its carefully considered development philosophy.

That said, there are storage vendors outside of the traditional "storage cartel" who do support Proxmox natively and deliver robust functionality.

In the meantime, you might find this knowledge base article helpful: https://kb.blockbridge.com/technote/proxmox-lvm-shared-storage/

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[LnxBil]

There’s no directly comparable, production-ready alternative in the PVE ecosystem today.

I would even replace PVE with Linux in this sentence and I don't see that this will happen any time soon, if at all. No big player / contributer to Linux is using such antiquated technology anymore and therefore there is no need and no manpower to implement this.

We are almost at a point where this question gets asked multiple times per week. Maybe it's time to create a page like linuxatemymemory, but for FC-based SAN ... like WhyDoesProxmoxVeNotSupportFcBasedSanWithSnapshotsAndThinProvisioningAndNeverWill.com and redirect people there.

 

[alexskysilk]

Are there any plans to introduce native Fibre Channel (FC-SAN) support with full snapshot and shared storage capabilities in upcoming Proxmox VE releases?

I know @bbgeek17 is too humble, but I'm pretty sure you can get the functionality you are after using blockbridge. The state of PVE's support of block level SANs via API has been "not in scope" for a long time, and doesnt look like it will be.

I would even replace PVE with Linux in this sentence

Linux is not a hypervisor. there are plenty of linux based hypervisors that support this functionality (XCP-NG, RHEV, openstack, etc.)

 

[LnxBil]

Linux is not a hypervisor. there are plenty of linux based hypervisors that support this functionality (XCP-NG, RHEV, openstack, etc.)

With what production ready dedicated shared storage filesystem?

 

[alexskysilk]

I'm not a red hat rep. if you really want to know, reach out to their sales team otherwise, this may help: https://docs.openstack.org/cinder/latest/reference/support-matrix.html

 

[LnxBil]

I'm not a red hat rep. if you really want to know, reach out to their sales team otherwise, this may help: https://docs.openstack.org/cinder/latest/reference/support-matrix.html

I don't see any Linux kernel driver that is not part of Linux itself, just hardware vendor / product integration. Most are hardware vendor integration drivers similar to the ones that exist for PVE. If more vendors would support PVE directly, PVE would not always be blamed by people for not integrating storage technology xyz. It's simply not their task, but then vendors. Blockbridge is the best example how to do it properly. Therefore I recommend it to everyone that asks me what to use if CEPH is out-of-the-picture.

 

[alexskysilk]

I don't see any Linux kernel driver that is not part of Linux itself

exactly. the drivers are fine.

. Most are hardware vendor integration drivers similar to the ones that exist for PVE

yes. that is the point.

PVE would not always be blamed by people

thats kind of a silly point to make. PVE isnt responsible for anything, and choose what they want to support. Again, kind of the point. Its not a TECHNOLOGICAL limitation.

 

[sys92]

Thank you all for the clarification!
In summary, while LVM on multipath-enabled SAN storage is viable, it is fundamentally not a cluster file system and cannot safely support simultaneous multi-node access without additional clustering components and a proper cluster-aware file system on top.
Therefore, in an enterprise production environment , relying solely on LVM over shared SAN storage without proper clustering and a cluster-aware file system is not considered safe or supported.

It’s probably time to explore solutions like oVirt or OpenStack or RHV as some of you suggested, since I can’t justify scrapping a powerful SAN setup with high-performance SSD storage.

 

[waltar]

Funny problems ... just take any external sas or fc storage, forget lvm complete, use xfs directly on volumes, export by nfs to pve's.
Any switch to other nfs host could be done in seconds by scripts and ctdb.
Any crashed pve will take more than 3 minutes to bring up machines (vm/lxc) on other nodes.

W

Post in thread 'PBS Expected speeds and performances'

Apr 9, 2025

Nice solution and quiet good pbs results.
We have a real quiet unusual solution complete without vzdump or pbs on a bunch of even older hardware:
PVE on Dell T620, 2x 6-core Xeon E5-2620 @ 2GHz +HT, 32GB, with dr-backup store 8x4TB hdd as perc p710 raid6 with xfs, pbzip2'ed and duperemove'd, 1x 10Gbit between
Fileserver with rocky9.5 on Lenovo x3650 M4, 1x 4-core Xeon E5-2609 v2 @ 2.50GHz +HT, 128GB, 10x4TB hdd as ServeRAID M5110 raid6 with xfs.
Demo 32GB vm disk vm-158-disk-1.qcow2:
Backup as reflink 32GB: 0.002s on fileserver, 32774MB/0.002s = 16 GB/s
Backup to pve storage by nfs-copy...

• waltar

W

Post in thread 'best-practices für Enterpriseumgebungen'

Apr 7, 2025

ls */srv/data/images/146/vm-146-disk-0.raw
daily.2025-02-14_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-03-25_0001/srv/data/images/146/vm-146-disk-0.raw
daily.2025-02-15_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-03-26_0001/srv/data/images/146/vm-146-disk-0.raw
daily.2025-02-17_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-03-27_0001/srv/data/images/146/vm-146-disk-0.raw
daily.2025-02-18_0001/srv/data/images/146/vm-146-disk-0.raw daily.2025-03-28_0001/srv/data/images/146/vm-146-disk-0.raw
daily.2025-02-19_0001/srv/data/images/146/vm-146-disk-0.raw...

• waltar

 

[floh8]

In summary, while LVM on multipath-enabled SAN storage is viable, it is fundamentally not a cluster file system and cannot safely support simultaneous multi-node access without additional clustering components and a proper cluster-aware file system on top.
Therefore, in an enterprise production environment , relying solely on LVM over shared SAN storage without proper clustering and a cluster-aware file system is not considered safe or supported.

No. That is right for lvm-thin, but not for shared lvm. Read the documentation to the headline "storage" and here in the forum. Its answered a hundred times.
But your entry question was about the development of support of pve for shared blockstorage with snapshots: The answer is that proxmox is working at a solution like ovirt. Have a look to this post:https://bugzilla.proxmox.com/show_bug.cgi?id=6096

 

[spirit]

yes, snapshots on san are coming (with qcow2 on top of lvm, like ovirt indeed) . I'm working on it, I hope to finish it for pve9.

 

[alexskysilk]

Therefore, in an enterprise production environment , relying solely on LVM over shared SAN storage without proper clustering and a cluster-aware file system is not considered safe or supported.

True, but there are ways to live with it anyway, it really depends on your commitment to operating PVE in production and availability of devops talent.

Method 1. LVM Thick+Hardware snapshots. If your storage has internal thin provisioning and snapshot support (which many do) Its possible to orchestrate qm-freeze storage-snap qm-thaw workflows. You gain actual thin provisioning via the storage and access to snapshots. The downside is that snapshots would be of lvm states, which means restoration is an all-or-nothing proposition without granularity limiting its usefulness, which brings us to
Method 2. direct mapped LUN to VM. This obviates the need for any volume management since a lun belongs to a guest. Thin provisioning and snapshots work as intended although you will still need to provide orchestration; the downside is that storage management now has to be in two different places- PVE and the SAN, and can get cumbersome and fault prone.

Its all possible to do, up to and including integration into PVE- its just that its not in the box from either Proxmox or your storage vendor. If your shop has talent it could be an option.

 

[sys92]

yes, snapshots on san are coming (with qcow2 on top of lvm, like ovirt indeed) . I'm working on it, I hope to finish it for pve9.

That's great news

Do you mean something like below will have both snapshot and sharing capabilities in future release ? Or any new filesystem will be implemented other than xfs/ext4 etc which is cluster aware.

# setup multipath across all nodes and then

# whatever LUN available
pvcreate  /dev/mapper/<storage path-of-LUN>

# create vg
vgcreate  <vgname> /dev/mapper/<storage path-of-LUN>

# create lv
lvcreate -n data -l 100%FREE <vgname>

# format lv with whatever filesystem
# some filesystem which is cluster aware 
mkfs.xfs  -K  /dev/mapper/<storage path-of-lv>

# mount across all nodes available
mount /dev/mapper/<storage path-of-lv> /path/to/SAN-MOUNT

 

[bbgeek17]

In summary, while LVM on multipath-enabled SAN storage is viable, it is fundamentally not a cluster file system

It is not a file system at all. It is a volume manager.

cannot safely support simultaneous multi-node access without additional clustering components

This is correct. The PVE software acts as an arbiter to make it safe.

proper cluster-aware file system on top

PVE/LVM scheme does not need or use cluster-aware file system. One could use CAFS instead of LVM or with it outside of PVE mechanics.

Therefore, in an enterprise production environment , relying solely on LVM over shared SAN storage without proper clustering and a cluster-aware file system is not considered safe or supported.

You are posting this in the PVE forum. If you are speaking of PVE - the statement above is incorrect. If you meant something that is outside of the scope of the PVE, i.e. general Linux - you are correct.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox