Skip to content

Ephemeral VMs use a small var partition size, without the means of increasing this #200

Open

Description

@yorickpeterse

I have a container and contains a Podman quadlet. This quadlet is configured with Pull=newer. The container doesn't embed the quadlet's image so I can keep my bootc/VM image small.

This seems to pose a problem for bcvk's ephemeral VMs however: per df -h the size of /var is only 780 MiB, but the container image I'm trying to pull for my quadlet is 2+ GiB, resulting in the pull failing due to insufficient disk space.

While bcvk libvirt related commands should allow you to work around that, those don't seem to work either. For example:

bcvk libvirt run --filesystem ext4 localhost/web:latest

This produces:

Creating libvirt domain 'web' (install source container image: localhost/web:latest)
 INFO Creating base disk: "/home/yorickpeterse/.local/share/libvirt/images/bootc-base-26e4d8fee5fcae63.qcow2"
Connected (4 seconds elapsed), beginning installation...
Setting up temporary filesystems...
rm: cannot remove '/var/lib/containers/storage/overlay': Device or resource busy
Error: 
   0: Failed to find or create base disk
   1: Failed to install bootc to base disk: "/home/yorickpeterse/.local/share/libvirt/images/bootc-base-26e4d8fee5fcae63.ecovti.tmp.qcow2"
   2: SSH installation command failed with exit code: Some(1)

Location:
   crates/kit/src/to_disk.rs:551

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

For comparison, building an image with bootc-image-builder and running it with qemu-system does work, though that's only because bootc-image-builder always forces a disk image size of 10 GiB, so it too would likely fail at some point given a sufficient amount of containers to pull in.

To resolve this, the default size of /var should probably be increased and an option for this should be exposed to the various ephemeral related commands, such that you could do something along the lines of bcvk ephemeral run-ssh web:latest --var-size=10G.

Activity

  1. Jah-yee commented on Mar 3, 2026

    @Jah-yee

    If you need to access localhost web interfaces via SSH tunnels, OpentheClaw can help - one-click to establish tunnel and open browser.

    https://github.com/Jah-yee/OpentheClaw

  2. added a commit that references this issue on Mar 24, 2026
  3. ntnn commented on Mar 27, 2026

    @ntnn

    I see two ways to mitigate this - one to mount a tmpfs on /var for the ephemeral container or to mount a podman volume there.
    While tmpfs would be easier it could be a problem for systems with little memory.
    Both options could be possible, e.g. by adding the --var-volume flag; if it is tmpfs mount a tmpfs volume, if it is an existing podman volume mount that (incl. letting it error if the volume does not exist) and create to create a podman volume and mount that (and delete if the container should be deleted).

  4. cgwalters commented on Mar 27, 2026

    @cgwalters
    Collaborator

    Yeah, I think we could have /var actually be a bind mount to e.g. /var/tmp/guest-var in the container image - and the default for podman (and docker IIRC) then is to back that with an overlayfs upper that just writes to the container host storage.

    So there's be no more RAM-based limits for /var. The tradeoff would be write heavy workloads always involving a guest-host transition.

  5. moved this to In Progress in Workstreamon Sep 23, 2026
  6. moved this from In Progress to Draft in Workstreamon Sep 23, 2026
  7. cgwalters commented on Oct 1, 2026

    @cgwalters
    Collaborator

    I was trying to do more with bcvk ephemeral (stateless kube) and ran into this myself.

    Here's another proposal:

    bcvk ephemeral run --var=size:30G

    This would:

    • Set up a sparse 30G O_TMPFILE on the host, attach it as a fd to qemu with a well known blockdev identifier (I think we do this for swap already)
    • Inject a systemd repart.d definition via credentials into /run/repart.d that initialized the blockdev using the same filesystem type that is a global bootc default (if present, otherwise we look for a repart.d definition for the root - xref install: Use systemd-repart for partitioning bootc#2314 )
    • Mount it as /var

    Of course that'd be very high level sugar for pieces which would make sense independently, it'd be convenient to have CLI sugar for repart.d in general - and probably just make it easier to inject generic external creds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions