RBD as Proxmox VE storage

Intermediate⏱ ~17 mincephrbdpvesm

What you'll learn

Configure RBD storage in Proxmox VE
Understand what Proxmox manages and what it does not
Choose pool and image settings for VM workloads
Diagnose storage configuration problems

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

RBD is the standard Proxmox storage backend for VM disks, and most of the configuration is done once. The parts that matter are the ones that are easy to get wrong and hard to change later.

Configuring the storage

# on the Ceph side
ceph osd pool create pve-vms 128 128 replicated
ceph osd pool application enable pve-vms rbd
rbd pool init pve-vms

ceph auth get-or-create client.pve \
  mon 'profile rbd' \
  osd 'profile rbd pool=pve-vms' \
  mgr 'profile rbd pool=pve-vms'

# on the Proxmox side
pvesm add rbd ceph-vms \
  --pool pve-vms \
  --monhost '10.0.0.11,10.0.0.12,10.0.0.13' \
  --username pve \
  --content images,rootdir \
  --krbd 0

# /etc/pve/storage.cfg
rbd: ceph-vms
        pool pve-vms
        monhost 10.0.0.11,10.0.0.12,10.0.0.13
        username pve
        content images,rootdir
        krbd 0

The keyring goes in /etc/pve/priv/ceph/ceph-vms.keyring, named after the storage ID.

What Proxmox manages

Managed	Not managed
Image creation and deletion	pool creation
Image naming (`vm-<id>-disk-N`)	CRUSH rules
Snapshots via the VM snapshot feature	pool `size` and `min_size`
Live migration using shared storage	Ceph health
Resize operations	quota configuration

Proxmox treats the pool as a namespace it owns and manages images within it; everything about the pool itself remains a Ceph administration task.

The `krbd` setting

krbd 0    → librbd via QEMU (default for VMs)
krbd 1    → kernel RBD (required for containers)

Use	Setting
VM disks	`krbd 0` — librbd, full feature support
Container rootfs	`krbd 1` — containers need a block device
Both on one storage	define two storage entries

Container storage with krbd 1 requires image features compatible with the node’s kernel.

Settings that matter for VM workloads

# cache mode, per VM disk
qm set 100 --scsi0 ceph-vms:vm-100-disk-0,cache=writeback,discard=on,iothread=1

Setting	Effect
`cache=writeback`	client-side caching; safe with a flushing guest
`discard=on`	guest TRIM reclaims space in the RBD image
`iothread=1`	a dedicated I/O thread per disk
`ssd=1`	advertises the disk as non-rotational to the guest

discard=on is the one most often omitted, and without it deleted guest data is never reclaimed in the cluster.

Diagnosing configuration problems

pvesm status
pvesm list ceph-vms
rbd -p pve-vms ls
ceph auth get client.pve

Symptom	Cause
Storage inactive	monitor addresses wrong, or keyring missing
Permission denied	capability mismatch on the client key
Images visible in Ceph but not Proxmox	naming convention mismatch
Container creation fails	`krbd 0`, or unsupported image features

Quiz

Knowledge check · 4 questions

Q1. What happens to freed guest filesystem space without `discard=on`?

It is reclaimed on the next VM reboot, when the guest replays its filesystem journal and the freed extents are released Ceph reclaims it during the next deep scrub, which compares the image's allocated extents against the guest filesystem map It remains allocated in the RBD image indefinitely, so cluster usage grows regardless of guest deletions The guest filesystem cannot reuse it either, so the VM reports free space that no subsequent write is able to occupy
Q2. Proxmox will create and delete images in a pool whose `size` and CRUSH rule it knows nothing about.

True False
Q3. Configure Proxmox RBD storage for a mixed VM and container environment.

A Proxmox cluster will run both VMs and LXC containers backed by Ceph. One RBD storage entry is currently configured with krbd 0.
Q4. Why does Proxmox derive image names from the VM ID rather than storing a mapping?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Set discard=on on every Proxmox VM disk — without it, guest deletions never reclaim cluster capacity and the growth is monotonic. Use separate storage entries for VMs (krbd 0) and containers (krbd 1); containers need a kernel block device and the feature sets differ.

Cross-course references

Kubernetes: the RBD CSI driver faces the same krbd-versus-librbd choice
Linux: TRIM/discard propagation through storage layers is the same reclamation problem