Proxmox 集群文件系統（“pmxcfs”）是一個數據庫驅動的用於存儲配置文件的系統，使用 corosync 實時復制給所有集群節點 。 我們用它來存儲所有 PVE 相關的配置文件。
盡管文件系統將所有數據存儲在磁盤上一個持久性數據庫中，但數據的副本駐留在 RAM 中。 這限制了最大大小，目前為 30MB。 這仍然足以存儲數千個虛擬機的配置。
該系統具有以下優點：
-
將所有配置實時無縫復制到所有節點
-
提供強一致性檢查以避免重復的 VM ID
-
當節點失去仲裁時只讀
-
corosync 集群配置自動更新到所有節點
-
包括分布式鎖定機制
POSIX 兼容性
文件系統基於 FUSE，因此行為類似於 POSIX。 但有些功能根本沒有實現，因為我們不需要它們：
-
你可以只生成普通的文件和目錄，但不能生成符號鏈接，…
-
你不能重命名非空目錄（因為這樣更容易，以保證 VM ID 是唯一的）。
-
您無法更改文件權限（權限基於路徑）
-
O_EXCL 創建不是原子的（就像舊的 NFS）
-
O_TRUNC 創建不是原子的（FUSE 限制）
文件訪問權限
所有文件和目錄都歸用戶 root 所有 並擁有組 www-data。 只有 root 有寫權限，但組 www-data 可以讀取大多數文件。 以下路徑下的文件：
/etc/pve/priv/
/etc/pve/nodes/${NAME}/priv/
只能通過 root 訪問。
技術
我們使用 Corosync 集群引擎的集群通信，和 SQlite 數據庫文件。 文件系統是在用戶空間實現的，使用 FUSE 。
文件系統布局
文件系統掛載在：
/etc/pve
文件
符號鏈接
用於調試的特殊狀態文件 (JSON)
啟用/禁用調試
您可以通過以下方式啟用詳細的系統日志消息：
echo "1" >/etc/pve/.debug
並禁用詳細的系統日志消息：
echo "0" >/etc/pve/.debug
恢復
如果您的 Proxmox VE 主機有重大問題，例如硬件問題，僅復制 pmxcfs 數據庫文件 /var/lib/pve-cluster/config.db 可能會有所幫助並將其移動到新的 Proxmox VE 主機。 在新主機上（沒有任何VM運行），您需要停止 pve-cluster 服務並替換 config.db 文件（需要權限 0600 )。 然后， 根據 丟失 Proxmox VE 主機 /etc/hostname 和 /etc/hosts，然后重新啟動並檢查。 （不要忘記你的 VM/CT 數據）
刪除集群配置
推薦的方法是刪除節點后重新安裝節點到你的集群。 這確保所有 secret 集群/ssh 密鑰和任何共享配置數據被破壞。
在某些情況下，您可能更喜歡將節點放回本地模式，而無需重新安裝，這在分離一個節點而不重新安裝
從故障節點中恢復或移動Guest
對於 nodes/<NAME>/qemu-server/(VMs) 和 nodes/<NAME>/lxc/(containers)，Proxmox VE 將包含節點 <NAME> 視為相應Guest的所有者。 這個概念允許使用本地鎖而不是昂貴的集群范圍的鎖來防止並發Guest配置更改。
因此，如果Guest的擁有節點發生故障（例如，由於電源停電，fencing 事件，..），常規遷移是不可能的（即使所有磁盤位於共享存儲上）因為這樣的本地鎖 （死鎖）擁有節點是無法獲得的。 這對於 HA 管理的Guest來說不是問題，因為 Proxmox VE 的高可用性堆棧包括必要的（集群范圍內的）鎖定和看門狗功能，以確保正確從受保護的節點自動恢復Guest。
如果非 HA 管理的Guest只有共享磁盤（並且沒有其他本地資源僅在故障節點上配置），手動恢復只需從失敗的節點中移動Guest配置文件即可。失敗節點的目錄中的 /etc/pve/ 到一個在線節點的目錄（其改變Guest的邏輯所有者或位置）。
例如，將 ID 為 100 的 VM 從 node1 節點恢復到另一個 node2 節點，使用以下命令在集群的任何成員節點上以 root 登錄時執行：
mv /etc/pve/nodes/node1/qemu-server/100.conf /etc/pve/nodes/node2/
在手動恢復這樣的Guest之前，請務必確保故障源節點確實被關閉/隔離。 否則 mv 命令 違反了 Proxmox VE 鎖定原則，這可能會導致意外結果。
具有本地磁盤（或其他本地資源）的Guest在故障節點上可用）不能像這樣恢復。 要么等待失敗的節點重新加入集群或從備份中恢復這些Guest。