When building the Lab if you hit the following error:

ERROR [kvm.storage.LibvirtStorageAdaptor] (AgentRequest-Handler-1:[]) (logid:5a91eee6) Failed to create RBD storage pool: org.libvirt.LibvirtException: failed to connect to the RADOS monitor on: 10.100.99.21,: No such file or directory
2026-09-02 01:36:54,642 ERROR [kvm.storage.LibvirtStorageAdaptor] (AgentRequest-Handler-1:[]) (logid:5a91eee6) Failed to create the RBD storage pool, cleaning up the libvirt secret

The trouble shooting steps are as follows:

This is a known, documented, one-line fault, and it's not the server hardware. It's the Ceph authentication client, not your networking or your monitor address.

What the error really means. When you add the Zone, CloudStack asks a KVM host to register the RBD (Ceph) primary storage pool, and libvirt opens a connection to your monitor at 10.100.99.21. That monitor address is correct. The No such file or directory message is misleading — the true cause is that the cephx user CloudStack logs in as (client.cloudstack) is missing its mgr capability.

Here's the mechanism: creating the pool makes libvirt stat the cluster, and modern Ceph serves that statistic through the manager (mgr) daemon. A client with only mon and osd capabilities can happily list pools and create/delete RBD images from the command line — so every smoke test passes — but the moment libvirt asks the mgr for cluster stats, it gets a file-not-found from a cluster that is otherwise working perfectly. That's exactly why retrying the wizard four times gave the same result: the wizard was never the problem.

Confirm it first (30 seconds). On ceph-01 (10.100.99.21):

sudo cephadm shell -- ceph auth get client.cloudstack

Look at the caps lines. You want to see all three of these:

caps mon = "profile rbd"
caps osd = "profile rbd pool=rbd-prod, profile rbd pool=rbd-dev"
caps mgr = "profile rbd pool=rbd-prod, profile rbd pool=rbd-dev"

If the caps mgr line is missing (or the client doesn't exist at all), that's your fault confirmed.

The fix. Set the full capability set — ceph auth caps replaces all caps, so list all three. Run this on ceph-01:

sudo cephadm shell -- ceph auth caps client.cloudstack \
    mon 'profile rbd' \
    osd 'profile rbd pool=rbd-prod, profile rbd pool=rbd-dev' \
    mgr 'profile rbd pool=rbd-prod, profile rbd pool=rbd-dev'

Important and reassuring: this does not change the key. The RADOS Secret you already entered in CloudStack stays valid — you don't need to touch the storage form. Just go back and add the Zone again; the pool will register this time.

(If ceph auth get client.cloudstack instead reports that the client doesn't exist, you skipped the client-creation step — create it with the command in the deployment guide §5.7 and use the printed key as your RADOS Secret, with RADOS User set to cloudstack.)

Where this is in the book, so you can see the full explanation: it's the deployment guide, Phase 5, 5.7 "The Dedicated cephx Client" — the paragraph right after the ceph auth get-or-create command describes this precise error.

The troubleshooting guide's Section 6 (CloudStack Layer) and the diagnostic sweep in Section 8 are your companions for anything else.

Two quick sanity checks only if the above somehow isn't it (it almost certainly is):

1. On the KVM/compute host (not the Ceph nodes), confirm ceph-common and qemu-block-extra are installed — deployment guide Phase 7.2, troubleshooting §6.6. These give the hypervisor its RBD driver.
2. In the CloudStack primary-storage form, the RADOS User field should be exactly cloudstack (no client. prefix), matching the cephx user you just granted caps to.

If you made it this far you are one capability away from a working zone.

This article is powered by MatrixClaw using Testlab hardware and ebook content as the system build & diagnostic aide tools.