@@ -621,16 +621,58 @@ Instances with local data volumes on that host.
621621Volume Encryption
622622^^^^^^^^^^^^^^^^^
623623
624- CloudStack supports LUKS-based volume encryption on KVM. Encrypted volumes are managed
625- through the :ref: `key-management-system `, where you can create and manage the encryption
626- keys used to protect your data.
627-
628- To create an encrypted volume, select a **KMS Key ** from the UI when creating the volume,
629- or supply the key ID via the API. The key must belong to the same zone as the volume.
624+ CloudStack supports LUKS-based volume encryption on KVM. Encryption is enabled through the
625+ storage offering: create a Disk Offering with encryption enabled (for data volumes) or a
626+ Compute Offering with root volume encryption enabled (for root disks), and deploy on a
627+ primary storage that supports encryption. Volumes deployed from such an offering are
628+ encrypted automatically with a per-volume passphrase. Encryption is performed on the KVM
629+ host, so the guest always sees a normal, decrypted disk and there is no encryption device
630+ to manage inside the Instance.
631+
632+ By default the per-volume passphrase is protected by a single key stored in the database.
633+ Optionally, the :ref: `key-management-system ` (KMS, introduced in 4.23) can instead wrap the
634+ passphrase with a key held in an external HSM/KMS provider, in which case you select a
635+ **KMS Key ** for the volume. KMS is not required for volume encryption.
630636
631637.. warning ::
632- Deleting the KMS key used to encrypt a volume will render that volume permanently
633- unrecoverable.
638+ If the key material protecting a volume's passphrase is lost — for example by deleting
639+ the KMS key used to wrap it — that volume becomes permanently unrecoverable.
640+
641+ Supported primary storage
642+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
643+
644+ * File-based storage (NFS, local, SharedMountPoint) and Dell PowerFlex/ScaleIO — encrypted
645+ with the qemu-native LUKS stack.
646+ * Ceph/RBD — encrypted with **native librbd LUKS2 **
647+ (``<encryption format='luks2' engine='librbd'> ``), for both data disks and root disks.
648+
649+ The two stacks are not interchangeable: a volume is always decrypted by the same engine
650+ that encrypted it, and they are never mixed on a single volume.
651+
652+ Ceph/RBD encryption
653+ ~~~~~~~~~~~~~~~~~~~
654+
655+ For Ceph/RBD, encryption is applied natively by librbd, which preserves Ceph's thin
656+ provisioning and copy-on-write cloning:
657+
658+ * **Data disks ** stay thin — only written blocks consume space (a 1 TB encrypted volume
659+ with 400 GB written uses roughly 400 GB).
660+ * **Root disks ** deployed from a template already on the same Ceph cluster are created as
661+ thin copy-on-write clones: each Instance stores only its own (encrypted) writes and
662+ shares the template blocks, so deploying many encrypted Instances from one template uses
663+ far less storage than a full per-Instance copy. When the template is not on the same
664+ cluster (for example on first use from secondary storage), the encrypted root is created
665+ as a full copy instead.
666+
667+ .. note ::
668+ Attaching an encrypted RBD volume to a **running ** Instance (hot-plug) requires
669+ **libvirt >= 10.1.0 ** on the KVM host. Older libvirt (for example 10.0.0 shipped with
670+ Ubuntu 24.04 LTS) has a bug that breaks hot-plug of encrypted block devices; on such a
671+ host the CloudStack agent refuses the attach with a clear error. Booting an Instance
672+ from an encrypted RBD root disk is **not ** affected and works on older libvirt.
673+
674+ Requirements on the KVM host: ``ceph-common `` (the ``rbd `` CLI) and a QEMU/librbd build
675+ that supports librbd LUKS2 encryption (Ceph Pacific / QEMU 6.1 and newer).
634676
635677
636678To Create a New Volume
0 commit comments