Skip to content

Enable block volume passthrough with filesystem for CSI #18818

Description

@greco-a

Please confirm

  • I have searched existing issues to check if an issue already exists for my feature request.

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:

  1. 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.
  2. The volume is still stored and treated as a content_type: block volume.
  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions