New test runner by brenns10 · Pull Request #213 · oracle-samples/drgn-tools

brenns10 · 2026-06-01T16:36:09Z

Introduce a new test runner, testing.vm, which will replace both the testing.litevm and testing.heavyvm runners, while adding more features and being overall... better.

The new test runner has the following benefits:

It runs tests in an Oracle Linux rootfs. This means the tests run in a real OL userspace and can use the official drgn RPMs in our tests. (Compared to the old "litevm" runner, which ran in the host's rootfs.)
The rootfs is built with dnf --installroot in a container, which is much faster than scripting the ISO installer, and easier to update than the prebuilt cloud VM images.
Since the rootfs is manually built and part of the host filesystem, we can install just what we need, keeping the size small. And since we can share the rootfs for each test associated test kernel, we have less duplication. My rootfs directory is less than 2 GiB for all three combined.
Since the rootfs is not contained in an image, it's easy to run maintainence commands (e.g. installing new packages, compiling kernel modules) in a chroot rather than spinning up a full VM.
As a direct consequence, we can now build and insert a kernel module for our VM tests.
The runner now supports testing against Red Hat kernels (RHCK) -- including with the test kernel module.
Tests run on Oracle Linux host with only standard RPMs - just be sure to use the latest KVM utils stream.
Tests boot and run much faster! My laptop can run both DWARF + CTF test for OL8/UEK6 in around 15 seconds -- and this requires booting twice.

Some other notes:

This is a large amount of addition without many changes or deletions. The idea is to add this new framework in parallel to the others. I'll remove the others (testing.litevm, testing.heavyvm) once this is stable on Github CI.
I have some follow-ups that I will tackle later based on priority:
- Make it possible to run tests against specific Python versions in each rootfs. (OL8: python 3.6, 3.12, OL9: 3.9,
  3.12, 3.14 soon, OL10: 3.12, 3.14 soon).
- Enable running vmcore tests in the chroot for each OL version. This ensures that vmcore tests also use the real bits from our RPMs.
- Make it easy to drop-in new drgn/drgn-tools RPMs to test them (replacing my ad-hoc testing workflow for testing new RPM releases).
- Expand support to aarch64 and add this to Gitlab.

There is a known failure on UEK-NEXT due to changes in the slab allocator. Imran is currently taking a look at it, but I don't think this should block merging this.

Oracle Linux uses /usr/libexec/qemu-kvm, test that first and fallback to the standard name of qemu. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>

The "litevm" runner runs an Oracle Linux kernel, but it does so in whatever host rootfs is available. This means that we are not running tests of the actual drgn RPM which Oracle Linux provides. It also means that if we want to create a test kmod (similar to drgn), it is very difficult to build it. The "heavyvm" runner runs an Oracle Linux kernel within a full Oracle Linux userspace disk image. This solves both problems, but since the disk image is very large and slow to interact with, it cannot really be used in Github Actions and it's cumbersome to use locally. What's more, sharing the code for testing & module builds is difficult, so in practice we don't actually get much benefit. Plus, rebuilding the image is a maintenance chore. To simplify and sidestep these issues, a new "vm" runner will replace both. Tests will run within an Oracle Linux userspace chroot which we create by using the official podman images to run "dnf --installroot". The chroot contains necessary build dependencies for kernel modules as well as drgn and anything else the tests need. With this, the chroots can be created quickly enough to be useful in CI (say, a couple minutes). They are much smaller than the VM runners of heavyvm, with the flexibility of allowing bind mounts and kernel module builds. We also add a "hello world" kernel module which will become the test kmod over time. The test runner itself is stubbed out, we will add it next. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>