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

 

[sys92]

Thank you all for your valuable inputs & clarifications! I managed to spin two nodes with Ovirt with FC-SAN for testing purpose. Once PVE version 9 releases with FC-Support I will re-evaluate.

 

[bbgeek17]

Thank you all for your valuable inputs & clarifications! I managed to spin two nodes with Ovirt with FC-SAN for testing purpose. Once PVE version 9 releases with FC-Support I will re-evaluate.

Have you looked at the project's status as of today? This was the last conversation I recall: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/6Z5CCSNZPSBBG2M3GN5YJBNFEMGEHNEA/

Last release 12/1/23

---

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

 

[sys92]

---

Yes, I’ve checked, and unfortunately, the client doesn’t have the budget to upgrade either the hardware (for a Ceph deployment) or the software (to continue with VMware). Being a school, they’re trying to make the most of their existing servers and SAN storage, so I had to work within those limitations.

As for oVirt, it’s disheartening to see the state it’s in—no active forums, minimal community engagement, and an overall lack of momentum. It feels like a project slowly fading away, despite the value it once brought to many of us in the open-source world.

Sometimes it seems like open-source solutions are being quietly edged out, either absorbed by large corporations or abandoned due to lack of funding and support. If this trend continues, we may one day witness not just the decline of individual projects, but a broader erosion of the open-source ecosystem itself. And with that, a part of what made the tech world truly collaborative and innovative may be lost.

 

[alexskysilk]

Yes, I’ve checked, and unfortunately, the client doesn’t have the budget to upgrade either the hardware (for a Ceph deployment) or the software (to continue with VMware). Being a school, they’re trying to make the most of their existing servers and SAN storage, so I had to work within those limitations.
As for oVirt, it’s disheartening to see the state it’s in—no active forums, minimal community engagement, and an overall lack of momentum. It feels like a project slowly fading away, despite the value it once brought to many of us in the open-source world.

Understandable. In my view, deploying a product that is effectively unsupported (by anyone) is a bad solution, regardless of budgetary requirements. outages, loss of service, or loss of data are more expensive than upfront spending. Given your set of constraints, I'd probably be looking at XCP-NG and not oVirt although PVE can still work as well- the lack of snapshots doesnt have to be a showstopper for a 2 node operation.

Sometimes it seems like open-source solutions are being quietly edged out,

Why? The whole point of open source is that it cannot be "closed." The IP owner may change the source license to make it private downstream but that doesnt alter the license for the prior releases; forks can and do happen routinely. and yes, developers can move on for any number of reasons. These are not trends, its a simple business reality that always existed, both in the commercial and OS space. In the case of oVirt, when IBM bought Red Hat they didnt want to continue to invest in RHEV (and consequently its non commercial version, oVirt) because they had other products for that space. As oVirt was 100% Red Hat software, the removal of the entire dev team meant that anyone who would want to continue supporting it would have to assume the entirety of the project. So far there are no takers. In that particular case, it was the REMOVAL of corporate funding that killed the project.

But make no mistake, Open Source isnt going anywhere. You can rest assured that there is no "trend" and there is no danger of "erosion of open source ecosystem."

 

[Johannes S]

Understandable. In my view, deploying a product that is effectively unsupported (by anyone) is a bad solution, regardless of budgetary requirements. outages, loss of service, or loss of data are more expensive than upfront spending. Given your set of constraints, I'd probably be looking at XCP-NG and not oVirt although PVE can still work as well- the lack of snapshots doesnt have to be a showstopper for a 2 node operation.

Exactly see this wiki section whic covers that part:

Alternatives to Snapshots​

If an existing iSCSI/FC/SAS storage needs to be repurposed for a Proxmox VE cluster and using a network share like NFS/CIFS is not an option, it may be possible to rethink the overall strategy; if you plan to use a Proxmox Backup Server, then you could use backups and live restore of VMs instead of snapshots.

Backups of running VMs will be quick thanks to dirty bitmap (aka changed block tracking) and the downtime of a VM on restore can also be minimized if the live-restore option is used, where the VM is powered on while the backup is restored.
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Alternatives_to_Snapshots

Now this won't work for any scenario obviouvsly but might be enough for the OPs scenario.

But make no mistake, Open Source isnt going anywhere. You can rest assured that there is no "trend" and there is no danger of "erosion of open source ecosystem."

And any KVM based solution ( like ProxmoxVE, Openstack or whatever) has the benefit that even in the worst case (development of said solution stops, subscription costs rise to vmware level etc) one coud still migrate to a regular Linux system and run the vms from there. It won't be as comfortable (due to the missing WebUI), but since KVM (the actual hypervisor technology) is part of the Linux kernel you will still be able to run as long as the Linux kernel continues including KVM (which is unlikely to change).