Ceph RBD als KVM-VM-Storage mit libvirt

Eine einzelne lokale Festplatte ist ein Single Point of Failure. Indem Sie Ihre KVM-VMs mit Ceph RBD (RADOS Block Device) unterlegen, wird jede VM-Festplatte zu einem replizierten, selbstheilenden Objekt, verteilt über Ihren Storage-Cluster — die VM überlebt eine defekte Platte oder sogar einen ausgefallenen Host, und Sie können sie zwischen Hypervisoren live migrieren, weil der Speicher geteilt ist. Genau so unterlegen OpenStack Nova und Cinder Instanzen in der Produktion.

Diese Anleitung verbindet Compute und Storage: Sie binden einen KVM/libvirt-Host an einen bestehenden Ceph-Cluster an, erstellen ein RBD-Image, registrieren es als libvirt-Storage-Pool und hängen ein ausfallsicheres Block-Device an eine VM. Sie setzt voraus, dass Sie bereits einen Ceph-Cluster mit cephadm aufgebaut haben und mit den virsh-Grundlagen vertraut sind.

Voraussetzungen

Sie benötigen einen gesunden Ceph-Cluster mit einem rbd-Pool, einen KVM/libvirt-Host unter Ubuntu 24.04 mit installiertem qemu-kvm und libvirt-daemon-system, Netzwerkerreichbarkeit vom Hypervisor zu den Ceph-Monitoren (Port 6789/3300) sowie Admin-Zugriff auf beide. Die Beispiele nutzen einen Monitor unter 10.10.10.11.

Schritt 1: Den Ceph-Client auf dem Hypervisor installieren

Der libvirt/QEMU-Host benötigt die Ceph-Client-Bibliotheken und das RBD-Werkzeug:

sudo apt update
sudo apt install -y ceph-common

Kopieren Sie /etc/ceph/ceph.conf von einem Cluster-Knoten, damit der Client die Monitore kennt:

sudo scp root@ceph-1:/etc/ceph/ceph.conf /etc/ceph/ceph.conf

Schritt 2: Einen dedizierten Ceph-Benutzer für libvirt anlegen

Geben Sie libvirt niemals den Admin-Schlüssel. Legen Sie einen beschränkten Benutzer client.libvirt an, der nur den rbd-Pool berühren darf. Auf einem Ceph-Knoten:

sudo cephadm shell -- ceph auth get-or-create client.libvirt \
  mon 'profile rbd' \
  osd 'profile rbd pool=rbd'

Geben Sie den Schlüssel aus — im nächsten Schritt übergeben Sie ihn libvirt als Secret:

sudo cephadm shell -- ceph auth get-key client.libvirt

Schritt 3: Das Ceph-Auth-Secret in libvirt definieren

libvirt speichert den Ceph-Schlüssel als Secret-Objekt. Erstellen Sie eine Definitionsdatei mit einfach gequoteten Attributen:

cat > secret.xml <<'EOF'
<secret ephemeral='no' private='no'>
  <usage type='ceph'>
    <name>client.libvirt</name>
  </usage>
</secret>
EOF
virsh secret-define --file secret.xml

Das gibt eine UUID aus. Binden Sie den eigentlichen Ceph-Schlüssel daran (ersetzen Sie Schlüssel und UUID):

virsh secret-set-value \
  --secret 2a1b... \
  --base64 AQD...ihr-schluessel...==

Schritt 4: Ein RBD-Image für die VM erstellen

Provisionieren Sie ein 20 GiB großes Block-Image im rbd-Pool. Das Abschalten neuerer Features hält es mit dem QEMU-RBD-Treiber kompatibel:

rbd create rbd/vm-disk1 --size 20480 \
  --image-feature layering
rbd info rbd/vm-disk1
rbd ls rbd

Schritt 5: Einen RBD-basierten libvirt-Storage-Pool registrieren

Definieren Sie einen libvirt-Pool, der auf den Ceph-rbd-Pool abbildet und die Secret-UUID aus Schritt 3 referenziert:

cat > rbd-pool.xml <<'EOF'
<pool type='rbd'>
  <name>rbd-libvirt</name>
  <source>
    <name>rbd</name>
    <host name='10.10.10.11' port='6789'/>
    <auth username='libvirt' type='ceph'>
      <secret uuid='2a1b...'/>
    </auth>
  </source>
</pool>
EOF
virsh pool-define rbd-pool.xml
virsh pool-start rbd-libvirt
virsh pool-autostart rbd-libvirt

Bestätigen Sie, dass libvirt die Images im Pool sieht:

virsh vol-list rbd-libvirt

Schritt 6: Das RBD-Device an eine VM anhängen

Beschreiben Sie die Netzwerk-Festplatte und hängen Sie sie an eine laufende Domain an. Der auth-Block verweist auf dasselbe Secret:

cat > disk.xml <<'EOF'
<disk type='network' device='disk'>
  <driver name='qemu' type='raw'/>
  <source protocol='rbd' name='rbd/vm-disk1'>
    <host name='10.10.10.11' port='6789'/>
  </source>
  <auth username='libvirt'>
    <secret type='ceph' uuid='2a1b...'/>
  </auth>
  <target dev='vdb' bus='virtio'/>
</disk>
EOF
virsh attach-device ubuntu-test disk.xml --persistent

Schritt 7: Im Gast verifizieren

In der VM erscheint das neue Gerät als /dev/vdb. Formatieren und einhängen:

lsblk
sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /mnt/ceph
sudo mount /dev/vdb /mnt/ceph
df -h /mnt/ceph

Fehlerbehebung und Stolperfallen

• „failed to connect to the RADOS monitor“ — der Hypervisor erreicht die Monitor-IP/-Port nicht, oder /etc/ceph/ceph.conf fehlt.
• Authentifizierungsfehler — der base64-Schlüssel im libvirt-Secret passt nicht zu client.libvirt, oder die Secret-UUID in der XML ist falsch.
• „feature set mismatch“ — das RBD-Image aktiviert Features, die Kernel/QEMU des Clients nicht unterstützen; neu anlegen mit nur --image-feature layering.
• Festplatte im Gast nicht sichtbar — Sie haben ohne --persistent angehängt und neu gestartet, oder der Bus-Typ wird nicht unterstützt; verwenden Sie virtio.

Wie es weitergeht

Sie haben nun Hypervisor und Storage-Cluster verbunden — das Fundament jeder Private Cloud. Dieselben RBD-Pools unterlegen transparent auch OpenStack-Cinder-Volumes, und Sie verwalten diese Festplatten im Alltag mit den zuvor behandelten virsh-Befehlen.

Fazit

KVM-VMs mit Ceph RBD zu unterlegen bringt Replikation, Live-Migration und Speicher, der jede einzelne Platte oder jeden Host überlebt — ohne ein proprietäres SAN zu kaufen. Dieses Muster aus Compute plus Storage ist genau die Art, wie clouditiv jede Instanz mit ausfallsicherem Speicher unterlegt. Ceph, libvirt, Secrets und Netzwerk selbst zusammenzubauen und zu betreiben ist echte Arbeit; wenn Sie lieber einfach ausfallsichere VMs starten möchten: clouditiv betreibt eine souveräne, ISO-27001-/BSI-C5-konforme Private Cloud auf Ubuntu 24.04 + OpenStack 2025.2 mit Ceph-gestütztem Speicher und Ihren Daten in Deutschland. Sehen Sie sich unsere On-Premise-Cloud-Lösung an.