Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement VM support for OCI images #1360

Open
stgraber opened this issue Nov 7, 2024 · 1 comment
Open

Implement VM support for OCI images #1360

stgraber opened this issue Nov 7, 2024 · 1 comment
Labels
API Changes to the REST API Documentation Documentation needs updating Feature New feature, not a bug
Milestone

Comments

@stgraber
Copy link
Member

stgraber commented Nov 7, 2024

Currently OCI images can only be run as containers on top of Incus.
It would make sense to also allow them to run as lightweight virtual machines (--vm flag).

To do so, I expect we'll want to:

  • Publish a kernel + initrd combination on the image server (x86_64 and aarch64)
  • Have that initrd contain a small loader that will:
    • Mount the root filesystem over virtiofs
    • Re-shuffle the mount table and pivot_root
    • Mount the agent drive(s)
    • Spawn incus-agent
    • Exec into the container entry point ensuring it's attached to /dev/console
  • Have Incus treat all OCI images as both container and VM capable
  • For those images, rather than allocate a block volume, just stick with the single-volume as is normally done for containers
  • On startup, if dealing with OCI, ensure that we have a load kernel and initrd available for it, then bypass the firmware logic and use direct kernel booting to boot the image

This should give us a very lightweight VM which effectively acts almost identically to a traditional OCI container but can still handle all of our normal VM devices and config options.

@stgraber stgraber added Documentation Documentation needs updating Feature New feature, not a bug API Changes to the REST API labels Nov 7, 2024
@stgraber stgraber added this to the later milestone Nov 7, 2024
@chrisjsimpson
Copy link

+1

Publish a kernel + initrd combination on the image server (x86_64 and aarch64)

Yes, if I'm reading issue correctly a user with the following qemu experience:

qemu-system-x86_64 -enable-kvm -kernel bzImage -initrd rootfs.cpio.gz --append "console=ttyS0 init=/init -nographic

Woud be able to publish/upload their kernel and initrd (bzImage / rootfs.cpio.gz) and run.

For those images, rather than allocate a block volume, just stick with the single-volume as is normally done for containers

Consider having the option to have no volume at all (think of a busybox type scenario where all is in ram and a distro is never reaches pivot_root). imho most users would expect a volume by default- having the option of none is useful as less to tidy up if not needed.

A more complex use case might be how to translate networking expectations from a user -> incus e.g.

qemu-system-x86_64 -enable-kvm -kernelbzImage -initrd rootfs.cpio.gz --append "console=ttyS0 init=/init ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0::eth0:off" -nographic \
  -netdev tap,id=net0,ifname=tap0,script=no,downscript=no\
  -device e1000,netdev=net0

Fantastic live demo by the way!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Changes to the REST API Documentation Documentation needs updating Feature New feature, not a bug
Development

No branches or pull requests

2 participants