Ceph with Proxmox VE hyper-converged clusters

Ceph with Proxmox VE: when hyper-converged storage fits your cluster

If your team wants Proxmox VE guests on Ceph RBD, the first decision is whether Ceph runs on the same nodes that host the hypervisors (hyper-converged) or on a separate storage cluster. Proxmox VE integrates Ceph RBD and CephFS as network storage, so both layouts are supported from the guest side. The Proxmox-side tooling for building Ceph on its own nodes is pveceph, which is the method this page covers. The rest of the page answers when running Ceph on Proxmox nodes fits, what minimum node, OSD and memory planning looks like, how the networks are separated, and what day-two work changes when storage and compute share hardware.

Hyper-converged storage fits best when you want one platform to own compute, storage and cluster management, and when your hardware can absorb Ceph daemons next to guest workloads. The trade-off is shared failure. A node that loses a disk, runs out of memory during recovery or needs a reboot affects both its guests and its share of the storage pool. Before committing, confirm with your own sizing exercise whether the nodes you already own have enough spare CPU, memory and drive slots for Ceph's OSDs and monitors, and whether the Ceph hardware recommendations for memory, dedicated drives per OSD and bonded networks can be met without starving the hypervisor. Ask your Proxmox partner or hardware vendor to show the sizing math in writing.

Ceph itself is licensed under LGPL-2.1 or LGPL-3, and Proxmox VE is licensed under the GNU Affero General Public License, version 3, so neither platform imposes a license fee on the software. Paid Proxmox VE subscriptions buy support entitlements and access to the enterprise repository, which the Proxmox documentation recommends for production. Ceph has no paid edition from the project itself, so any Ceph support you buy comes from a vendor or service provider. Confirm which subscription tier and support path cover the Ceph packages you will run, since the Proxmox pricing and Ceph support models are separate decisions.

What you need in place before pveceph

Ceph on Proxmox VE depends on decisions made before the first pveceph command runs: the Proxmox and Debian base, the repository you subscribe to, the Ceph release line, and enough nodes to hold quorum. Network, time sync and drive prerequisites decide whether the cluster stays stable once it carries virtual machine disks.

Proxmox VE and Debian base

Proxmox VE 9.x is built on Debian 13, and the Proxmox VE release you choose is supported at least as long as the matching Debian release receives security support, roughly three years. Confirm the Debian support end date for your release before you commit, because an upgrade of the hypervisor and Ceph together is a larger change than either alone. Plan the Proxmox VE and Debian upgrade window around your Ceph maintenance windows so the two do not overlap.

Enterprise or no-subscription repository

The enterprise repository requires a valid subscription key and is the recommended repository for production. The no-subscription repository is intended for testing and non-production use. Subscriptions are priced per CPU socket per year and differ mainly in support entitlements, so ask the vendor or a reseller for the current quote for every node. Pick the repository before the first node joins, and use the same one on every node so package versions match.

Ceph release line

Two Ceph release lines are actively maintained: Tentacle (20.2.x) and Squid (19.2.x). Choose the line before deployment and record its end-of-life date, since the Ceph release line you start on determines when you must upgrade. Confirm which Ceph release your Proxmox VE version packages through pveceph before you standardize on it, and check the release notes for any cluster-wide upgrade requirements.

Minimum cluster size for quorum and HA

Proxmox VE high availability needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing. Three nodes also give Ceph the monitor majority it needs, so a single node failure leaves the cluster able to vote and keep serving storage. A two-node cluster can run, but it does not give you the same failure tolerance. Plan spare capacity so that the remaining nodes can carry the guests of a failed node.

Network layout and bonding

Plan separate networks for the Ceph cluster, Ceph public traffic and corosync before running pveceph. Ceph hardware guidance advises bonding network links across two switches, so one switch failure does not isolate a node. Keep corosync on its own links where possible, because cluster heartbeat delays caused by storage traffic can trigger fencing. Confirm MTU and VLAN settings match on every node and switch before creation.

Time sync across nodes

Every node needs accurate, synchronized time before the cluster forms, because Ceph monitors and corosync both rely on consistent clocks. Run one time service on all nodes, point it at the same reliable sources, and check offset on each node before creating monitors. Clock skew warnings in Ceph usually trace back to this step, so verify it as a prerequisite rather than fixing it after a health alert.

Drives and OSD media

Each OSD needs a dedicated drive, and the hardware guidance advises enterprise-class SSDs for metadata and moving WAL and DB to shared SSDs when OSDs sit on HDDs. Confirm that every node has matching drive classes and that no disk carries an existing partition table or filesystem you need to keep. Benchmark the planned drives before purchase, because the guidance notes that no two clusters are alike.

How pveceph places Monitors, Managers and OSDs on Proxmox nodes

On a hyper-converged Proxmox VE node, Ceph daemons and Proxmox services share the same CPU, memory, disks and network interfaces. Each data drive you give Ceph becomes an OSD on that node, and the Monitors and Managers are placed on some or all of the nodes depending on your design. Monitors hold the cluster map and must keep quorum, so the number of Monitors and the nodes that host them is a placement decision to confirm for your pveceph version before you build. OSDs are usually the heaviest consumers, especially during recovery. Running alongside them are the Proxmox Cluster File System, which replicates the Proxmox configuration to every node, and corosync, which maintains cluster membership and quorum. Both depend on timely responses, so a node under storage pressure can affect guests, Ceph and cluster membership at the same time.

Ceph separates its traffic into a public network for client and Monitor traffic and a cluster network for OSD replication, recovery and heartbeats. Corosync needs its own link with low and stable latency. Keeping these classes on separate interfaces or VLANs means a large recovery burst on the cluster network does not delay corosync heartbeats or client I/O. The Ceph hardware recommendations advise bonding network links across two switches, which you should apply to each traffic class where your hardware allows it. Confirm the network options that pveceph accepts at initialization, and the corosync link configuration for your Proxmox VE release, in the documentation for the version you run. Also confirm which ports your firewall must allow between nodes, including the Monitor port used by the msgr2 protocol.

Configuration sequence for a Proxmox VE Ceph cluster

This sequence takes bare nodes to a Proxmox VE cluster with a healthy Ceph cluster and an RBD pool that VMs can use. Each step ends with a check so the next step starts from a known-good state.

Prepare networks and bonds across two switches
The network team cables each node with bonded links that span two switches, and defines separate subnets for the Ceph public network, the Ceph cluster (replication) network and the corosync network. Keeping corosync off the storage traffic matters because heavy recovery I/O can delay cluster heartbeats. The step is done when every node can reach every other node on each subnet and a bond reports both links active. Confirm the switch configuration and bond mode with your network engineers and the Proxmox VE networking documentation before you cable anything.
Install Proxmox VE on each node
The platform team installs the same Proxmox VE release on every node, applies the same kernel and firmware baseline, and sets consistent time synchronization and hostnames. Matching versions reduce surprises when pveceph is installed later. The step is done when each node boots, the web interface answers on its management address, and the node reports the expected version. Decide repository access at this point: the enterprise repository requires a subscription key and is the recommended choice for production, while the no-subscription repository suits testing only.
Form the Proxmox VE cluster
An administrator creates the cluster on the first node and joins the others using the corosync network addresses. Proxmox VE replicates configuration across all members, so the join is done once per node from the cluster menu. The step is done when pvecm status shows the expected number of nodes and quorum is reached. Plan for an odd node count or a quorum device if you later intend to use high availability, since the HA guidance calls for at least three nodes for reliable quorum.
Install Ceph and create Monitors and Managers
On each node, the administrator runs pveceph install with the chosen Ceph release, then creates the initial Monitor and Manager on the first node, followed by additional Monitors and Managers on the other nodes. Monitors should sit on nodes that will stay online, and an odd number keeps quorum straightforward. The step is done when ceph -s lists the expected Monitors in quorum and at least one Manager is active. Confirm the Ceph release you intend to run against the active releases list before installation.
Create OSDs on dedicated drives
The storage administrator creates one OSD per dedicated drive, so no OS, Proxmox or guest disk shares a device with Ceph. Where data sits on HDDs, the team places the WAL and DB on shared SSDs, using enterprise-class drives as the hardware recommendations advise. The step is done when ceph osd tree shows every expected OSD up and in, and the OSDs are distributed evenly across nodes. Ask for a memory plan per OSD before purchase, because the hardware recommendations say to size memory for peak use and to benchmark before buying.
Create the RBD pool
The administrator creates a replicated RBD pool through the Proxmox VE interface or pveceph pool create, using a replica count and failure domain that match the number of nodes and the data protection target. Choosing the failure domain at this stage avoids rebuilding placement later. The step is done when ceph health reports the pool with its placement groups active and clean, and no health warnings remain from the new pool. Benchmark the pool with a representative workload before you place production guests on it.
Add the pool as Proxmox storage
The administrator adds the pool as RBD storage in the Proxmox VE datacenter, marking it for VM disks and container volumes as needed. Proxmox VE supports Ceph RBD and CephFS as network storage, and this step connects that storage to every node in the cluster. The step is done when the storage shows as active on all nodes in the web interface. Document which storage ID the cluster uses so backup and migration jobs refer to the correct pool.
Verify cluster health with a test VM disk
The team creates a test virtual machine, allocates a disk on the new Ceph storage, writes data, takes a snapshot and migrates the VM to another node. They then power off one node in a controlled window and confirm that Ceph reports degraded but recovering placement groups, and that the VM remains reachable. The step is done when quorum holds, ceph -s returns to HEALTH_OK after recovery, and the test VM's disk reads back the written data. Record these results as the acceptance baseline for later changes.

Sizing choices: node count, OSD count and memory per OSD

A three-node layout is the smallest arrangement most teams consider for a hyper-converged Proxmox VE cluster, because Proxmox VE high availability needs at least three cluster nodes for reliable quorum. A pilot tests the pveceph workflow, network separation and day-two tasks before production data arrives. It is useful for learning, but it leaves little room when a node is down, because the remaining nodes must absorb both recovery traffic and guest load.

Failure domain reality: With one host per failure domain, a single node failure leaves Ceph to recover data onto fewer hosts, so confirm how the CRUSH rule and replica count behave in that state.
Memory headroom: Size memory for peak use during recovery and scrubs, not for calm periods, and keep guest memory separate in your plan.
Benchmark first: Run benchmarks on the pilot hardware, since the Ceph hardware recommendations note that no two clusters are alike.
Network layout: Test separate cluster, public and corosync networks on the pilot, including how bonded links behave when one switch fails.
Upgrade path: Rehearse a Proxmox VE and Ceph upgrade on the pilot before it holds anything you cannot rebuild.

Ask the vendor or consultant to confirm the exact minimum node and OSD counts in the Ceph hardware recommendations and the Proxmox documentation, and to state in writing which pilot behaviors are not representative of production.

What day-two operations look like on shared hardware

On a hyper-converged cluster, every node maintenance task touches two systems at once: the Proxmox VE hypervisor that runs your guests and the Ceph daemons that hold their disks. Plan upgrades as two version tracks. Proxmox VE support follows the matching Debian release, which the Proxmox VE FAQ describes as roughly three years of support, so the Proxmox VE 8 line on Debian 12 reached end of life in August 2026. Ceph handles this differently: the Ceph releases page says actively maintained releases receive periodic backports and security fixes, and it lists estimated end-of-life dates for each release. Confirm both dates for your versions before you schedule a window, and check that the Proxmox VE release you move to supports the Ceph release you run, because each track can force the other.

Node maintenance follows a fixed order. Confirm Ceph health is HEALTH_OK before you start, then set the OSDs on the target node to noout so Ceph does not start rebuilding data while the node is briefly offline. Migrate or shut down guests with Proxmox VE's HA manager or your own runbook, then stop the node's OSDs and monitors in a controlled way. Keep enough monitors in quorum at every step, and only move to the next node once the cluster has returned to a clean state. Under HA, a failed node is fenced by its watchdog before guests restart elsewhere, so a planned reboot should be scripted to avoid unexpected fencing. Test this sequence on a non-production cluster first, because the exact commands depend on your release.

Drive replacement and recovery are where guest I/O and Ceph compete. When an OSD fails, Ceph backfills its placement groups onto remaining drives, and that traffic shares the same NICs, switches and disks as your virtual machine disks. Set recovery and backfill limits deliberately rather than accepting defaults, and decide in advance what latency your VMs can tolerate during a rebuild. Keep spare capacity so the cluster can absorb a failed drive without reaching full ratios. Ask your team to rehearse one drive replacement end to end, including ceph osd out, removing the old OSD, and confirming the new one rejoins. The recovery behavior you observe in that rehearsal is the best input for your performance and tuning plan.

Proxmox objects and Ceph objects that must match

This table maps each Proxmox VE identifier the integration depends on to the matching Ceph object and the place each one is set. Read it before creating the first RBD storage entry, because a mismatch in any row usually surfaces as a storage that is listed but cannot be used by guests.

Proxmox item	Ceph item	Where it is set	What breaks if they differ
RBD storage ID	Pool name and cluster identity	Datacenter storage configuration in Proxmox VE, `pool` and `monhost` keys	Guests fail to start or disks cannot be created because the storage points at a pool that does not exist
Monitor addresses	Monitor addresses on the Ceph public network	`monhost` in the storage entry, or the cluster monitor map in Ceph	Proxmox nodes cannot reach a monitor, so every RBD operation times out even though Ceph reports healthy
CephX user for RBD	Client key with capabilities on the pool	Keyring copied to `/etc/pve/priv/ceph/` under the storage ID name, and `username` in the storage entry	Authentication fails on some or all nodes, or the user can see the pool but cannot create images
RBD namespace (if used)	Namespace inside the pool	`namespace` option in the storage entry and the CephX capability scope	Images are created in the default namespace while the client looks elsewhere, causing missing disks after a migration
Public network subnet	`public_network` in the Ceph configuration	Ceph cluster configuration and Proxmox node interfaces on that VLAN or bridge	Clients route storage traffic over the wrong link, or the network is missing from one node entirely
Cluster network subnet	`cluster_network` in the Ceph configuration	Ceph configuration on OSD hosts, separate from Proxmox corosync rings	Replication and recovery compete with client I/O on the wrong link, or OSDs report heartbeat failures during backfill
Corosync network	Not a Ceph setting, but must stay isolated from Ceph traffic	Proxmox cluster configuration and corosync link addresses	Heavy Ceph recovery traffic delays cluster messages, which can trigger spurious node fencing in HA setups
Keyring and ceph.conf on each node	Same monitor list and fsid on every node	`/etc/pve/ceph.conf` shared through the cluster file system	A node that was not updated keeps stale monitor addresses and fails after a monitor is replaced

Security settings for hyper-converged Ceph

A hyper-converged Ceph cluster on Proxmox VE shares nodes between storage, guests and administration, so one weak setting can reach all three. The cards below cover the transport, identity, network and access controls to set and verify for your Ceph release before the cluster carries production VM disks.

Msgr2 secure mode on port 3300

Ceph's messenger v2 protocol listens on port 3300 and offers a secure mode that encrypts all traffic after authentication with AES-GCM and adds integrity checks. On a hyper-converged cluster, VM disk I/O and monitor traffic cross the same nodes, so confirm that secure mode is set for every daemon and client path you use. Check the setting against the messenger documentation for your Ceph release, and test that older clients can still connect before you enforce it.

CephX users scoped per consumer

Give each consumer its own CephX user with capabilities limited to the pools it needs. A Proxmox VE storage definition for RBD should not share a key with backup jobs, CephFS mounts or other clusters. Review the caps of every key with the Ceph auth commands on your release, and rotate keys on a schedule that you document. Keep the keyring files on the Proxmox nodes readable only by the services that use them.

Separate cluster network from guest traffic

Keep the Ceph cluster network for OSD replication and recovery on its own interfaces, separate from the public network used by clients, the corosync network and guest or management traffic. Mixing replication with corosync heartbeats can cause false node fencing under load. Bond links across two switches where the hardware allows it, and verify routes and MTU on each network from every node.

Dashboard access and single sign-on

The Ceph Dashboard supports single sign-on through SAML 2.0, and through OAuth2 when cephadm runs the Management Gateway and OAuth2 Proxy services. Choose one method, disable local accounts you do not need, and assign dashboard roles deliberately. Confirm the dashboard is reachable only from your management network, and check which SSO options your Ceph release supports before you plan the identity integration.

cephadm and host access control

cephadm manages Ceph daemons as containers, so anyone with root on a host or with the orchestrator role can change the cluster. Limit SSH access to named administrators, restrict who holds the cephadm SSH key, and keep the Proxmox VE and Ceph admin accounts separate. Note that Proxmox VE can deploy Ceph with its own tooling, so confirm which tool owns the cluster configuration before you change it by hand.

Verify settings against your release

Record the Ceph release and Proxmox VE version on every node, then check each setting above against the documentation for that combination. The Ceph releases page lists which releases are actively maintained and their estimated end-of-life dates, and Proxmox VE follows the Debian release it is built on. Schedule a review at each upgrade, because defaults and supported options change between releases.

Common failures when Ceph runs on Proxmox nodes

This table pairs common symptoms of a hyper-converged Ceph cluster on Proxmox VE nodes with their likely causes, the first check to run and the fix. Read each row as a triage starting point, then confirm the cause on your own nodes before changing configuration. The main takeaway is that most failures trace back to shared hardware, shared networks or capacity headroom, so check those before touching the cluster.

Symptom	Likely cause	First check	Fix
Monitors lose quorum after a network change	A switch, VLAN or bonding change on the Ceph public or corosync network cut Monitors off from each other	Confirm which Monitors are in quorum and whether each node can reach the others on the public network and the corosync network	Restore the previous network path or correct the change on every node, then verify Monitor quorum before resuming maintenance
Slow requests when recovery competes with guest I/O	Backfill or recovery traffic uses the same disks and links as running virtual machines on the shared nodes	Check cluster health for slow request warnings and see whether recovery is active during the slow period	Limit recovery concurrency and schedule heavy rebalancing away from peak guest hours, then retune with a benchmark
OSDs reach full state after a node fails or capacity is added late	Usable capacity was sized without enough headroom for a node loss or for guest disk growth	Compare raw and used capacity per OSD and per pool, and simulate the space left if one host is removed	Add drives or nodes, reduce replica pressure on the pool, or move non-essential disks off the cluster before writes stop
Mismatched network configuration between nodes	One node has a different MTU, bond mode, subnet or interface name than its peers	Compare the network configuration file and interface state on every node, including MTU on each link	Align the configuration across all nodes and confirm the same MTU path end to end before restarting services
Storage shows as unavailable in Proxmox after a CephX key change	The Proxmox storage definition or keyring still refers to the old CephX user or key	Check the Ceph client keyring on each node and the matching storage entry in the Proxmox configuration	Update the keyring and storage definition consistently on every node, then confirm the storage is active in each node's view
Monitor or manager placement drifts after node changes	Services were added or removed on nodes without updating placement, so too few daemons remain for the cluster	List monitor and manager daemons and compare them with the number of nodes intended to run them	Redeploy or add daemons on healthy nodes and confirm quorum before removing any other service
Guests stall after a single node reboot	Guest disks are not redundant across hosts, or the failure domain is set to the OSD level instead of the host level	Review the CRUSH failure domain and the replica placement for the pool used by guest disks	Plan the failure domain at the host level for production pools and retest a planned node reboot before go-live

Questions buyers ask before running Ceph on Proxmox VE

How much does running Ceph on Proxmox VE cost?

Software licenses are the smallest recurring line, and the main costs are hardware, people and any support you buy. Ceph's source is licensed under LGPL-2.1 or LGPL-3, and the project itself offers no paid edition, so there is no license fee to the Ceph project. Proxmox VE subscriptions are priced per CPU socket per year: 120 euros for Community, 370 euros for Basic, 550 euros for Standard and 1,100 euros for Premium (Proxmox VE pricing). Hardware is mostly one-time spending: a dedicated drive per OSD, SSDs for WAL and DB, memory sized for peak use and bonded network links across two switches. Services are a separate cost, either a fixed-scope project or a retainer for upgrades and testing. A quote should show each of these as its own line, with the recurring items marked.

How long does it take to reach a working cluster?

The timeline depends mostly on hardware lead times, network readiness and how many design decisions are still open, so no single duration fits every site. Work usually runs in stages: confirm node and drive counts, prepare switches for the public, cluster and corosync networks, benchmark the hardware, deploy Ceph and Proxmox VE, then test failure and recovery before guests move in. Late hardware and unconfigured switches tend to cause the most delay. Ask any partner for a written schedule with milestones, the dates your team must meet and the acceptance tests that close each stage. Also agree who carries the cost of delays caused by late hardware or late access, because those decisions change the schedule more than the build itself.

What must our team supply for a Proxmox VE and Ceph cluster?

Your team supplies the hardware, the network, access and the people who will decide and run the cluster. High availability in Proxmox VE needs at least three cluster nodes for reliable quorum, shared storage and watchdog-based fencing. The Ceph hardware guidance calls for a dedicated drive per OSD, shared SSDs for WAL and DB on HDD-based OSDs, enterprise-class SSDs for metadata and bonded links across two switches. Your switches must carry separate public, cluster and corosync networks. You also need out-of-band management, power and cooling plans for each node, and named owners for storage, networking and virtualization. Ask for a line-by-line check of these items against your current inventory before the build starts.

Can our own team build and run this without a partner?

Yes, if your team already runs Linux, Ceph and Proxmox VE in production and has time to learn the parts it does not know. Both projects publish their documentation, and cephadm deploys Ceph as containers, which keeps day-two work more uniform. The hardest parts are usually not the first install but the decisions that are expensive to change later: pool and failure domain design, memory per OSD, network layout and the order of upgrades across two products. Make a short skills list and name who handles a failed drive at night. If several items are missing, a fixed-scope engagement can cover design, build and handover, and a retainer can cover upgrades and recurring testing.

Which Proxmox VE subscription tier do we need?

Choose the tier by the support response time you need, because all subscription tiers include the same software features. Community has no support tickets. Basic includes 3 tickets with a 1 business day response, Standard includes 10 tickets with a 4-hour response and Premium includes unlimited tickets with a 2-hour response. The subscription also grants access to the enterprise repository, which requires a valid subscription key and is the recommended repository for production. The software can run without a subscription, but the no-subscription repository suits testing and non-production use. Confirm the socket count per node before you request a quote, because pricing scales with sockets, not with nodes or storage.

When is a separate Ceph cluster a better choice than hyper-converged?

A separate Ceph cluster fits better when storage must serve many consumers or grow on a different schedule from compute. In a hyper-converged design, OSDs, monitors and recovery traffic share CPU, memory and network with your virtual machines, so a large rebuild can slow guests and a guest spike can slow storage. Separate clusters let you size storage, networks and failure domains on their own terms and upgrade each side independently. Hyper-converged remains a sound choice for smaller footprints where one team owns both layers and workload I/O is predictable. Ask for sizing that shows peak OSD memory, recovery bandwidth during a node loss and what happens to guests when the pool approaches full.

When do Rook or an external Ceph cluster fit better?

Rook fits when the consumers are Kubernetes workloads and your team already operates Kubernetes. An external Ceph cluster fits when several platforms share one storage pool and you want Ceph managed separately from both the hypervisors and the container platform. The cephadm documentation points to Rook as the alternative way to deploy Ceph on Kubernetes, and the CNCF lists Rook as a Graduated project since October 7, 2020 (CNCF Rook project). Running Ceph inside Kubernetes ties storage upgrades to the Kubernetes operating model, which suits some teams and burdens others. Before choosing, list every consumer, who upgrades each layer and how each consumer will authenticate to the cluster.

When hyper-converged Ceph is the wrong design

Hyper-converged Ceph is the wrong design when storage load and compute load are likely to fight for the same hardware. On a Proxmox VE cluster, every node runs guests and also runs Ceph OSDs, Monitors and possibly Managers. Client I/O from many consumers, such as a large number of virtual machines with heavy write patterns, competes with OSD CPU, memory and disk bandwidth on the node that hosts the guest. The Ceph hardware recommendations ask you to size memory for peak use rather than calm periods, and that advice becomes harder to meet when the same node must also hold guest memory for busy VMs. Before committing, ask for a benchmark of your own workload on the proposed nodes, and compare the result against a design where storage nodes are separate from the hypervisors.

Hyper-converged layouts also lock compute and storage growth together. If you need more capacity but your VMs are CPU-bound, or the reverse, adding a Proxmox VE node adds both, and you may buy processors or memory you do not need to get drives. A separate Ceph cluster lets you add OSD hosts for capacity and hypervisors for compute, and it lets storage be shared with other platforms such as OpenStack or Kubernetes through the Ceph RBD and CephFS interfaces that Proxmox VE already consumes as external storage. The trade-off is more hardware to buy, a second set of nodes to patch, and a network design with the cluster, public and corosync networks kept separate across both sides. Ask your team to write down which of these two growth paths is more likely in the next few years before deciding.

Operations is the third test. Proxmox VE and Ceph both require node reboots, kernel updates and occasional drain operations, and on a hyper-converged cluster each reboot moves an OSD host and a hypervisor at once. If your staff cannot schedule shared-node maintenance windows, or if guests must stay up during routine work, a split design usually fits better, because storage nodes can be drained and patched on their own schedule. Confirm with your operators how they handle a node that must stay out of service for longer than planned, how recovery traffic will affect guests, and whether the quorum and high-availability requirements in the Proxmox VE documentation can still be met while that node is offline.

How DeployOpen scopes and delivers Ceph on Proxmox VE

DeployOpen plans, builds and hands over Ceph storage on Proxmox VE nodes inside infrastructure you control. We start from a written scope that sets node count, OSD layout, network separation and the day-two runbook, so your team knows what is built, tested and documented before the cluster carries guest disks.

How we scope

Engagements are fixed-scope, with the node count, OSD layout, network plan and deliverables agreed in writing before work starts.
We review your hardware against the Ceph hardware recommendations, covering drive-per-OSD layout, WAL and DB placement and memory per OSD.
We confirm whether your workloads need HA, which determines the three-node minimum, shared storage and watchdog fencing plan.

How we build

We deploy Ceph with pveceph on each node and separate the public, cluster and corosync networks as the written design specifies.
We bond network links across two switches where the design calls for it, and test failover before any guest disks are placed on Ceph RBD.
We benchmark the cluster on your hardware, since the Ceph hardware recommendations advise measuring before buying and no two clusters are alike.

How we hand over

You receive the as-built configuration, network diagram, pool and CRUSH rule layout, and a record of each test result.
We document day-two procedures for drive replacement, node maintenance, adding OSDs and recovering from a failed node on shared hardware.
Your team runs a knowledge transfer session covering health warnings, memory sizing for peak use and upgrade steps for Proxmox VE and Ceph.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build engagement.
Retainers can cover coordinated Proxmox VE and Ceph upgrades, checked against each product's release and support dates before a change window.
Confirm with your vendor which Proxmox VE subscription tier and support entitlements your production cluster requires before go-live.