How to fix Error response from daemon: OCI runtime create failed: kata runtime error in Docker

DockerADVANCEDHIGHUpdated Dec 6, 2025· 216 views

This error occurs when Docker cannot start a container using the Kata Containers runtime, typically due to missing Kata components, incorrect configuration, or lack of hardware virtualization support.

Quick fix

Fixes Error response from daemon: OCI runtime create failed: kata runtime error

# Check if kata-runtime binary exists
which kata-runtime

# Verify kata-runtime version
kata-runtime --version

# Run Kata's built-in system compatibility check
kata-runtime kata-check
  1. Verify Kata Containers is properly installed
  2. Check hardware virtualization support
  3. Configure Docker daemon for Kata runtime
  4. Verify Kata components are complete
docker — error
# Check if kata-runtime binary exists
which kata-runtime
# Verify kata-runtime version
kata-runtime --version
# Run Kata's built-in system compatibility check
kata-runtime kata-check
Error response from daemon: OCI runtime create failed: kata runtime error

What this error means

The "OCI runtime create failed: kata runtime error" indicates that Docker attempted to create a container using Kata Containers as the OCI runtime but failed during the container creation process. Kata Containers is an open-source project that provides lightweight virtual machines to run containers with stronger isolation than traditional container runtimes like runc. Unlike standard container runtimes that share the host kernel, Kata Containers launches each container inside its own micro-VM with a dedicated kernel. This requires hardware virtualization support (Intel VT-x/AMD-V) and properly configured virtualization components. The error typically surfaces when the Kata runtime is specified but the system lacks the necessary prerequisites. Common scenarios include: the Kata runtime binaries are not installed or not found in the expected path, the Docker daemon configuration references Kata incorrectly, the host system doesn't support nested virtualization (when running inside a VM), or required Kata components like the hypervisor (QEMU/Firecracker) or guest kernel are missing.

Typical symptoms

  • Container fails to start when using --runtime=kata or --runtime=kata-runtime
  • Error message includes 'OCI runtime create failed' and mentions kata
  • Docker run or docker-compose up exits immediately with no container logs
  • Container works with default runtime (runc) but fails with Kata
  • Kubernetes pods stuck in ContainerCreating state when using Kata RuntimeClass
  • CI/CD pipelines fail when attempting to use Kata for enhanced isolation
  • Error messages referencing kata-runtime, kata-fc, or kata-qemu

Common causes

  1. Kata Containers runtime is not installed on the system
  2. Docker daemon.json has incorrect Kata runtime path configuration
  3. Hardware virtualization (VT-x/AMD-V) is not enabled in BIOS/UEFI
  4. Running inside a VM without nested virtualization support
  5. Required Kata components are missing (guest kernel, hypervisor, firmware)
  6. Containerd configuration doesn't include Kata runtime handlers
  7. SELinux or AppArmor blocking Kata runtime operations
  8. Kata runtime version incompatible with Docker/containerd version
  9. Incorrect containerd runtime shim path for Kata v2 API

How to fix "Error response from daemon: OCI runtime create failed: kata runtime error"

1Verify Kata Containers is properly installed

First, check if Kata Containers is installed and its components are present:

bash
# Check if kata-runtime binary exists
which kata-runtime

# Verify kata-runtime version
kata-runtime --version

# Run Kata's built-in system compatibility check
kata-runtime kata-check

If kata-runtime is not found, install Kata Containers:

On Ubuntu/Debian:

bash
# Add the Kata Containers repository
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.opensuse.org/repositories/home:/katacontainers:/releases:/x86_64:/master/xUbuntu_22.04/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kata-containers.gpg

echo "deb [signed-by=/etc/apt/keyrings/kata-containers.gpg] https://download.opensuse.org/repositories/home:/katacontainers:/releases:/x86_64:/master/xUbuntu_22.04/ /" | sudo tee /etc/apt/sources.list.d/kata-containers.list

sudo apt update
sudo apt install -y kata-runtime kata-containers-image

Using kata-manager (recommended):

bash
# Download and run kata-manager
bash -c "$(curl -fsSL https://raw.githubusercontent.com/kata-containers/kata-containers/main/utils/kata-manager.sh)"
2Check hardware virtualization support

Kata Containers requires hardware virtualization. Verify it's available and enabled:

bash
# Check for CPU virtualization support
cat /proc/cpuinfo | grep -E "(vmx|svm)"

# Run kata-check for comprehensive verification
sudo kata-runtime kata-check

Expected output should show either vmx (Intel VT-x) or svm (AMD-V).

If no output:

1. Reboot and enter BIOS/UEFI settings
2. Enable "Intel Virtualization Technology" or "AMD-V"
3. The setting location varies by manufacturer (usually under CPU, Advanced, or Security)

If running inside a VM, enable nested virtualization:

For VMware:
- Edit VM settings > Processors > Enable "Virtualize Intel VT-x/EPT"

For VirtualBox:
- Settings > System > Processor > Enable "Nested VT-x/AMD-V"

For KVM/QEMU host:

bash
# Enable nested virtualization on the host
sudo modprobe -r kvm_intel
sudo modprobe kvm_intel nested=1
3Configure Docker daemon for Kata runtime

Update the Docker daemon configuration to recognize Kata as an available runtime:

bash
# Edit Docker daemon configuration
sudo nano /etc/docker/daemon.json

Add or update the runtimes section:

json
{
  "runtimes": {
    "kata": {
      "path": "/usr/bin/kata-runtime"
    },
    "kata-qemu": {
      "path": "/usr/bin/containerd-shim-kata-qemu-v2"
    },
    "kata-fc": {
      "path": "/usr/bin/containerd-shim-kata-fc-v2"
    }
  }
}

Restart Docker to apply changes:

bash
sudo systemctl daemon-reload
sudo systemctl restart docker

Verify the runtime is available:

bash
docker info | grep -i runtime

Expected output should include kata in the list of runtimes.

4Verify Kata components are complete

Kata requires several components to function. Check they all exist:

bash
# Check for guest kernel
ls -la /usr/share/kata-containers/

# You should see files like:
# - vmlinuz.container (guest kernel)
# - kata-containers.img or kata-containers-initrd.img (root filesystem)
# - OVMF.fd or similar (UEFI firmware, if using UEFI boot)

If files are missing, reinstall Kata with all components:

bash
# Using kata-manager
kata-manager install-packages

# Or manually install missing packages (Ubuntu)
sudo apt install kata-runtime kata-containers-image kata-linux-container kata-proxy kata-shim

Check the hypervisor is available:

bash
# For QEMU
which qemu-system-x86_64

# For Firecracker
which firecracker
5Configure containerd for Kata (if using containerd)

If you're using containerd (directly or via Kubernetes), configure it for Kata:

bash
# Edit containerd config
sudo nano /etc/containerd/config.toml

Add the Kata runtime configuration:

toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
  runtime_type = "io.containerd.kata.v2"
  privileged_without_host_devices = true
  pod_annotations = ["io.katacontainers.*"]

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu]
  runtime_type = "io.containerd.kata-qemu.v2"
  privileged_without_host_devices = true

Restart containerd:

bash
sudo systemctl restart containerd

For Kubernetes, create a RuntimeClass:

yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata

Then reference it in your pod spec:

yaml
spec:
  runtimeClassName: kata
6Test Kata runtime functionality

Run a simple test container with Kata to verify it's working:

With Docker:

bash
docker run --rm --runtime=kata alpine uname -r

The kernel version should be different from your host kernel (indicating it's running in a Kata VM).

With containerd (ctr):

bash
sudo ctr image pull docker.io/library/alpine:latest
sudo ctr run --runtime "io.containerd.kata.v2" --rm -t docker.io/library/alpine:latest test-kata uname -r

With nerdctl:

bash
nerdctl run --runtime kata --rm alpine uname -r

If the test fails, check the logs for more details:

bash
# Docker daemon logs
sudo journalctl -u docker.service -n 100 --no-pager

# Containerd logs
sudo journalctl -u containerd.service -n 100 --no-pager
7Handle SELinux and AppArmor issues

Security modules can interfere with Kata operations. Check and adjust if necessary:

For SELinux (CentOS/RHEL/Fedora):

bash
# Check SELinux status
getenforce

# Check for Kata-related denials
sudo ausearch -m avc -ts recent | grep kata

# Temporarily set permissive (for testing only)
sudo setenforce 0

If this resolves the issue, create proper SELinux policies rather than leaving permissive.

For AppArmor (Ubuntu/Debian):

bash
# Check AppArmor status
sudo aa-status

# Check for Kata denials
sudo dmesg | grep -i apparmor | tail -20

# Test with AppArmor disabled for the container
docker run --security-opt apparmor=unconfined --runtime=kata alpine uname -r

Note: Running with security modules disabled is not recommended for production.

8Resolve version compatibility issues

Ensure your Kata version is compatible with Docker/containerd:

bash
# Check versions
kata-runtime --version
docker --version
containerd --version

Known compatibility issues:

- Kata 2.x with Docker < 20.10: May require specific shim paths
- Docker Engine 23.0: Has a known issue where exiting an exec session stops Kata containers
- Kata with older containerd: May need containerd 1.5+ for v2 runtime API

Update Kata to latest version:

bash
# Using kata-manager
kata-manager install-packages --force

# Or using package manager
sudo apt update && sudo apt upgrade kata-runtime

If using an older system, consider using Kata 1.x which has different requirements:

bash
# Check available versions
apt-cache madison kata-runtime

Advanced notes

### Understanding Kata Containers Architecture

Kata Containers provides VM-level isolation for containers. Each Kata container runs inside a lightweight virtual machine with its own kernel, providing:

- Strong isolation: Containers don't share the host kernel
- Security: Kernel vulnerabilities don't affect the host
- Compatibility: Standard container images work without modification

The architecture includes:
- kata-runtime: OCI-compliant runtime binary
- containerd-shim-kata-v2: Containerd runtime handler (Kata 2.x)
- Hypervisor: QEMU, Firecracker, or Cloud Hypervisor
- Guest kernel and initrd: Lightweight Linux kernel and root filesystem

### Firecracker vs QEMU

Kata supports multiple hypervisors:

QEMU (kata-qemu):
- Full-featured VM emulation
- Better compatibility with various workloads
- Supports more device types
- Higher memory overhead

Firecracker (kata-fc):
- Minimal microVM (built by AWS)
- Faster startup times (~125ms)
- Lower memory footprint
- Limited device support

bash
# Use Firecracker runtime
docker run --runtime=kata-fc alpine uname -r

# Use QEMU runtime
docker run --runtime=kata-qemu alpine uname -r

### Debugging Kata Issues

Enable debug logging:

bash
# Edit Kata configuration
sudo nano /etc/kata-containers/configuration.toml

# Set enable_debug = true in [hypervisor.qemu] section
[hypervisor.qemu]
enable_debug = true

Check Kata logs:

bash
sudo journalctl -t kata

View hypervisor process:

bash
ps aux | grep -E "(qemu|firecracker)"

### Resource Considerations

Kata containers have higher resource requirements than runc containers:

- Memory: Each VM needs minimum ~128MB (configurable)
- CPU: Hypervisor overhead per container
- Disk: Guest kernel and initrd (~50MB)

Configure resources in /etc/kata-containers/configuration.toml:

toml
[hypervisor.qemu]
default_memory = 2048  # MB
default_vcpus = 1

### Cloud Provider Support

When running on cloud VMs, nested virtualization support varies:

- AWS: Bare metal instances (*.metal) or specific instance types
- GCP: Enabled by default on most instances
- Azure: Requires specific VM sizes (Dv3, Ev3 series)
- DigitalOcean: Not supported on standard droplets

Check your cloud provider's documentation for nested virtualization support.

Frequently asked questions

What does "Error response from daemon: OCI runtime create failed: kata runtime er" mean?
The "OCI runtime create failed: kata runtime error" indicates that Docker attempted to create a container using Kata Containers as the OCI runtime but failed during the container creation process. Kata Containers is an open-source project that provides lightweight virtual machines to run containers with stronger isolation than traditional container runtimes like runc. Unlike standard container runtimes that share the host kernel, Kata Containers launches each container inside its own micro-VM with a dedicated kernel.
How do I fix "Error response from daemon: OCI runtime create failed: kata runtime er"?
This error occurs when Docker cannot start a container using the Kata Containers runtime, typically due to missing Kata components, incorrect configuration, or lack of hardware virtualization support.
What causes "Error response from daemon: OCI runtime create failed: kata runtime er"?
Kata Containers runtime is not installed on the system Docker daemon.json has incorrect Kata runtime path configuration Hardware virtualization (VT-x/AMD-V) is not enabled in BIOS/UEFI
Is the "Error response from daemon: OCI runtime create failed: kata runtime er" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading