This repository contains little-vm-helper configuration files and dockerfiles for building kernel and rootfs images. The latter are stored in OCI images (https://quay.io/organization/lvh-images) so that they can be used in testing/development.
The easiest way to use this repository is via the Makefile, which performs the builds in docker
containers that include all the necessary dependnecies. make without arguments will print a list
of targets. Alternatively, lvh can be used directly,
which is faster but requres the necessary tools (e.g., guestfs-tools) to be installed in the host.
The Makefile targets will produce docker images that contain the generated root image(s). The commands below will generate the root images, extract the base image, and use it to boot a VM.
$ make images
...
=> => writing image sha257:96a86e6ebb38238569c007491c3e86a056340ceb9e4a3e66959bfa6a6ca8f8a0
=> => naming to quay.io/lvh-images/root-images
$ c=$(docker create sha256:96a86e6ebb38238569c007491c3e86a056340ceb9e4a3e66959bfa6a6ca8f8a0)
$ docker cp $c:/data/images/base.qcow2.zst /tmp
$ zstd --decompress /tmp/base.qcow2.zst
$ lvh run --host-mount $(pwd) --image /tmp/base.qcow2
The command below will directly buid the base image, and use it to boot a VM.
$ lvh images --dir _data build --image base.qcow2
$ lvh run --host-mount $(pwd) --image _data/images/base.qcow2
-
images.json is the configuration for building root images. There are two root images: base and kind. The former is intended for simple tests (e.g., tetragon unit tests) and the latter for kind-based tests.
-
kernels.json is the configuration for the various kernels.
- kernel-builder builds a container for building kernel images images
- kernel-images builds a container with the kernel images
- root-builder builds a container for building root images
- root-images builds a container with all the root images
- kind-images builds kernel-specific version of the kind image
- complexity-test-images builds kernel-specific versions of the complexity-test-image
This repository includes GH actions for automatically building and pushing images. Whenever a PR is opened, the buildx GH action will:
- generate a unique tag based on the day
- build the images
- push the images with the unqique tag
The action will not build the root images unless configuration files have changed.
There is a check-files input parameter that determines what files are checked to
determine if an image will be build. If you want to ensure that an image is build, you
can add a comment to the dockerfile of the image.
Yes, via gha-builds/kernel/XXX labes in PRs.
Kernel images and rootfs images that depend on kernels are treated differently. By default, they will always be build
because the kernels might have been updated. This can be controlled with adding gha-buidlds/kernel/XXX labels to the PRs.
These labels (if added) determine what kernels versions are build. For example, adding the gha-builds/kernel/bpf-next label,
results in images for the bpf-next version be build.
Yes, you can use the gha-builds/justdont label.
The build of LVH and the kernel can be done using cross-compilation which simplifies a lot the build of multi-arch images. Unfortunately, the part that build the images relies libguestfs that cannot work as of now for different target architectures than the host architecture. However switching to use only mmdebstrap, which can easily cross-build images, and get rid of libguestfs would solve this duality.
flowchart TD
subgraph "cross compilation"
A[kernel builder] --> B[kernel images]
E[little vm helper]
end
subgraph "native build"
C[root builder] --> D[root images]
B & D & E --> F[kind]
end
As of now, each steps to build an image (the left on the diagram above), for
example kind, are built on native runners and produce arch specific images
(with the -<arch> suffix in the tag), a multi-arch tag is then produced,
merging the architecture specific images, for the final result ease of use.