CephLI · Host PreparationHost Preparation
Hostnames and resolution on Ceph hosts
What you'll learn
- Configure hostnames consistently
- Ensure forward and reverse resolution works
- Diagnose hostname mismatches
- Verify resolution across the fleet
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
The orchestrator identifies hosts by name and matches placement against that name. A mismatch between what the host reports and what the cluster knows produces a host that appears healthy and never receives daemons — a symptom with no obvious cause.
Setting the hostname
hostnamectl set-hostname ceph-osd-01.example.com
hostnamectl status
hostname
hostname -f
hostname -s
Decide whether the cluster uses short names or FQDNs and apply it consistently. Mixing them across a fleet is what produces the mismatches.
cephadm bootstrap --mon-ip 10.20.0.10 --allow-fqdn-hostname
ceph orch host add ceph-osd-01.example.com 10.20.0.21
--allow-fqdn-hostname is needed if hosts report FQDNs, and the names
used in host add must match what the hosts report.
Resolution
# forward
getent hosts ceph-osd-01
dig +short ceph-osd-01.example.com
# reverse
dig +short -x 10.20.0.21
# from every host to every other
for h in ceph-mon-01 ceph-osd-01 ceph-osd-02; do
getent hosts "$h" || echo "FAIL forward $h"
done
Both directions, from every host. /etc/hosts entries are an acceptable
fallback where DNS is unavailable, provided they are consistent across the
fleet — inconsistent hosts files are worse than no entries at all.
Diagnosing a mismatch
ceph orch host ls
# HOST ADDR LABELS STATUS
# ceph-osd-01 10.20.0.21 osd
ssh ceph-osd-01 hostname
# ceph-osd-01.example.com ← mismatch
The cluster knows ceph-osd-01; the host reports the FQDN. Placement
matches on the cluster’s name and the daemon deployment reports the host’s,
so they never align.
ceph orch host rm ceph-osd-01
ceph orch host add ceph-osd-01.example.com 10.20.0.21 --labels osd
Removing and re-adding with the correct name is the fix. Do it before OSDs are deployed if possible.
Verifying across the fleet
for h in $(ceph orch host ls --format json | jq -r '.[].hostname'); do
reported=$(ssh "$h" hostname 2>/dev/null || echo UNREACHABLE)
[ "$h" = "$reported" ] || printf '%-30s cluster=%s reported=%s\n' "$h" "$h" "$reported"
done
Anything printed is a mismatch.
Quiz
Knowledge check · 4 questions
Q1. A host is added successfully, shows as healthy, and never receives daemons. What is the likely cause?
Q2. Consistent /etc/hosts entries are an acceptable substitute for DNS, while inconsistent ones are worse than no entries at all.
Q3. Standardise naming across an inconsistent fleet.
A cluster of 30 hosts was built over two years by different people. Some hosts report short names, some FQDNs. Several hosts have been added to the orchestrator under names that do not match what they report.
Q4. Why does reverse DNS matter even though forward resolution is sufficient for connectivity?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Establish a single naming convention at bootstrap and verify every host reports what the cluster recorded; the mismatch is silent and its symptom — a healthy host with no daemons — points nowhere obvious. Run the comparison loop after any host provisioning change.
Cross-course references
- Kubernetes: node name mismatches produce the same silent scheduling failure
- Linux: consistent naming across a fleet is a prerequisite for any orchestration tool