How to test one RHEL 10 bootable container in three bcvk modes

Red Hat has published a compact workflow for testing RHEL 10 image-mode systems locally with the bootc container virtualization kit, or bcvk. The approach builds one OCI bootable-container image and then runs it as a disposable virtual machine, a persistent libvirt guest or a qcow2 disk artifact.

The walkthrough starts on a physical RHEL 10 host with an active subscription, Podman, access to a container registry and enough local storage for images. The bcvk package comes from EPEL. Persistent virtual machines additionally require a running libvirt daemon and permission to manage libvirt domains.

Build once

The example Containerfile inherits from registry.redhat.io/rhel10/rhel-bootc:latest, adds the containers.bootc=1 label, writes a custom message of the day and creates an administrator account. After registry login, Podman builds the image locally. bcvk images list then checks local metadata and displays images that carry the bootc label.

That label matters because bcvk expects a complete bootable operating-system image, not an ordinary application container. Red Hat notes that any existing bootc image can be used; the sample merely provides a reproducible starting point.

Choose the test mode

Ephemeral mode is the fast inner loop. bcvk ephemeral run-ssh starts the image as a temporary virtual machine and passes the host's SSH credentials. State disappears when the instance exits, making this suitable for smoke tests and repeated image iteration. Detached, named and automatic-cleanup options are available.

Libvirt mode creates a persistent virtual machine with bcvk libvirt run. Its disk and state survive reboots, and the guest can exercise bootc upgrades over time. bcvk also provides list, start, stop and SSH operations. The walkthrough says the first run is slower because it must create the disk image, but subsequent use retains the environment.

Disk mode converts the same container image into a deployable artifact. The example uses bcvk to-disk to create a 20GB qcow2 file. That output can feed virtual-machine, cloud or bare-metal deployment workflows rather than remaining tied to the local test instance.

Where it fits

The useful property is artifact continuity: the image checked on a laptop is the one promoted into persistent testing or converted for deployment. That reduces the gap between an OS build and the machine image that eventually boots.

The article is a getting-started path, not a production hardening guide. It does not cover automated credential injection, image signing, Secure Boot, registry availability, storage sizing or CI integration. Teams adopting the pattern should add those controls around the demonstrated build-and-test loop rather than treating the sample account and local image as production defaults.