Provide support for running kvm-introvirt in Github Actions via nested virtualization paving the way for future CI tests.

[LethalServant]

Implemented CI improvements to build the kvm-introvirt kernel module, and then install it in vagrant boxes for ci tests in IntroVirt lib repo.

• Vagrant Files:
  • ivkvm - runs a focal ubuntu virtual box to build the kvm-introvirt deb package and uploads it to the github action
  • ivkvmhost - builds a focal ubuntu virtual box that has kvm-introvirt installed, then it is packaged as a vagrant box, and uploaded to the github action.
  • ivkvmhostci - builds a virtual box based of ivkvmhost with extra packages installed, vagrant libvirt plugin, libvirtd, etc, then it is packaged as a vagrant box, and uploaded to the github action. this box is intended to be used to test the IntroVirt lib.

These vagrant boxes were uploaded out of band to my vagrant cloud

The current changes for this are located in my fork at branch ubuntu/focal/Ubuntu-5.4.0-135.152.
This was branched ubuntu/focal/Ubuntu-5.4.0-99.112, but should not be merged back into that branch through a Pull Request with the current branch kernel naming schema.

I think the best way to merge the changes is for the IntroVirt:kvm-introvirt repo to make a main branch off of ubuntu/focal/Ubuntu-5.4.0-99.112 to begin the directory kernel naming schema (instead of branch naming). These changes could be added with a pull request to the new main branch, and then adapted to the new kernel naming schema.

@chp-io does this sound right?

[chp-io]

This issue is specific to providing support for running kvm-introvirt in Github Actions, which will be needed for running integration tests in the future. I have renamed the title to reflect this.

Since kvm-introvirt is a hypervisor which will run in a Github Action runner (which is VM), we need to leverage a runner that supports nested virtualization. Only MacOS Github hosted runners currently support this feature, which is why you've chosen the macos12 runner. Using VirtualBox and Vagrant to automate the creation of the nested VM, is fine. However, we won't need to run vagrant in the nested VM (where the kvm-introvirt module runs), unlike for the libintrovirt integration tests, as we don't need full fledge VMs that run Windows or Linux, since kvm-introvirt has no understanding of the OS, that's libintrovirt's responsibility.

The kvm-introvirt integration tests will focus on exercising code that our kvm patch introduced. e.g. KVM ioctl handlers, vmexit handlers, etc. We will also need to make sure that we don't introduce any regressions. A separate issue will be created to discuss the actual kvm-introvirt integration tests. For now, we'll just run the kvm-unit-tests, which runs QEMU internally.

The kvm-introvirt integration tests will need to be able to run on bare metal and in a nested VM. We will re-use the bare-metal environment for the nested VM case:

• Bare Metal:
  • L0 hypevisor: kvm-introvirt kernel module + QEMU/kvm-unit-tests
• Github Action's MacOS VM:
  • L0 hypervisor: VirtualBox + Vagrant
  • L1 hypervisor: kvm-introvirt kernel module + QEMU/kvm-unit-tests