Skip to content

cilium/little-vm-helper-images

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

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.

Use

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.

Build and start a VM using Makefile

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

Build and start a VM with lvh

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

Configuration files

LVH configuration (under _data)

  • 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.

Dockerfiles

GH actions

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

How can I ensure that new rootfs images are build?

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.

Can I only create builds for specific kernels?

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.

Can I completely disable builds for a PR?

Yes, you can use the gha-builds/justdont label.

How does the arm64 builds works?

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
Loading

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.