Consider supporting bootc bootable containers #26
Labels
enhancement
New feature or request
Comments
|
Are you considering mounting the image via virtiofsd? |
|
I was thinking of actually building the disk image and booting that. This would just save the user from having to do that themselves, with the added bonus of not requiring privileges. |
|
If you can build the image without requiring privs? |
|
crun-vm could internally run bootc-image-builder in a minimal VM prior to running the user's actual VM. |
albertofaria
added a commit
that referenced
this issue
Apr 22, 2024
We attempt to detect if a container image is bootable. We can't easily retrieve the image's labels, so we instead look for files under /usr/lib/bootc/install. If there are none, it isn't a bootable container. If it is a bootable container but we're not running under Podman, we fail with an error. Once our container's entrypoint starts running, a background process on the host (outside the container) queries Podman for the image's name and ID, which the OCI runtime does not get but bootc-install needs. It then saves the container image as an OCI archive. It then runs the original container to generate the VM image. We do this using krun [1] so that elevated privileges aren't necessary. Our entrypoint blocks until this is done, and all subsequent logic remains the same. We could potentially avoid the OCI archive creation step by mounting the host's container storage into the container running under krun. This isn't trivial to achieve due to SELinux label and context mismatches between the host and the krun environment, so we leave this optimization for a future date. Closes #26. [1] https://github.com/containers/crun/blob/main/krun.1.md Signed-off-by: Alberto Faria <afaria@redhat.com>
albertofaria
added a commit
that referenced
this issue
Apr 22, 2024
We attempt to detect if a container image is bootable. We can't easily retrieve the image's labels, so we instead look for files under /usr/lib/bootc/install. If there are none, it isn't a bootable container. If it is a bootable container but we're not running under Podman, we fail with an error. Once our container's entrypoint starts running, a background process on the host (outside the container) queries Podman for the image's name and ID, which the OCI runtime does not get but bootc-install needs. It then saves the container image as an OCI archive. It then runs the original container to generate the VM image. We do this using krun [1] so that elevated privileges aren't necessary. Our entrypoint blocks until this is done, and all subsequent logic remains the same. We could potentially avoid the OCI archive creation step by mounting the host's container storage into the container running under krun. This isn't trivial to achieve due to SELinux label and context mismatches between the host and the krun environment, so we leave this optimization for a future date. Closes #26. [1] https://github.com/containers/crun/blob/main/krun.1.md Signed-off-by: Alberto Faria <afaria@redhat.com>
albertofaria
added a commit
that referenced
this issue
Apr 23, 2024
We attempt to detect if a container image is bootable. We can't easily retrieve the image's labels, so we instead look for files under /usr/lib/bootc/install. If there are none, it isn't a bootable container. If it is a bootable container but we're not running under Podman, we fail with an error. Once our container's entrypoint starts running, a background process on the host (outside the container) queries Podman for the image's name and ID, which the OCI runtime does not get but bootc-install needs. It then saves the container image as an OCI archive. It then runs the original container to generate the VM image. We do this using krun [1] so that elevated privileges aren't necessary. Our entrypoint blocks until this is done, and all subsequent logic remains the same. We could potentially avoid the OCI archive creation step by mounting the host's container storage into the container running under krun. This isn't trivial to achieve due to SELinux label and context mismatches between the host and the krun environment, so we leave this optimization for a future date. Closes #26. [1] https://github.com/containers/crun/blob/main/krun.1.md Signed-off-by: Alberto Faria <afaria@redhat.com>
albertofaria
added a commit
that referenced
this issue
Apr 28, 2024
We attempt to detect if a container image is bootable. We can't easily retrieve the image's labels, so we instead look for files under /usr/lib/bootc/install. If there are none, it isn't a bootable container. If it is a bootable container but we're not running under Podman, we fail with an error. Once our container's entrypoint starts running, a background process on the host (outside the container) queries Podman for the image's name and ID, which the OCI runtime does not get but bootc-install needs. It then saves the container image as an OCI archive. It then runs the original container to generate the VM image. We do this using krun [1] so that elevated privileges aren't necessary. Our entrypoint blocks until this is done, and all subsequent logic remains the same. We could potentially avoid the OCI archive creation step by mounting the host's container storage into the container running under krun. This isn't trivial to achieve due to SELinux label and context mismatches between the host and the krun environment, so we leave this optimization for a future date. Closes #26. [1] https://github.com/containers/crun/blob/main/krun.1.md Signed-off-by: Alberto Faria <afaria@redhat.com>
albertofaria
added a commit
that referenced
this issue
Apr 28, 2024
We attempt to detect if a container image is bootable. We can't easily retrieve the image's labels, so we instead look for files under /usr/lib/bootc/install. If there are none, it isn't a bootable container. If it is a bootable container but we're not running under Podman, we fail with an error. Once our container's entrypoint starts running, a background process on the host (outside the container) queries Podman for the image's name and ID, which the OCI runtime does not get but bootc-install needs. It then saves the container image as an OCI archive. It then runs the original container to generate the VM image. We do this using krun [1] so that elevated privileges aren't necessary. Our entrypoint blocks until this is done, and all subsequent logic remains the same. We could potentially avoid the OCI archive creation step by mounting the host's container storage into the container running under krun. This isn't trivial to achieve due to SELinux label and context mismatches between the host and the krun environment, so we leave this optimization for a future date. Closes #26. [1] https://github.com/containers/crun/blob/main/krun.1.md Signed-off-by: Alberto Faria <afaria@redhat.com>
albertofaria
added a commit
that referenced
this issue
May 1, 2024
We attempt to detect if a container image is bootable. We can't easily retrieve the image's labels, so we instead look for files under /usr/lib/bootc/install. If there are none, it isn't a bootable container. If it is a bootable container but we're not running under Podman, we fail with an error. Once our container's entrypoint starts running, a background process on the host (outside the container) queries Podman for the image's name and ID, which the OCI runtime does not get but bootc-install needs. It then saves the container image as an OCI archive. It then runs the original container to generate the VM image. We do this using krun [1] so that elevated privileges aren't necessary. Our entrypoint blocks until this is done, and all subsequent logic remains the same. We could potentially avoid the OCI archive creation step by mounting the host's container storage into the container running under krun. This isn't trivial to achieve due to SELinux label and context mismatches between the host and the krun environment, so we leave this optimization for a future date. Closes #26. [1] https://github.com/containers/crun/blob/main/krun.1.md Signed-off-by: Alberto Faria <afaria@redhat.com>
albertofaria
added a commit
that referenced
this issue
May 1, 2024
We attempt to detect if a container image is bootable. We can't easily retrieve the image's labels, so we instead look for files under /usr/lib/bootc/install. If there are none, it isn't a bootable container. If it is a bootable container but we're not running under Podman, we fail with an error. Once our container's entrypoint starts running, a background process on the host (outside the container) queries Podman for the image's name and ID, which the OCI runtime does not get but bootc-install needs. It then saves the container image as an OCI archive. It then runs the original container to generate the VM image. We do this using krun [1] so that elevated privileges aren't necessary. Our entrypoint blocks until this is done, and all subsequent logic remains the same. We could potentially avoid the OCI archive creation step by mounting the host's container storage into the container running under krun. This isn't trivial to achieve due to SELinux label and context mismatches between the host and the krun environment, so we leave this optimization for a future date. Closes #26. [1] https://github.com/containers/crun/blob/main/krun.1.md Signed-off-by: Alberto Faria <afaria@redhat.com>
albertofaria
added a commit
that referenced
this issue
May 8, 2024
We attempt to detect if a container image is bootable. We can't easily retrieve the image's labels, so we check if /usr/lib/bootc/install exists and is a directory. If so, it is a bootable container. If it is a bootable container but we're not running under Podman, we fail with an error. Once our container's entrypoint starts running, a background process on the host (outside the container) queries Podman for the image's name and ID, which the OCI runtime does not get but bootc-install needs. It then saves the container image as an OCI archive. It then runs the original container to generate the VM image. We do this using krun [1] so that elevated privileges aren't necessary. Our entrypoint blocks until this is done, and all subsequent logic remains the same. We could potentially avoid the OCI archive creation step by mounting the host's container storage into the container running under krun. This isn't trivial to achieve due to SELinux label and context mismatches between the host and the krun environment, so we leave this optimization for a future date. Closes #26. [1] https://github.com/containers/crun/blob/main/krun.1.md Signed-off-by: Alberto Faria <afaria@redhat.com>
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To run bootc bootable containers using crun-vm, users currently must first create a VM image from the container using something like bootc-image-builder, and then pass that image to crun-vm.
We could potentially allow users to pass the bootc container directly to crun-vm, which would internally convert it into an image and run a VM from it. This would simplify the workflow for users.
bootc-image-builder requires root privileges, but we would want this to work with rootless podman. A possible solution is running it an ephemeral VM before launching the actual VM requested by the user.
The text was updated successfully, but these errors were encountered: