mirror of
https://github.com/kata-containers/kata-containers.git
synced 2026-07-07 19:06:16 +00:00
Align the composable VM images proposal with the naming convention used throughout the implementation: the generic mechanism and its data model are now "guest extension image" (config key `guest_extension_images`, struct `GuestExtensionImage`), and the runtime artifacts use the matching "extension" vocabulary (`/run/kata-extensions/<name>`, `kata.extension.<name>.verity_params`, `kata-extension-mount@.service`, the `extension-<name>` virtio-blk serial / dm-verity target, and the `kata-containers-coco-extension.img` image). It also documents how template-unit instances are enabled: a systemd generator instantiates kata-extension-mount@<name>.service for each extension on the kernel command line, so the rootfs build stays extension-agnostic. This replaces the earlier mixed "extra_images"/"addon" terminology and addresses the naming-consistency review feedback on the series. Assisted-by: Cursor <cursoragent@cursor.com> Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Design
Kata Containers design documents:
- Kata Containers architecture
- API Design of Kata Containers
- Design requirements for Kata Containers
- VSocks
- VCPU handling(in runtime-go)
- VCPU handling(in runtime-rs)
- VCPU threads pinning
- Host cgroups
- Agent systemd cgroup
InotifysupportHookssupport- Metrics(Kata 2.0)
- Metrics in Rust Runtime(runtime-rs)
- Design for Kata Containers
Lazyloadability withnydus - Design for direct-assigned volume
- Design for core-scheduling
- Virtualization Reference Architecture