Please confirm
Is your feature request related to a problem? Please describe.
Currently, LXD custom storage volumes with content_type: filesystem on block-backed storage pools (such as Ceph RBD, LVM, or ZFS with zfs.block_mode=true) support the optional block.filesystem (e.g., ext4, xfs) and block.mount_options configurations.
LXD automatically formats the underlying block device on the host before making it available. However, when attached to a Virtual Machine, these filesystem volumes must be shared via virtiofs, which introduces CPU overhead and latency under write-heavy workloads (e.g., databases).
To achieve bare-metal storage performance inside isolated VM nodes, the ideal approach I would like to use is to attach the volume to the VM as a raw block device (by creating it with content_type: block).
However, LXD currently explicitly disables and rejects block.filesystem for ContentType: "block" custom storage volumes during validation (returning Invalid option... block.filesystem).
As a consequence, in order to expose a block device with a custom native filesystem inside VMs, I am currently forced to handle the formatting inside the guest. This introduces unnecessary complexity and forces guest environments or external orchestrators (such as the CSI driver) to rely on disk partitioning and formatting utilities installed inside the guest operating system.
Describe the solution you'd like
I propose modifying LXD to support the optional block.filesystem setting for custom storage volumes of content_type: block on block-backed storage pools (Ceph, LVM, and ZFS in block mode).
When these properties are provided for a block-type custom volume:
- During volume creation, LXD maps the block device on the host and runs the filesystem creation tool (e.g., mkfs.ext4 or mkfs.xfs) with the desired options, just as it already does today for filesystem volumes.
- The volume is still stored and treated as a content_type: block volume.
- When attached to a VM, it is passed through as a raw block device (without virtiofs on the path), but appears inside the guest operating system pre-formatted and ready to be mounted.
I briefly discussed this feature in canonical/lxd-csi-driver#210.
Describe alternatives you've considered
No response
Additional context
No response
Please confirm
Is your feature request related to a problem? Please describe.
Currently, LXD custom storage volumes with
content_type: filesystemon block-backed storage pools (such as Ceph RBD, LVM, or ZFS withzfs.block_mode=true) support the optionalblock.filesystem(e.g., ext4, xfs) andblock.mount_optionsconfigurations.LXD automatically formats the underlying block device on the host before making it available. However, when attached to a Virtual Machine, these filesystem volumes must be shared via virtiofs, which introduces CPU overhead and latency under write-heavy workloads (e.g., databases).
To achieve bare-metal storage performance inside isolated VM nodes, the ideal approach I would like to use is to attach the volume to the VM as a raw block device (by creating it with
content_type: block).However, LXD currently explicitly disables and rejects
block.filesystemfor ContentType: "block" custom storage volumes during validation (returning Invalid option... block.filesystem).As a consequence, in order to expose a block device with a custom native filesystem inside VMs, I am currently forced to handle the formatting inside the guest. This introduces unnecessary complexity and forces guest environments or external orchestrators (such as the CSI driver) to rely on disk partitioning and formatting utilities installed inside the guest operating system.
Describe the solution you'd like
I propose modifying LXD to support the optional
block.filesystemsetting for custom storage volumes ofcontent_type: blockon block-backed storage pools (Ceph, LVM, and ZFS in block mode).When these properties are provided for a block-type custom volume:
I briefly discussed this feature in canonical/lxd-csi-driver#210.
Describe alternatives you've considered
No response
Additional context
No response