Container Image

FlexBlock can also run from its runtime container image. Because it drives a kernel block device, the container needs extra privileges and access to the host’s /dev, and the grant is mounted in read-only.

Running a command

docker run --rm --privileged --device /dev/ublk-control -v /dev:/dev \
  -v /etc/flexblock:/etc/flexblock:ro flexblock show /dev/nvme1n1p1

Option	Why
--privileged	FlexBlock drives a kernel block device, which needs privileges.
--device /dev/ublk-control	Gives the container the ublk control device.
-v /dev:/dev	Gives the container access to the host’s /dev, including the cache device.
-v /etc/flexblock:/etc/flexblock:ro	Mounts the grant read-only at its default path, /etc/flexblock/grant.json.

Everything after the image name is an ordinary flexblock command line.

This suits one-off commands (show, attach, detach, update, wipe, reap) as shown. The example passes no credentials, so pass them in for commands that reach object storage, for example -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY, or your provider’s environment variables or a mounted config file.

The host still needs the ublk_drv kernel module loaded (sudo modprobe ublk_drv) and the other host requirements, since the container shares the host’s kernel.

Running the daemon

For start, or for show against a daemon running on the host, also add these options:

Option	Why
-v /run/flexblock:/run/flexblock	Keeps runtime state on the host, including the page-state file a restarted daemon needs to recover unflushed writes. Without it, that state vanishes with a --rm container.
--pid host	Lets the daemon’s recorded PID match the host’s process table.

Prefer systemd for long-running service

For long-running service on a host, Running Under systemd is simpler to reason about than a privileged container. The rest of these docs assume the binary is installed directly.

Related

• Install
• Requirements
• Running Under systemd