This release has been tracked through the v24.0 project. virtio-iommu specification describes how a device can be attached by default to a bypass domain. This feature is particularly helpful for booting a VM with guest software which doesn't support virtio-iommu but still need to access the device. Now that Cloud Hypervisor supports this feature, it can boot a VM with Rust Hypervisor Firmware or OVMF even if the virtio-block device exposing the disk image is placed behind a virtual IOMMU. Multiple checks have been added to the code to prevent devices with identical identifiers from being created, and therefore avoid unexpected behaviors at boot or whenever a device was hot plugged into the VM. Sparse mmap support has been added to both VFIO and vfio-user devices. This allows the device regions that are not fully mappable to be partially mapped. And the more a device region can be mapped into the guest address space, the fewer VM exits will be generated when this device is accessed. This directly impacts the performance related to this device. A new serial_number option has been added to --platform, allowing a user to set a specific serial number for the platform. This number is exposed to the guest through the SMBIOS. * Fix loading RAW firmware (#4072) * Reject compressed QCOW images (#4055) * Reject virtio-mem resize if device is not activated (#4003) * Fix potential mmap leaks from VFIO/vfio-user MMIO regions (#4069) * Fix algorithm finding HOB memory resources (#3983) * Refactor interrupt handling (#4083) * Load kernel asynchronously (#4022) * Only create ACPI memory manager DSDT when resizable (#4013) Deprecated features will be removed in a subsequent release and users should plan to use alternatives * The mergeable option from the virtio-pmem support has been deprecated (#3968) * The dax option from the virtio-fs support has been deprecated (#3889) Fixes: #4317 Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com> |
||
---|---|---|
.github/workflows | ||
ci | ||
docs | ||
snap | ||
src | ||
tools | ||
utils | ||
.gitignore | ||
CODE_OF_CONDUCT.md | ||
CODEOWNERS | ||
CONTRIBUTING.md | ||
Glossary.md | ||
LICENSE | ||
Makefile | ||
README.md | ||
utils.mk | ||
VERSION | ||
versions.yaml |

Kata Containers
Welcome to Kata Containers!
This repository is the home of the Kata Containers code for the 2.0 and newer releases.
If you want to learn about Kata Containers, visit the main Kata Containers website.
Introduction
Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.
License
The code is licensed under the Apache 2.0 license. See the license file for further details.
Platform support
Kata Containers currently runs on 64-bit systems supporting the following technologies:
Architecture | Virtualization technology |
---|---|
x86_64 , amd64 |
Intel VT-x, AMD SVM |
aarch64 ("arm64 ") |
ARM Hyp |
ppc64le |
IBM Power |
s390x |
IBM Z & LinuxONE SIE |
Hardware requirements
The Kata Containers runtime provides a command to determine if your host system is capable of running and creating a Kata Container:
$ kata-runtime check
Notes:
This command runs a number of checks including connecting to the network to determine if a newer release of Kata Containers is available on GitHub. If you do not wish this to check to run, add the
--no-network-checks
option.By default, only a brief success / failure message is printed. If more details are needed, the
--verbose
flag can be used to display the list of all the checks performed.If the command is run as the
root
user additional checks are run (including checking if another incompatible hypervisor is running). When running asroot
, network checks are automatically disabled.
Getting started
See the installation documentation.
Documentation
See the official documentation including:
Configuration
Kata Containers uses a single configuration file which contains a number of sections for various parts of the Kata Containers system including the runtime, the agent and the hypervisor.
Hypervisors
See the hypervisors document and the Hypervisor specific configuration details.
Community
To learn more about the project, its community and governance, see the community repository. This is the first place to go if you wish to contribute to the project.
Getting help
See the community section for ways to contact us.
Raising issues
Please raise an issue in this repository.
Note: If you are reporting a security issue, please follow the vulnerability reporting process
Developers
See the developer guide.
Components
Main components
The table below lists the core parts of the project:
Component | Type | Description |
---|---|---|
runtime | core | Main component run by a container manager and providing a containerd shimv2 runtime implementation. |
agent | core | Management process running inside the virtual machine / POD that sets up the container environment. |
documentation | documentation | Documentation common to all components (such as design and install documentation). |
libraries | core | Library crates shared by multiple Kata Container components or published to crates.io |
tests | tests | Excludes unit tests which live with the main code. |
Additional components
The table below lists the remaining parts of the project:
Component | Type | Description |
---|---|---|
packaging | infrastructure | Scripts and metadata for producing packaged binaries (components, hypervisors, kernel and rootfs). |
kernel | kernel | Linux kernel used by the hypervisor to boot the guest image. Patches are stored here. |
osbuilder | infrastructure | Tool to create "mini O/S" rootfs and initrd images and kernel for the hypervisor. |
agent-ctl |
utility | Tool that provides low-level access for testing the agent. |
trace-forwarder |
utility | Agent tracing helper. |
runk |
utility | Standard OCI container runtime based on the agent. |
ci |
CI | Continuous Integration configuration files and scripts. |
katacontainers.io |
Source for the katacontainers.io site. |
Packaging and releases
Kata Containers is now available natively for most distributions. However, packaging scripts and metadata are still used to generate snap and GitHub releases. See the components section for further details.
Glossary of Terms
See the glossary of terms related to Kata Containers.