tiCrypt and libvirt Storage Pools: Network Block Devices (iSCSI, Ceph RBD)
tiCrypt delegates VM storage to libvirt storage pools, but not every pool type can create volumes on demand. This article explains which pool types support dynamic provisioning and how encrypted data drives map onto network block-device backends like Ceph RBD and iSCSI.
At a glance
tiCrypt manages virtual machines through libvirt/KVM and delegates VM storage to libvirt storage pools. As a result, tiCrypt can use any pool type that libvirt can present as attachable volumes, including network and block-device pools such as Ceph RBD and iSCSI.
The important nuance behind that statement is that libvirt pool types are not equivalent in capability. Some pool types let libvirt create new volumes on demand; others can only consume volumes that already exist on the storage backend:
- Dynamic provisioning supported (libvirt can create the backing volume): directory (
dir), filesystem (fs), network filesystem (netfs), LVM (logical), Ceph RBD (rbd), GlusterFS (gluster), ZFS (zfs), Virtuozzo (vstorage), and physical disk (disk, as partitions). - Dynamic provisioning not supported (volumes must pre-exist on the backend): iSCSI (
iscsi), iSCSI-direct (iscsi-direct), SCSI host adapter (scsi), and multipath (mpath).
This is why Ceph RBD and iSCSI, though both "network block storage," behave very differently in practice: RBD images can be created and destroyed by libvirt directly, while iSCSI LUNs are defined on the storage target and libvirt can only attach to them.
Background: how tiCrypt uses storage pools
When a user creates an encrypted data drive, tiCrypt needs a backing storage volume to attach to the VM. That volume is sourced from a libvirt storage pool. The pool type determines only where the backing volume lives and how it is reached (a local file, an LVM logical volume, an RBD image over the network, an iSCSI LUN, etc.).
The pool type is independent of tiCrypt's drive encryption. tiCrypt does not rely on libvirt's encryption and support for different pool types. Instead, encryption is handled inside the VM using LUKS (Linux) or BitLocker (Windows) both for security (decryption key is not available to the infrastructure/admins) and independence of storage/pool technology. Selection of the pool or storage type can be made purely based on performance considerations.
Drive encryption is handled inside the secure VMs. Storage type is independent of encryption, and all storage types are compatible with tiCrypt encryption.
Supported libvirt pool types
The table below lists libvirt's storage pool backends. tiCrypt can in principle attach volumes from any of them. The right-hand column shows whether libvirt itself can create new volumes in that pool, which is the key factor that determines whether tiCrypt can provision drives dynamically.
| libvirt pool type | Backing storage | libvirt can create volumes? |
|---|---|---|
dir | Files in a local directory | Yes |
fs | A pre-formatted block device mounted as a filesystem | Yes |
netfs | A network filesystem (e.g., NFS, CIFS) | Yes |
logical | An LVM volume group | Yes (logical volumes) |
disk | A physical disk device | Yes (as partitions) |
rbd | Ceph RADOS Block Device images | Yes |
gluster | A GlusterFS volume | Yes |
zfs | A ZFS storage pool | Yes (zvols) |
vstorage | Virtuozzo Storage | Yes |
iscsi | LUNs on an iSCSI target | No (LUNs defined on the target) |
iscsi-direct | iSCSI via libiscsi (no host initiator) | No |
scsi | LUNs behind a SCSI host adapter (HBA) | No |
mpath | Multipath block devices | No |
If the libvirt storage pool does not support creation of volumes, tiCrypt cannot use the pool since it relies on libvirt to create new volumes as drives are created using the tiCrypt interface.
Ceph RBD specifically
libvirt has first-class RBD support. It can create, delete, resize, and snapshot RBD images directly in a Ceph pool. A VM disk backed by RBD is accessed over the network using QEMU's native RADOS/RBD driver and is not mapped as a local block device on the hypervisor host.
For tiCrypt, this means an encrypted data drive maps to a single RBD image. tiCrypt's encryption is applied to the contents of that image; Ceph stores only ciphertext and stripes it across OSDs according to the cluster's CRUSH/pool configuration. The striping is internal to Ceph; the drive consumer does not manage it.
Key deployment considerations for RBD:
- Authentication: libvirt needs Ceph
cephxcredentials, configured through a libvirt secret (the keyring is referenced by the pool/disk definition, not stored inline). - Cluster sizing: RBD performance and resilience are governed by the Ceph cluster (replication factor or erasure coding, OSD count, network), independent of tiCrypt.
iSCSI specifically
This is where the "any libvirt pool type" statement needs the most clarification.
The libvirt iscsi pool type discovers and exposes the LUNs that already exist on an iSCSI target. libvirt cannot create new LUNs on an iSCSI target. LUN creation is the storage array's responsibility. The same applies to iscsi-direct (which connects QEMU straight to the target via libiscsi, bypassing the host initiator). So you cannot dynamically provision a brand-new data drive directly on an iSCSI pool the way you can on RBD or LVM.
There are two established patterns for using iSCSI-backed storage with libvirt:
-
Pre-provisioned LUNs. Create LUNs on the iSCSI target ahead of time, then attach them. In this model each encrypted data drive corresponds to one LUN. This works but is operationally heavy if drives are created and destroyed frequently, because every drive requires you to provision a target-side LUN out of band. This setup cannot be used by tiCrypt.
-
LVM layered on iSCSI (recommended for dynamic provisioning). The hypervisor host logs into the iSCSI target; the LUN(s) appear as local block devices; you create an LVM volume group on top of them and define a libvirt
logicalpool over that VG. Because thelogicalpool does support volume creation, tiCrypt can then provision encrypted data drives as logical volumes carved from the VG on demand. Each encrypted drive maps to one logical volume, which the VG may concatenate or stripe across one or more underlying LUNs depending on how the VG is built.
In short: iSCSI works, but the dynamic-provisioning capability comes from layering LVM on top of the iSCSI LUNs, not from the iscsi pool type itself.
How encrypted data drives map onto block-device pools
The mapping depends on the pool type and the chosen pattern:
- Ceph RBD: one encrypted drive maps to one RBD image. The "LUN" concept does not directly apply; Ceph handles striping and replication internally across OSDs.
- iSCSI + LVM (
logicalpool): one encrypted drive maps to one logical volume, which may span one or more LUNs depending on the volume group layout.
Practical recommendations
- Want network block storage with on-demand drive provisioning? Ceph RBD is the most natural fit, because libvirt can create and manage RBD images directly. Plan for cephx secrets and appropriate Ceph cluster sizing.
- Standardized on an iSCSI SAN? Expect to layer LVM on top of the iSCSI LUN(s) and expose it as a libvirt
logicalpool to get dynamic provisioning; the bareiscsipool type alone cannot create new drives. - Validate before committing. Pool-type capabilities vary, so test the full create / attach / delete lifecycle of an encrypted data drive on your chosen pool type in a non-production environment first.