You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Ephemeral VMs use a small var partition size, without the means of increasing this #200
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.
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).
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.
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.
Activity
Jah-yee commentedon Mar 3, 2026
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
Issue 200, tmpfs
ntnn commentedon Mar 27, 2026
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-volumeflag; if it istmpfsmount a tmpfs volume, if it is an existing podman volume mount that (incl. letting it error if the volume does not exist) andcreateto create a podman volume and mount that (and delete if the container should be deleted).cgwalters commentedon Mar 27, 2026
Yeah, I think we could have
/varactually be a bind mount to e.g./var/tmp/guest-varin 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.ephemeral: Give /var its own tmpfs, add --var-size
cgwalters commentedon Oct 1, 2026
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:30GThis would:
O_TMPFILEon the host, attach it as a fd to qemu with a well known blockdev identifier (I think we do this for swap already)/run/repart.dthat 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 theroot- xref install: Use systemd-repart for partitioning bootc#2314 )/varOf 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.