GithubHelp home page GithubHelp logo

kata-containers / kata-containers Goto Github PK

View Code? Open in Web Editor NEW
4.9K 104.0 980.0 66.45 MB

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. https://katacontainers.io/

License: Apache License 2.0

Shell 8.92% Makefile 0.95% Rust 56.38% Go 26.14% Dockerfile 0.35% C 0.03% Logos 6.47% Open Policy Agent 0.36% R 0.39% Smarty 0.01%
kvm virtualization containers kubernetes k8s virtual-machine qemu firecracker acrn oci

kata-containers's Introduction

CI | Publish Kata Containers payload Kata Containers Nightly CI

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 as root, 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.
runtime-rs core The Rust version runtime.
agent core Management process running inside the virtual machine / POD that sets up the container environment.
dragonball core An optional built-in VMM brings out-of-the-box Kata Containers experience with optimizations on container workloads
documentation documentation Documentation common to all components (such as design and install documentation).
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.
kata-debug infrastructure Utility tool to gather Kata Containers debug information from Kubernetes clusters.
agent-ctl utility Tool that provides low-level access for testing the agent.
kata-ctl utility Tool that provides advanced commands and debug facilities.
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.
Webhook utility Example of a simple admission controller webhook to annotate pods with the Kata runtime class

Packaging and releases

Kata Containers is now available natively for most distributions.

General tests

See the tests documentation.

Metrics tests

See the metrics documentation.

Glossary of Terms

See the glossary of terms related to Kata Containers.

kata-containers's People

Contributors

amshinde avatar apokleos avatar bbolroc avatar bergwolf avatar chavafg avatar cmaf avatar danmihai1 avatar dborquez avatar dgibson avatar egernst avatar fidencio avatar gabyct avatar gkurz avatar jakob-naucke avatar jcvenegas avatar jiangliu avatar jodh-intel avatar jongwu avatar lifupan avatar likebreath avatar liubin avatar marcov avatar nitkon avatar pennyzct avatar studychao avatar teawater avatar tim-0731-hzt avatar tim-zhang avatar wainersm avatar weizhang555 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

kata-containers's Issues

kata-manager install-packages fails on Ubuntu 18.04.2

Description of problem

Fails due to broken dependencies.

Expected result

Installation of Kata components.

Actual result

$ bash -c "$(curl -fsSL https://raw.githubusercontent.com/kata-containers/tests/master/cmd/kata-manager/kata-manager.sh) install-packages"
Cloning into '/home/multipass/go/src/github.com/kata-containers/documentation'...
remote: Enumerating objects: 110, done.
remote: Counting objects: 100% (110/110), done.
remote: Compressing objects: 100% (59/59), done.
remote: Total 1431 (delta 54), reused 92 (delta 49), pack-reused 1321
Receiving objects: 100% (1431/1431), 1.82 MiB | 7.26 MiB/s, done.
Resolving deltas: 100% (818/818), done.
Cloning into '/home/multipass/go/src/github.com/kata-containers/tests'...
remote: Enumerating objects: 12, done.
remote: Counting objects: 100% (12/12), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 9575 (delta 3), reused 8 (delta 3), pack-reused 9563
Receiving objects: 100% (9575/9575), 6.53 MiB | 7.70 MiB/s, done.
Resolving deltas: 100% (5500/5500), done.
OK
Hit:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease                         
Hit:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease                                           
Ign:4 http://download.opensuse.org/repositories/home:/katacontainers:/releases:/x86_64:/master/xUbuntu_18.04  InRelease
Hit:5 http://archive.ubuntu.com/ubuntu bionic-backports InRelease        
Get:6 http://download.opensuse.org/repositories/home:/katacontainers:/releases:/x86_64:/master/xUbuntu_18.04  Release [716 B]
Get:7 http://download.opensuse.org/repositories/home:/katacontainers:/releases:/x86_64:/master/xUbuntu_18.04  Release.gpg [481 B]
Get:8 http://download.opensuse.org/repositories/home:/katacontainers:/releases:/x86_64:/master/xUbuntu_18.04  Packages [2052 B]
Fetched 3249 B in 1s (4341 B/s)   
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 kata-runtime : Depends: kata-containers-image (= 1.7.0) but it is not going to be installed
                Depends: kata-linux-container (= 4.19.28.39) but it is not going to be installed
                Depends: kata-proxy (= 1.7.0) but 1.7.0-25 is to be installed
                Depends: kata-shim (= 1.7.0) but 1.7.0-23 is to be installed
                Depends: kata-ksm-throttler (= 1.7.0) but it is not going to be installed
                Depends: qemu-lite (= 2.11.0+git.87517afd72) but it is not going to be installed
                Depends: qemu-vanilla (= 2.11.2+git.0982a56a55) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Add kubernetes CRI Port-Forward support

In CRI spec, there is a Port-Forward method, which forwards a user request stream to a port of the container. (ref: the original CRI streaming design document)

The implementation of this API in runC is nsenter + socat in brief. For hyper runV, we once did this by exec a socat in the sandbox but not in any user containers. (as follows)

                         +-------------------------------------------+
                         | sandbox                                   |
                         |              +-----------+ +-----------+  |
                         |              | container | | container |  |
                         |              +-----+-----+ +-----------+  |
                         |                    ^                      |
          exec           |  +-------+         |                      |
stream +------------------> | socat +---------+                      |
                         |  +-------+                                |
                         +-------------------------------------------+

For kata containers, we have at least two options to implement this

Add a new agent API to support this behavior

The agent could just do the stream termination and forward traffic to the port of the sandbox network.

                         +-------------------------------------------+
                         | sandbox                                   |
                         |              +-----------+ +-----------+  |
                         |              | container | | container |  |
                         |              +-----+-----+ +-----------+  |
                         |                    ^                      |
          PortForward()  |  +-------+         |                      |
stream +------------------> | agent +---------+                      |
                         |  +-------+                                |
                         +-------------------------------------------+

Intercept the network traffic of the containers from outside of the sandbox

I think this may lead to different ways for different CNI implementations

Any ideas, guys?

Remove TravisCI

Tracking issue for the removal of TravisCI.

It's been useful, but as we found for Clear Containers, Travis is too limited in its abilities. The main issues being:

Remove the Travis config file from the following repos:

  • agent
  • ksm-throttler
  • osbuilder
  • proxy
  • qemu
  • runtime
  • shim
  • tests

Before removing Travis from a repo, ensure the following:

  • Ensure unit tests running and passing under Jenkins

    Known issue: Jenkins doesn't provide /dev/tty whereas Travis does.

  • Ensure code coverage being reported under Jenkins.

  • Ensure no other checks called from .travis.yml missing from Jenkins.

Add support for IBM Z

This issue tracks the Kata support for s390 architecture.

handling changes to the agent's gRPC protocol buffer protocol version

First things first: this issue is about the version of the Kata Containers defined agent protocol, not the version of protocol buffers (proto2, proto3, ...) used to define the agent protocol!


Overview

  • The agent protocol which underlies Kata is a gRPC protocol buffer based.
  • A protocol buffer protocol requires each message member or field to be numbered.
  • If the ordering of the message fields in a protocol buffer changes, all components that use the protocol nominally need to be updated to ensure they are all "speaking the same language".

Handling protocol changes

Protocol buffers do have some basic features to handle protocol changes:

Requirements

Since we have made lots of change and will no doubt wish to make changes at some point in the future, we need a documented approach for:

  • How to deal with protocol modifications.
  • How to test such changes.

Concrete example

Assume we are already creating Kata Containers packages (we're not yet)...

  • A new image package is created containing a new agent version which is using a new gRPC protocol version.
  • Unless packages for all system components are updated at the same time for this new gRPC protocol version (*), the system will not function correctly.

Implications

This implies:

  • We need some sort of "trigger" so that if any of the *.proto files in the directory below change in the master branch:

    ... that this somehow triggers a re-vendor of the agent code for the other system components.

  • We should start looking at the how best to handle protocol changes (see links above).


[*] - This also assumes we aren't using any of the protocol buffer features to handle protocol changes.

Improve unit test coverage for core components

Overview

We need to increase our unit test (UT) coverage for the main components.

Requirement

  • Increase UT coverage to 80% (minimum) for core components (excluding the throttler which is not well used afaik).

  • Ensure the percentages stay at or above this threshold.

    This isn't quite as simple as it sounds: although it would be easy to mandate that every code PR includes a full set of unit tests that isn't always realistic. Some unit test scenarios are difficult to engineer (either technically difficult or extremely time-consuming to investigate). Sometimes we get "drive-by PRs" without tests, etc.

Why?

Unfortunately, the current figures are not very good. They used to be a lot better, but the project has grown a lot and as a result the percentages have dropped.

Component UT coverage
runtime 58.6%
throttler 55.7%
agent 50.1%
proxy 40.0%
shim 38.4%

Tasks

Strategy

  • Phase 1: "tal"
    Investigate how much work adding new tests is going to be for each file / package / component.

  • Phase 2: "jfdi"

    Divide the work up and give individual issues to team members to work on.

Finally

The figures may be better for the runtime once we finish the slash'n'burn work on:

Landing rust-agent in kata-containers org

In the past months, we have open-sourced rust-agent (alipay/kata-rust-agent).

Thanks to all the contributors, especially for the inputs from @jodh-intel, it could work with other Kata components: The CI changes are on the way (kata-containers/tests#1966) and the os-builder related issues are mostly fixed.

I discussed with @egernst and we both think we may try to land it in Kata by this month, which means we could have it before the Summit in Nov. Therefore we should have the PR for landing it right now. However, we still need to decide the place to land it:

  • A new repo called rust-agent or similar
    • Pro: easy to do.
    • Cons: one more repo, we want to consolidate our repos.
  • Re-construct agent repo, and put both the Go and Rust agent in the repo
    • Pro: it's reasonable as they share the same protocol and same position in the architecture. In short, they are two variants of a same software.
    • Cons: needs work in agent repo, and we need further work on consolidating the repos after this move.
  • Put into the kata-containers/kata-containers repo.
    • Pro: it will be the first step of consolidating the repos.
    • Cons: we need to figure out the repo structure firstly. However, we have not had any detailed conclusions on how to do the consolidation.

Folks here, we need your inputs here. And I suggest we discussed this in the next AC meeting.

@kata-containers/architecture-committee

Adding OpenTracing support for Kata

All Kata Components use highly structured logging.

We now need to consider adding full tracing abilities using OpenTracing as we can leverage the existing tooling and capitalise on the log fields we've added.

I've only started to look at open tracing but it sounds like we're going to have to think very carefully about where we inject traces and spans to get the maximum benefit.

Handling of dependencies and forks

The problem (well, "a problem")

The CI system uses the xurls utility in the static-checks script to check all URLs for validity.

The xurls package is rather "special" in that it is available from two locations:

.. but the code itself imports from https://mvdan.cc. This caused us some confusion recently when suddently xurls broke:

However, the real issue was not the URL for this package, but the version of golang it now requires:

But even updating the golang version caused problems as Travis uses an old version of Ubuntu which provides a version of golang too old for the new xurls. For the docs repo, I had to pretend to Travis that the repo is a golang code repo to get a newer version of golang that worked with xurls:

We've just seen another repo which is failing as a result of using an old version of golang under Travis:

A solution

The correct fix going forward is to version xurls in https://github.com/kata-containers/runtime/blob/master/versions.yaml so that the tests repo can determine the correct version before running the CI. This is a well proven technique we've been using for a long time now.

More generally

Versioning the xurls package "should" work -- even with stable branches in the runtime repo -- but we need to be aware that unless we are very careful to do this, we're potentially going to complicate the code in https://github.com/kata-containers/tests as the master branches in all the repos move further away from what we have in our stable branches. The tests repo currently already has to handle testing the following branches:

  • master
  • stable-1.1
  • stable-1.2
  • stable-1.3

A question

As such, I'm wondering if we should consider forking the tests repo [1] so that the stable-1.x branch of that repo would be used to test the stable-1.x branch of all the other repos.

That would:

  • Mean that a single tests branch would only need to test that version of the code in the other repos.
  • Bring the tests repo into parity with the component repos (with respect to branches).
  • Serve to keep the tests repo branches as "clean" as possible (but would of course impose a maintenance burden on backporting fixes to the older stable-* branches).

The question is which is the more expensive maintenance burden:

  • Cost of maintaining an increasingly complex tests repo.
  • Cost of backporting fixes in the tests repos master branch to tests repo stable branches.

Related:


[1] - In my view, we should fork all repos, including the crucial documentatation repo:

Refactor Process struct

The Process struct contains duplicate information, in Process struct and in grpc oci Process struct, we need to remove duplicate information, use grpc oci Process struct to provide needed information in Process struct

basic docker run example hangs with kata-proxy messages in journalctl

Description of problem

Hello all, and thanks in advanced for any help you can give.

I can successfully run Docker containers using the kata-runtime after I install the kata-containers from the deb packages as described here, however I am attempting to build kata-container from source as described in the developer documentation on a clean installation of Ubuntu 17.10, and I cannot successfully launch a container. Instead after running the sudo docker run -ti --runtime kata-runtime busybox sh command the process hangs and does not respond to ctrl-c.

I initially thought that the problem was with my QEMU configuration because that is the one area of the instructions that I believe to be a bit vague. (Actually I don't believe the current developer documentation makes any mention of QEMU installation, whereas the older revsion mentioned that it is installed with clear-containers, however the clear-container version of QEMU did not work for me either).

In any case I tried several options to set up QEMU after using the go package manager to install the kata-* packages from source:

  1. Downloaded source from kata's fork of QEMU on branch qemu-lite-2.11.0, and built from source using the configurations generated from configure-hypervisor.sh qemu-lite (script found here) run at the base of the qemu repository. As a note, this required me to install a few additional packages which I can list if you would like.
  2. Installing qemu-lite and qemu-vanilla packages using apt-get from the kata-containers deb repo.

Note: building QEMU (and everything else) from source is necessary in the end as my end target is not Ubuntu or Fedora where you have packages available.

In each of these cases I modified the path variable in the /usr/share/defaults/kata-containers/configuration.toml file to point to the correct binary, and cleaned up the hanging container from the previous attempt with the following script:

#!/bin/bash                                                
set -ex                                                    

# Gather debug logs                                        
sudo -E ${GOPATH}/src/github.com/kata-containers/runtime/data/kata-collect-data.sh > ${HOME}/kata-crash-logs/$(date | tr " " "-")                                                                                                     

# Kill all qemu and kata processes                         
sudo kill -9 $(pgrep kata) || echo "no kata* processes"    
sudo kill -9 $(pgrep qemu) || echo "no qemu processes"     
sudo kill -9 $(pgrep docker) || echo "no docker processes" 
docker rm -f $(docker ps -aq) || echo "no active containers"                                                           

# Cleon directories                                   
sudo rm -rf /var/run/vc/sbs/*                              
sudo rm -rf /var/lib/vs/sbs/* # Not sure this exists at all                          
sudo rm -rf /var/lib/vc/sbs/*                              
sudo rm -rf /run/vc/sbs/* 

Expected result

I expected the busybox container to launch, instead of hanging.

Actual result

The terminal hangs indeterminately after running sudo docker run -ti --runtime kata-runtime busybox sh and does not respond to ctrl-c. Below is the kata-collect-data.sh for an attempt made using qemu built from source. If you would like I can supply the kata-collect-data.sh log for the other variants that I tried as well.


Meta details

Running kata-collect-data.sh version 0.2.0 (commit 32c734e10bd15fec15d0961902f07efaa9c6f633) at 2018-05-17.19:28:14.893055339-0400.


Runtime is /usr/local/bin/kata-runtime.

kata-env

Output of "/usr/local/bin/kata-runtime kata-env":

[Meta]
  Version = "1.0.12"

[Runtime]
  Debug = false
  [Runtime.Version]
    Semver = "0.2.0"
    Commit = "32c734e10bd15fec15d0961902f07efaa9c6f633"
    OCI = "1.0.1"
  [Runtime.Config]
    Path = "/usr/share/defaults/kata-containers/configuration.toml"

[Hypervisor]
  MachineType = "pc"
  Version = "QEMU emulator version 2.11.0 (v2.11.0-rc0-306-g6ba2bfbee9-dirty)\nCopyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers"
  Path = "/home/ygefen/kata-containers/qemu/build/x86_64-softmmu/qemu-system-x86_64"
  BlockDeviceDriver = "virtio-scsi"
  Msize9p = 8192
  Debug = false

[Image]
  Path = "/usr/share/kata-containers/kata-containers-2018-05-17-11:57:21.804007878-0400-d25a591"

[Kernel]
  Path = "/usr/share/kata-containers/kata-vmlinuz-4.14.22.container"
  Parameters = "agent.log=debug"

[Initrd]
  Path = ""

[Proxy]
  Type = "kataProxy"
  Version = "kata-proxy version 0.2.0-16414149f38f7099c9afd529ebfbac335a15194a"
  Path = "/usr/libexec/kata-containers/kata-proxy"
  Debug = true

[Shim]
  Type = "kataShim"
  Version = "kata-shim version 0.2.0-2457ccc107ac46d7105254c089b240523b1701c4"
  Path = "/usr/libexec/kata-containers/kata-shim"
  Debug = true

[Agent]
  Type = "kata"

[Host]
  Kernel = "4.13.0-41-generic"
  Architecture = "amd64"
  VMContainerCapable = true
  [Host.Distro]
    Name = "Ubuntu"
    Version = "17.10"
  [Host.CPU]
    Vendor = "GenuineIntel"
    Model = "Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz"

Runtime config files

Runtime default config files

/etc/kata-containers/configuration.toml
/usr/share/defaults/kata-containers/configuration.toml

Runtime config file contents

Config file /etc/kata-containers/configuration.toml not found
Output of "cat "/usr/share/defaults/kata-containers/configuration.toml"":

# Copyright (c) 2017-2018 Intel Corporation
#
# SPDX-License-Identifier: Apache-2.0
#

# XXX: WARNING: this file is auto-generated.
# XXX:
# XXX: Source file: "cli/config/configuration.toml.in"
# XXX: Project:
# XXX:   Name: Kata Containers
# XXX:   Type: kata

[hypervisor.qemu]
# path = "/usr/bin/qemu-vanilla-system-x86_64"
# path = "/usr/bin/qemu-lite-system-x86_64"
# path = "/home/ygefenkata-containers/kata-deploy/bin/qemu-system-x86_64"
path = "/home/ygefen/kata-containers/qemu/build/x86_64-softmmu/qemu-system-x86_64"
kernel = "/usr/share/kata-containers/vmlinuz.container"
# initrd = "/usr/share/kata-containers/kata-containers-initrd.img"
image = "/usr/share/kata-containers/kata-containers.img"
machine_type = "pc"

# Optional space-separated list of options to pass to the guest kernel.
# For example, use `kernel_params = "vsyscall=emulate"` if you are having
# trouble running pre-2.15 glibc.
#
# WARNING: - any parameter specified here will take priority over the default
# parameter value of the same name used to start the virtual machine.
# Do not set values here unless you understand the impact of doing so as you
# may stop the virtual machine from booting.
# To see the list of default parameters, enable hypervisor debug, create a
# container and look for 'default-kernel-parameters' log entries.
kernel_params = " agent.log=debug"

# Path to the firmware.
# If you want that qemu uses the default firmware leave this option empty
firmware = ""

# Machine accelerators
# comma-separated list of machine accelerators to pass to the hypervisor.
# For example, `machine_accelerators = "nosmm,nosmbus,nosata,nopit,static-prt,nofw"`
machine_accelerators=""

# Default number of vCPUs per SB/VM:
# unspecified or 0                --> will be set to 1
# < 0                             --> will be set to the actual number of physical cores
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores
default_vcpus = 1

# Default maximum number of vCPUs per SB/VM:
# unspecified or == 0             --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# WARNING: Depending of the architecture, the maximum number of vCPUs supported by KVM is used when
# the actual number of physical cores is greater than it.
# WARNING: Be aware that this value impacts the virtual machine's memory footprint and CPU
# the hotplug functionality. For example, `default_maxvcpus = 240` specifies that until 240 vCPUs
# can be added to a SB/VM, but the memory footprint will be big. Another example, with
# `default_maxvcpus = 8` the memory footprint will be small, but 8 will be the maximum number of
# vCPUs supported by the SB/VM. In general, we recommend that you do not edit this variable,
# unless you know what are you doing.
default_maxvcpus = 0

# Bridges can be used to hot plug devices.
# Limitations:
# * Currently only pci bridges are supported
# * Until 30 devices per bridge can be hot plugged.
# * Until 5 PCI bridges can be cold plugged per VM.
#   This limitation could be a bug in qemu or in the kernel
# Default number of bridges per SB/VM:
# unspecified or 0   --> will be set to 1
# > 1 <= 5           --> will be set to the specified number
# > 5                --> will be set to 5
default_bridges = 1

# Default memory size in MiB for SB/VM.
# If unspecified then it will be set 2048 MiB.
#default_memory = 2048

# Disable block device from being used for a container's rootfs.
# In case of a storage driver like devicemapper where a container's 
# root file system is backed by a block device, the block device is passed
# directly to the hypervisor for performance reasons. 
# This flag prevents the block device from being passed to the hypervisor, 
# 9pfs is used instead to pass the rootfs.
disable_block_device_use = false

# Block storage driver to be used for the hypervisor in case the container
# rootfs is backed by a block device. This is either virtio-scsi or 
# virtio-blk.
block_device_driver = "virtio-scsi"

# Enable iothreads (data-plane) to be used. This causes IO to be
# handled in a separate IO thread. This is currently only implemented
# for SCSI.
#
enable_iothreads = false

# Enable pre allocation of VM RAM, default false
# Enabling this will result in lower container density
# as all of the memory will be allocated and locked
# This is useful when you want to reserve all the memory
# upfront or in the cases where you want memory latencies
# to be very predictable
# Default false
#enable_mem_prealloc = true

# Enable huge pages for VM RAM, default false
# Enabling this will result in the VM memory
# being allocated using huge pages.
# This is useful when you want to use vhost-user network
# stacks within the container. This will automatically 
# result in memory pre allocation
#enable_hugepages = true

# Enable swap of vm memory. Default false.
# The behaviour is undefined if mem_prealloc is also set to true
#enable_swap = true

# This option changes the default hypervisor and kernel parameters
# to enable debug output where available. This extra output is added
# to the proxy logs, but only when proxy debug is also enabled.
# 
# Default false
enable_debug = true

# Disable the customizations done in the runtime when it detects
# that it is running on top a VMM. This will result in the runtime
# behaving as it would when running on bare metal.
# 
#disable_nesting_checks = true

# This is the msize used for 9p shares. It is the number of bytes 
# used for 9p packet payload.
#msize_9p = 8192

[proxy.kata]
path = "/usr/libexec/kata-containers/kata-proxy"

# If enabled, proxy messages will be sent to the system log
# (default: disabled)
enable_debug = true

[shim.kata]
path = "/usr/libexec/kata-containers/kata-shim"

# If enabled, shim messages will be sent to the system log
# (default: disabled)
enable_debug = true

[agent.kata]
# There is no field for this section. The goal is only to be able to
# specify which type of agent the user wants to use.

[runtime]
# If enabled, the runtime will log additional debug messages to the
# system log
# (default: disabled)
enable_debug = true
#
# Internetworking model
# Determines how the VM should be connected to the
# the container network interface
# Options:
#
#   - bridged
#     Uses a linux bridge to interconnect the container interface to
#     the VM. Works for most cases except macvlan and ipvlan.
#
#   - macvtap
#     Used when the Container network interface can be bridged using
#     macvtap.
internetworking_model="macvtap"

Image details

---
osbuilder:
  url: "https://github.com/kata-containers/osbuilder"
  version: "unknown"
rootfs-creation-time: "2018-05-17T15:48:56."
description: "osbuilder rootfs"
file-format-version: "0.0.2"
architecture: "x86_64"
base-distro:
  name: "Alpine"
  version: "v3.7"
  packages:
    default:
      - "iptables"
    extra:

agent:
  url: "https://github.com/kata-containers/agent"
  name: "kata-agent"
  version: "0.2.0-60bcebf9f93bbf89e8e70a6eb1bd139a447fb73d"
  agent-is-init-daemon: "no"

Initrd details

No initrd


Logfiles

Runtime logs

Recent runtime problems found in system journal:

time="2018-05-17T16:59:30.175222884-04:00" level=warning msg="shortening QMP socket name" arch=amd64 name=kata-runtime new-name=mon-74e552b8-d8c6-40e1-8cd7-fa original-name=mon-74e552b8-d8c6-40e1-8cd7-fa68959a7390 pid=6480 source=virtcontainers subsystem=qemu
time="2018-05-17T16:59:30.175306638-04:00" level=warning msg="shortening QMP socket name" arch=amd64 name=kata-runtime new-name=ctl-74e552b8-d8c6-40e1-8cd7-fa original-name=ctl-74e552b8-d8c6-40e1-8cd7-fa68959a7390 pid=6480 source=virtcontainers subsystem=qemu
time="2018-05-17T16:59:30.175417355-04:00" level=debug msg="Could not retrieve anything from storage" arch=amd64 name=kata-runtime pid=6480 source=virtcontainers subsystem=kata_agent
time="2018-05-17T16:59:30.2962212-04:00" level=debug arch=amd64 default-kernel-parameters="tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 debug systemd.show_status=true systemd.log_level=debug" name=kata-runtime pid=6480 source=virtcontainers subsystem=qemu
time="2018-05-17T17:06:26.843334361-04:00" level=warning msg="shortening QMP socket name" arch=amd64 name=kata-runtime new-name=mon-3c15998e-dfbd-41ea-ac5d-52 original-name=mon-3c15998e-dfbd-41ea-ac5d-52aa8647596c pid=6883 source=virtcontainers subsystem=qemu
time="2018-05-17T17:06:26.843409691-04:00" level=warning msg="shortening QMP socket name" arch=amd64 name=kata-runtime new-name=ctl-3c15998e-dfbd-41ea-ac5d-52 original-name=ctl-3c15998e-dfbd-41ea-ac5d-52aa8647596c pid=6883 source=virtcontainers subsystem=qemu
time="2018-05-17T17:06:26.843515491-04:00" level=debug msg="Could not retrieve anything from storage" arch=amd64 name=kata-runtime pid=6883 source=virtcontainers subsystem=kata_agent
time="2018-05-17T17:06:26.966274221-04:00" level=debug arch=amd64 default-kernel-parameters="tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 debug systemd.show_status=true systemd.log_level=debug" name=kata-runtime pid=6883 source=virtcontainers subsystem=qemu
time="2018-05-17T17:11:44.699224851-04:00" level=warning msg="shortening QMP socket name" arch=amd64 name=kata-runtime new-name=mon-971ff00e-1130-428e-97d0-01 original-name=mon-971ff00e-1130-428e-97d0-01e804251ddf pid=8301 source=virtcontainers subsystem=qemu
time="2018-05-17T17:11:44.699288778-04:00" level=warning msg="shortening QMP socket name" arch=amd64 name=kata-runtime new-name=ctl-971ff00e-1130-428e-97d0-01 original-name=ctl-971ff00e-1130-428e-97d0-01e804251ddf pid=8301 source=virtcontainers subsystem=qemu
time="2018-05-17T17:11:44.699377764-04:00" level=debug msg="Could not retrieve anything from storage" arch=amd64 name=kata-runtime pid=8301 source=virtcontainers subsystem=kata_agent
time="2018-05-17T17:11:44.804825777-04:00" level=debug arch=amd64 default-kernel-parameters="tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 debug systemd.show_status=true systemd.log_level=debug" name=kata-runtime pid=8301 source=virtcontainers subsystem=qemu
time="2018-05-17T19:27:19.367186818-04:00" level=warning msg="shortening QMP socket name" arch=amd64 name=kata-runtime new-name=mon-8d553da2-64e4-47ee-8580-18 original-name=mon-8d553da2-64e4-47ee-8580-18e456fa15c9 pid=9194 source=virtcontainers subsystem=qemu
time="2018-05-17T19:27:19.367248264-04:00" level=warning msg="shortening QMP socket name" arch=amd64 name=kata-runtime new-name=ctl-8d553da2-64e4-47ee-8580-18 original-name=ctl-8d553da2-64e4-47ee-8580-18e456fa15c9 pid=9194 source=virtcontainers subsystem=qemu
time="2018-05-17T19:27:19.367335414-04:00" level=debug msg="Could not retrieve anything from storage" arch=amd64 name=kata-runtime pid=9194 source=virtcontainers subsystem=kata_agent
time="2018-05-17T19:27:19.484485573-04:00" level=debug arch=amd64 default-kernel-parameters="tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 debug systemd.show_status=true systemd.log_level=debug" name=kata-runtime pid=9194 source=virtcontainers subsystem=qemu
time="2018-05-17T19:28:01.13136504-04:00" level=warning msg="shortening QMP socket name" arch=amd64 name=kata-runtime new-name=mon-a842e579-a8ea-44c6-a791-c8 original-name=mon-a842e579-a8ea-44c6-a791-c8840371fdcf pid=9712 source=virtcontainers subsystem=qemu
time="2018-05-17T19:28:01.131437662-04:00" level=warning msg="shortening QMP socket name" arch=amd64 name=kata-runtime new-name=ctl-a842e579-a8ea-44c6-a791-c8 original-name=ctl-a842e579-a8ea-44c6-a791-c8840371fdcf pid=9712 source=virtcontainers subsystem=qemu
time="2018-05-17T19:28:01.131533486-04:00" level=debug msg="Could not retrieve anything from storage" arch=amd64 name=kata-runtime pid=9712 source=virtcontainers subsystem=kata_agent
time="2018-05-17T19:28:01.242400808-04:00" level=debug arch=amd64 default-kernel-parameters="tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 debug systemd.show_status=true systemd.log_level=debug" name=kata-runtime pid=9712 source=virtcontainers subsystem=qemu

Proxy logs

Recent proxy problems found in system journal:

time="2018-05-17T17:06:34.239081512-04:00" level=info msg="[    0.171766] EXT4-fs (pmem0p1): DAX enabled. Warning: EXPERIMENTAL, use at your own risk\n" name=kata-proxy pid=6933 source=agent
time="2018-05-17T17:06:34.239115612-04:00" level=info msg="[    0.172077] EXT4-fs (pmem0p1): mounted filesystem with ordered data mode. Opts: dax,data=ordered,errors=remount-ro\n" name=kata-proxy pid=6933 source=agent
time="2018-05-17T17:06:34.239191523-04:00" level=info msg="[    0.175629] Kernel panic - not syncing: Requested init /usr/lib/systemd/systemd failed (error -2).\n" name=kata-proxy pid=6933 source=agent

Shim logs

No recent shim problems found in system journal.


Container manager details

Have docker

Docker

Output of "docker version":

Client:
 Version:      18.03.1-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   9ee9f40
 Built:        Thu Apr 26 07:17:38 2018
 OS/Arch:      linux/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.5
  Git commit:   9ee9f40
  Built:        Thu Apr 26 07:15:45 2018
  OS/Arch:      linux/amd64
  Experimental: false

Output of "docker info":

Containers: 4
 Running: 0
 Paused: 0
 Stopped: 4
Images: 5
Server Version: 18.03.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: kata-runtime runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.13.0-41-generic
Operating System: Ubuntu 17.10
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.57GiB
Name: ygefen-ubox6
ID: CJPU:JL7O:WBHE:YPXX:XGK7:SQPX:HELC:43O4:RDQZ:QEGY:OXVQ:HFVZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 27
 Goroutines: 54
 System Time: 2018-05-17T19:28:15.201865596-04:00
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Output of "systemctl show docker":

Type=simple
Restart=on-failure
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=infinity
TimeoutStopUSec=1min 30s
RuntimeMaxUSec=infinity
WatchdogUSec=0
WatchdogTimestamp=Thu 2018-05-17 19:27:53 EDT
WatchdogTimestampMonotonic=18962999662
FailureAction=none
PermissionsStartOnly=no
RootDirectoryStartOnly=no
RemainAfterExit=no
GuessMainPID=yes
MainPID=9489
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
UID=4294967295
GID=4294967295
ExecMainStartTimestamp=Thu 2018-05-17 19:27:53 EDT
ExecMainStartTimestampMonotonic=18962999630
ExecMainExitTimestampMonotonic=0
ExecMainPID=9489
ExecMainCode=0
ExecMainStatus=0
ExecStart={ path=/usr/bin/dockerd ; argv[]=/usr/bin/dockerd -D --default-runtime runc --add-runtime kata-runtime=/usr/local/bin/kata-runtime ; ignore_errors=no ; start_time=[Thu 2018-05-17 19:27:53 EDT] ; stop_time=[n/a] ; pid=9489 ; code=(null) ; status=0/0 }
ExecReload={ path=/bin/kill ; argv[]=/bin/kill -s HUP $MAINPID ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
Slice=system.slice
ControlGroup=/system.slice/docker.service
MemoryCurrent=167862272
CPUUsageNSec=14978254354
TasksCurrent=78
Delegate=yes
CPUAccounting=no
CPUWeight=18446744073709551615
StartupCPUWeight=18446744073709551615
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=infinity
IOAccounting=no
IOWeight=18446744073709551615
StartupIOWeight=18446744073709551615
BlockIOAccounting=no
BlockIOWeight=18446744073709551615
StartupBlockIOWeight=18446744073709551615
MemoryAccounting=no
MemoryLow=0
MemoryHigh=18446744073709551615
MemoryMax=18446744073709551615
MemorySwapMax=18446744073709551615
MemoryLimit=18446744073709551615
DevicePolicy=auto
TasksAccounting=yes
TasksMax=18446744073709551615
UMask=0022
LimitCPU=18446744073709551615
LimitCPUSoft=18446744073709551615
LimitFSIZE=18446744073709551615
LimitFSIZESoft=18446744073709551615
LimitDATA=18446744073709551615
LimitDATASoft=18446744073709551615
LimitSTACK=18446744073709551615
LimitSTACKSoft=8388608
LimitCORE=18446744073709551615
LimitCORESoft=18446744073709551615
LimitRSS=18446744073709551615
LimitRSSSoft=18446744073709551615
LimitNOFILE=1048576
LimitNOFILESoft=1048576
LimitAS=18446744073709551615
LimitASSoft=18446744073709551615
LimitNPROC=18446744073709551615
LimitNPROCSoft=18446744073709551615
LimitMEMLOCK=65536
LimitMEMLOCKSoft=65536
LimitLOCKS=18446744073709551615
LimitLOCKSSoft=18446744073709551615
LimitSIGPENDING=63572
LimitSIGPENDINGSoft=63572
LimitMSGQUEUE=819200
LimitMSGQUEUESoft=819200
LimitNICE=0
LimitNICESoft=0
LimitRTPRIO=0
LimitRTPRIOSoft=0
LimitRTTIME=18446744073709551615
LimitRTTIMESoft=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOSchedulingClass=0
IOSchedulingPriority=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SyslogLevel=6
SyslogFacility=3
SecureBits=0
CapabilityBoundingSet=18446744073709551615
AmbientCapabilities=0
DynamicUser=no
RemoveIPC=no
MountFlags=0
PrivateTmp=no
PrivateDevices=no
ProtectKernelTunables=no
ProtectKernelModules=no
ProtectControlGroups=no
PrivateNetwork=no
PrivateUsers=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=no
UtmpMode=init
IgnoreSIGPIPE=yes
NoNewPrivileges=no
SystemCallErrorNumber=0
RuntimeDirectoryMode=0755
MemoryDenyWriteExecute=no
RestrictRealtime=no
RestrictNamespaces=no
MountAPIVFS=no
KillMode=process
KillSignal=15
SendSIGKILL=yes
SendSIGHUP=no
Id=docker.service
Names=docker.service
Requires=docker.socket system.slice sysinit.target
Wants=network-online.target
WantedBy=multi-user.target
ConsistsOf=docker.socket
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=basic.target system.slice systemd-journald.socket sysinit.target firewalld.service network-online.target docker.socket
TriggeredBy=docker.socket
Documentation=https://docs.docker.com
Description=Docker Application Container Engine
LoadState=loaded
ActiveState=active
SubState=running
FragmentPath=/lib/systemd/system/docker.service
DropInPaths=/etc/systemd/system/docker.service.d/kata-containers.conf
UnitFileState=enabled
UnitFilePreset=enabled
StateChangeTimestamp=Thu 2018-05-17 19:27:53 EDT
StateChangeTimestampMonotonic=18962999663
InactiveExitTimestamp=Thu 2018-05-17 19:27:53 EDT
InactiveExitTimestampMonotonic=18962999663
ActiveEnterTimestamp=Thu 2018-05-17 19:27:53 EDT
ActiveEnterTimestampMonotonic=18962999663
ActiveExitTimestamp=Thu 2018-05-17 19:27:52 EDT
ActiveExitTimestampMonotonic=18962673614
InactiveEnterTimestamp=Thu 2018-05-17 19:27:53 EDT
InactiveEnterTimestampMonotonic=18962993059
CanStart=yes
CanStop=yes
CanReload=yes
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnFailureJobMode=replace
IgnoreOnIsolate=no
NeedDaemonReload=no
JobTimeoutUSec=infinity
JobRunningTimeoutUSec=infinity
JobTimeoutAction=none
ConditionResult=yes
AssertResult=yes
ConditionTimestamp=Thu 2018-05-17 19:27:53 EDT
ConditionTimestampMonotonic=18962998851
AssertTimestamp=Thu 2018-05-17 19:27:53 EDT
AssertTimestampMonotonic=18962998851
Transient=no
Perpetual=no
StartLimitIntervalSec=60000000
StartLimitBurst=3
StartLimitAction=none
InvocationID=c7db5668f0f940f0a15248973082252b

No kubectl


Packages

Have dpkg
Output of "dpkg -l|egrep "(cc-oci-runtimecc-runtimerunv|kata-proxy|kata-runtime|kata-shim|kata-containers-image|linux-container|qemu-)"":

ii  qemu-lite                                  2.11.0+git.6ba2bfbee9-40                    amd64        linux kernel optimised for container-like workloads.
ii  qemu-vanilla                               2.11+git.e3050471ff-38                      amd64        linux kernel optimised for container-like workloads.

No rpm


A statement for the processor speculative execution related vulnerabilities

Based on the discussion of the previous meeting. We should have such a statement, including

  • The spectre and meltdown introduced a new class of side channel attack, as a result, there might be new similar attacks appear in the future months.
  • We have updated the kernel configuration to include kpti patch to improve the security of users workload.
  • Though kata containers with hypervisor have stronger isolation, we are seriously watching the progress and will take action if we found any potential exploit.

Clean up documentation and keep it cleaned

Ensure components can always consume on-disk state from previous versions

If component C at version X creates persistent on-disk state, that state must be consumable by component C at version X+1.

This guarantee is required to support a "live upgrade" scenario.

Approaches

We could either:

Version the on-disk state

  • Embed a version field into the start of each state file.
  • Versions would be semver :)

Pros:

  • ๐Ÿ‘ very quick to determine if state formats differ.

Cons:

  • ๐Ÿ‘Ž every new on-disk format change requires the component to understand all the previous versions potentially.
  • ๐Ÿ‘Ž spaghetti code:
    • ๐Ÿ‘Ž more fragile / less reliable.
    • ๐Ÿ‘Ž difficult to maintain and test.

Make the X+1 component version tolerant to missing elements

  • If a particular element from state file format version X+1 is not found in the on-disk state file, default that value to an X+1 state file format version value.

This is more like the autoconf approach where the tooling looks for host features rather than rigid feature versions.

Pros:

  • ๐Ÿ‘ simpler code.
  • ๐Ÿ‘ more reliable.

Cons:

  • ๐Ÿ‘Ž slower than just comparing version strings.

Thoughts

Atomicity

The state handling (serialising and deserialising) needs to be atomic to handle failure scenarios.

Dynamically loaded (and unloaded) state conversion?

If the state deserialisation code becomes big (maybe due to lots of different state versions), it might be worth investigating components dynamically loading a package to handle converting the on-disk state version X-n to the current state version X. Ideally, that package would be unloaded after successful conversion.

Testing

  • We'll need to create tests for every component which changes its on-disk state format version.
    • Each test will need to assert the component can consume state version X and state version X-1.
      • Store old state files in tests repo and arrange for tests to make component consume them.

Related

/cc @WeiZhang555.

Support "docker run --security-opt "

Description of problem

This Docker --security-opt option is not honoured.

Expected result

The seccomp profile passed inside the VM, should get honoured

Actual result

The seccomp profile passed gets dropped at the runtime itself and has no effect inside the container.

cat sleep.json
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"name": "nanosleep",
"action": "SCMP_ACT_ERRNO"
}
]
}

docker run -it --security-opt seccomp=sleep.json --runtime kata-runtime busybox sh
/ # sleep 6 ( Sleeps for 6 seconds)
/ #

Add static isolated tracing to agent

For parity with the golang agent tracing, we need to support the agent.trace agent kernel CLI option.

This may not be possible yet given the state of rust-lang bindings for the common tracing frameworks (openTracing, openCensus, openTelemetry). Need to investigate...

Kata 1.6.2 dependency chain broken

Description of problem

Kata 1.6.2 release page here: https://github.com/kata-containers/runtime/releases/tag/1.6.2

We are trying to consume the latest stable-1.6 release of kata but are hitting the dependency error below when attempting to install the package.

$ sudo apt install kata-runtime
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
kata-runtime : Depends: kata-linux-container (>= 4.19.34.33-4) but 4.19.28.31-3 is to be installed
E: Unable to correct problems, you have held broken packages.

http://download.opensuse.org/repositories/home:/katacontainers:/releases:/x86_64:/stable-1.6/xUbuntu_16.04/

https://imgur.com/aA8GOe2.jpg

Also the previous 1.6.1 release appears to have been removed, so we can't work around this without self-hosting a previous set of debs.

Expected result

Expecting package to be available due to new requirement from 1.6.2 kata-runtime:
kata-linux-container (>= 4.19.34.33-4)

As a backup, we were expecting the older 1.6.1 release to be available in the repo in case we need to roll back.

Actual result

Latest kata-linux-container package that's been published is 4.19.28.31-3.


Simplify agent API implement

Now, we have too many "match"es in API functions, we'd better refactor code to use one function to return Result, it will use ? for simplicity. And the just use one match in API function. It will make code more readable.

Fix doc review comments

#7 was merged inadvertently [*], so apply doc team review comments from #7.


[*] - as we don't have pullapprove enabled yet - see #9.

Consider creating an OBS instance for Kata packages

We currently use https://build.opensuse.org/project/show/home:katacontainers:release to build and host package binaries for Kata for various distro versions.

It's a good service but suffers from two awkward issues:

  • Reliability:

    • The free service is not always accessible (down for maintance, etc).
    • We sometimes see issues with repository metadata inconsistencies.
  • Security:

OBS is an OSS project so in theory we could create our own instance:

However, that would require hardware for all architectures and resource to manage it.

@annabellebertooch, @jimmytipit - is this something OSF could investigate for the Kata project?

@cboylan - OOI, does zuul offer any OBS-like functionality?

/cc @sameo, @jcvenegas.

Detect updated external versions

Problem

We have to poll lots of different sites to find out when external versions change. This is not efficient and we often don't notice when changes occur.

Background

We use a lot of external resources, some of which are encoded in the versions database in nice, machine-parseable and human-readable YAML:

Solution

We need a "check-versions" tool to detect when new versions of these resources change. The simplest approach would probably be to:

  • Add in the missing details to versions.yaml for:

    • The distro names and versions (and crucially URLs! :) for all the CI slaves we use.
    • Whatever else we've forgotten to add (take a look at the file and see what's missing :)
  • Write a golang tool to parse the YAML which can determine new versions of the resources specified in the versions database.

  • Run the tool periodically (atleast weekly) which will then send a mail / irc/slack ping when new versions are detected.

It should be possible for anyone to run the tool and see changes. The best location for it is probably below https://github.com/kata-containers/tests/tree/master/cmd.

Writing such a tool will no doubt require some changes to the format of versions.yaml (maybe to add in RSS feeds [is that still even "a thing"? :)] for things like new distro versions).

Minimum functionality

We absolutely must be informed automatically about new:

  • stable kernel versions (https://kernel.org)
  • stable qemu releases.
  • distro versions (new Ubuntu release, etc).
  • docker versions
  • k8s versions
  • golang versions

This is a new issue on the same problem described on kata-containers/ci#41. I've moved it here as it's a general problem (plus finding the issue just referenced always takes too long - I should have created it here :)

/cc @egernst, @bergwolf, @grahamwhaley, @chavafg.

Failed to check if grpc server is working: rpc error: code = DeadlineExceeded desc = context deadline exceeded

RPC Error

$ docker run --rm --runtime=kata-runtime hello-world

Expected result

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://cloud.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/

Actual result

docker: Error response from daemon: oci runtime error: Failed to check if grpc server is working: rpc error: code = DeadlineExceeded desc = context deadline exceeded.

Meta details

Running kata-collect-data.sh version 1.2.0 (commit 4220a7a9be8f37a3bb685bb7809239d5c84b20dd) at 2018-08-14.11:01:37.798942932+0800.


Runtime is /usr/local/bin/kata-runtime.

kata-env

Output of "/usr/local/bin/kata-runtime kata-env":

[Meta]
  Version = "1.0.13"

[Runtime]
  Debug = false
  [Runtime.Version]
    Semver = "1.2.0"
    Commit = "4220a7a9be8f37a3bb685bb7809239d5c84b20dd"
    OCI = "1.0.1"
  [Runtime.Config]
    Path = "/usr/share/defaults/kata-containers/configuration.toml"

[Hypervisor]
  MachineType = "pc"
  Version = "QEMU emulator version 2.11.0 (v2.11.0-rc0-308-ga39e0b3-dirty)\nCopyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers"
  Path = "/usr/bin/qemu-lite-system-x86_64"
  BlockDeviceDriver = "virtio-scsi"
  Msize9p = 8192
  Debug = false
  UseVSock = false

[Image]
  Path = "/usr/share/kata-containers/kata-containers-2018-08-13-15:43:09.394809477+0800-ae14163"

[Kernel]
  Path = "/usr/share/kata-containers/kata-vmlinuz-4.14.49.container"
  Parameters = ""

[Initrd]
  Path = ""

[Proxy]
  Type = "kataProxy"
  Version = "<<unknown>>"
  Path = "/usr/local/bin/kata-proxy"
  Debug = true

[Shim]
  Type = "kataShim"
  Version = "kata-shim version 1.2.0-0a37760c0224167143cb3cc920c78f5147f52e70"
  Path = "/usr/local/bin/kata-shim"
  Debug = true

[Agent]
  Type = "kata"

[Host]
  Kernel = "3.18.118+"
  Architecture = "amd64"
  VMContainerCapable = true
  [Host.Distro]
    Name = "Ubuntu"
    Version = "14.04"
  [Host.CPU]
    Vendor = "GenuineIntel"
    Model = "Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz"

Runtime config files

Runtime default config files

/etc/kata-containers/configuration.toml
/usr/share/defaults/kata-containers/configuration.toml

Runtime config file contents

Config file /etc/kata-containers/configuration.toml not found
Output of "cat "/usr/share/defaults/kata-containers/configuration.toml"":

# Copyright (c) 2017-2018 Intel Corporation
#
# SPDX-License-Identifier: Apache-2.0
#

# XXX: WARNING: this file is auto-generated.
# XXX:
# XXX: Source file: "cli/config/configuration.toml.in"
# XXX: Project:
# XXX:   Name: Kata Containers
# XXX:   Type: kata

[hypervisor.qemu]
path = "/usr/bin/qemu-lite-system-x86_64"
kernel = "/usr/share/kata-containers/vmlinuz.container"
#initrd = "/usr/share/kata-containers/kata-containers-initrd.img"
image = "/usr/share/kata-containers/kata-containers.img"
machine_type = "pc"

# Optional space-separated list of options to pass to the guest kernel.
# For example, use `kernel_params = "vsyscall=emulate"` if you are having
# trouble running pre-2.15 glibc.
#
# WARNING: - any parameter specified here will take priority over the default
# parameter value of the same name used to start the virtual machine.
# Do not set values here unless you understand the impact of doing so as you
# may stop the virtual machine from booting.
# To see the list of default parameters, enable hypervisor debug, create a
# container and look for 'default-kernel-parameters' log entries.
kernel_params = ""

# Path to the firmware.
# If you want that qemu uses the default firmware leave this option empty
firmware = ""

# Machine accelerators
# comma-separated list of machine accelerators to pass to the hypervisor.
# For example, `machine_accelerators = "nosmm,nosmbus,nosata,nopit,static-prt,nofw"`
machine_accelerators=""

# Default number of vCPUs per SB/VM:
# unspecified or 0                --> will be set to 1
# < 0                             --> will be set to the actual number of physical cores
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores
default_vcpus = 1

# Default maximum number of vCPUs per SB/VM:
# unspecified or == 0             --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# WARNING: Depending of the architecture, the maximum number of vCPUs supported by KVM is used when
# the actual number of physical cores is greater than it.
# WARNING: Be aware that this value impacts the virtual machine's memory footprint and CPU
# the hotplug functionality. For example, `default_maxvcpus = 240` specifies that until 240 vCPUs
# can be added to a SB/VM, but the memory footprint will be big. Another example, with
# `default_maxvcpus = 8` the memory footprint will be small, but 8 will be the maximum number of
# vCPUs supported by the SB/VM. In general, we recommend that you do not edit this variable,
# unless you know what are you doing.
default_maxvcpus = 0

# Bridges can be used to hot plug devices.
# Limitations:
# * Currently only pci bridges are supported
# * Until 30 devices per bridge can be hot plugged.
# * Until 5 PCI bridges can be cold plugged per VM.
#   This limitation could be a bug in qemu or in the kernel
# Default number of bridges per SB/VM:
# unspecified or 0   --> will be set to 1
# > 1 <= 5           --> will be set to the specified number
# > 5                --> will be set to 5
default_bridges = 1

# Default memory size in MiB for SB/VM.
# If unspecified then it will be set 2048 MiB.
#default_memory = 2048

# Disable block device from being used for a container's rootfs.
# In case of a storage driver like devicemapper where a container's 
# root file system is backed by a block device, the block device is passed
# directly to the hypervisor for performance reasons. 
# This flag prevents the block device from being passed to the hypervisor, 
# 9pfs is used instead to pass the rootfs.
disable_block_device_use = false

# Block storage driver to be used for the hypervisor in case the container
# rootfs is backed by a block device. This is either virtio-scsi or 
# virtio-blk.
block_device_driver = "virtio-scsi"

# Enable iothreads (data-plane) to be used. This causes IO to be
# handled in a separate IO thread. This is currently only implemented
# for SCSI.
#
enable_iothreads = false

# Enable pre allocation of VM RAM, default false
# Enabling this will result in lower container density
# as all of the memory will be allocated and locked
# This is useful when you want to reserve all the memory
# upfront or in the cases where you want memory latencies
# to be very predictable
# Default false
#enable_mem_prealloc = true

# Enable huge pages for VM RAM, default false
# Enabling this will result in the VM memory
# being allocated using huge pages.
# This is useful when you want to use vhost-user network
# stacks within the container. This will automatically 
# result in memory pre allocation
#enable_hugepages = true

# Enable swap of vm memory. Default false.
# The behaviour is undefined if mem_prealloc is also set to true
#enable_swap = true

# This option changes the default hypervisor and kernel parameters
# to enable debug output where available. This extra output is added
# to the proxy logs, but only when proxy debug is also enabled.
# 
# Default false
enable_debug = true

# Disable the customizations done in the runtime when it detects
# that it is running on top a VMM. This will result in the runtime
# behaving as it would when running on bare metal.
# 
#disable_nesting_checks = true

# This is the msize used for 9p shares. It is the number of bytes 
# used for 9p packet payload.
#msize_9p = 8192

# If true and vsocks are supported, use vsocks to communicate directly
# with the agent and no proxy is started, otherwise use unix
# sockets and start a proxy to communicate with the agent.
# Default false
#use_vsock = true

[factory]
# VM templating support. Once enabled, new VMs are created from template
# using vm cloning. They will share the same initial kernel, initramfs and
# agent memory by mapping it readonly. It helps speeding up new container
# creation and saves a lot of memory if there are many kata containers running
# on the same host.
#
# When disabled, new VMs are created from scratch.
#
# Default false
#enable_template = true

[proxy.kata]
#path = "/usr/libexec/kata-containers/kata-proxy"
path = "/usr/local/bin/kata-proxy"

# If enabled, proxy messages will be sent to the system log
# (default: disabled)
enable_debug = true

[shim.kata]
#path = "/usr/libexec/kata-containers/kata-shim"
path = "/usr/local/bin/kata-shim"

# If enabled, shim messages will be sent to the system log
# (default: disabled)
enable_debug = true

[agent.kata]
# There is no field for this section. The goal is only to be able to
# specify which type of agent the user wants to use.

[runtime]
# If enabled, the runtime will log additional debug messages to the
# system log
# (default: disabled)
enable_debug = true
#
# Internetworking model
# Determines how the VM should be connected to the
# the container network interface
# Options:
#
#   - bridged
#     Uses a linux bridge to interconnect the container interface to
#     the VM. Works for most cases except macvlan and ipvlan.
#
#   - macvtap
#     Used when the Container network interface can be bridged using
#     macvtap.
internetworking_model="macvtap"

Image details

---
osbuilder:
  url: "https://github.com/kata-containers/osbuilder"
  version: "unknown"
rootfs-creation-time: "2018-08-13T07:39:17.406715211+0000Z"
description: "osbuilder rootfs"
file-format-version: "0.0.2"
architecture: "x86_64"
base-distro:
  name: "Centos"
  version: "7"
  packages:
    default:
      - "iptables"
      - "systemd"
    extra:

agent:
  url: "https://github.com/kata-containers/agent"
  name: "kata-agent"
  version: "1.2.0-4c723f49d590813c311dcd0e2aab19616d757f19"
  agent-is-init-daemon: "no"

Initrd details

No initrd


Logfiles

Runtime logs

No recent runtime problems found in system journal.

Proxy logs

No recent proxy problems found in system journal.

Shim logs

No recent shim problems found in system journal.


Container manager details

Have docker

Docker

Output of "docker version":

Client:
 Version:      17.10.0-ce
 API version:  1.33
 Go version:   go1.8.3
 Git commit:   f4ffd25
 Built:        Tue Oct 17 19:04:40 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.10.0-ce
 API version:  1.33 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   f4ffd25
 Built:        Tue Oct 17 19:03:20 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of "docker info":

Containers: 4
 Running: 1
 Paused: 0
 Stopped: 3
Images: 76
Server Version: 17.10.0-ce
Storage Driver: aufs
 Root Dir: /home/persist/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 223
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: kata-runtime runc runsc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 0351df1c5a66838d0c392b4ac4cf9450de844e2d
init version: 949e6fa
Security Options:
 apparmor
Kernel Version: 3.18.118+
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.673GiB
Name: persist-pro
ID: VXSM:R2HZ:3MGJ:F2R2:BS5W:G27R:ITSI:6DTK:WWXW:J5JJ:BO2S:Y7QP
Docker Root Dir: /home/persist/var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: persist
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Registry Mirrors:
 http://f2d6cb40.m.daocloud.io/
Live Restore Enabled: false

Output of "systemctl show docker":

Id=docker.service
Names=docker.service
WantedBy=multi-user.target
Description=docker.service
LoadState=error
ActiveState=inactive
SubState=dead
InactiveExitTimestampMonotonic=0
ActiveEnterTimestampMonotonic=0
ActiveExitTimestampMonotonic=0
InactiveEnterTimestampMonotonic=0
CanStart=yes
CanStop=yes
CanReload=no
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnFailureIsolate=no
IgnoreOnIsolate=no
IgnoreOnSnapshot=no
NeedDaemonReload=no
JobTimeoutUSec=0
ConditionTimestampMonotonic=0
ConditionResult=no
LoadError=org.freedesktop.DBus.Error.FileNotFound "No such file or directory"
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutUSec=1min 30s
TimeoutStartUSec=1min 30s
TimeoutStopUSec=1min 30s
WatchdogUSec=0
WatchdogTimestampMonotonic=0
StartLimitInterval=10000000
StartLimitBurst=5
StartLimitAction=none
PermissionsStartOnly=no
RootDirectoryStartOnly=no
RemainAfterExit=no
GuessMainPID=yes
MainPID=0
ControlPID=0
Result=success
UMask=0022
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=65536
LimitAS=18446744073709551615
LimitNPROC=30823
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=30823
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=inherit
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSet=18446744073709551615
MountFlags=0
PrivateTmp=no
PrivateNetwork=no
SameProcessGroup=no
ControlGroupModify=no
ControlGroupPersistent=no
IgnoreSIGPIPE=yes
NoNewPrivileges=no
KillMode=control-group
KillSignal=15
SendSIGKILL=yes
ExecMainStartTimestampMonotonic=0
ExecMainExitTimestampMonotonic=0
ExecMainPID=0
ExecMainCode=0
ExecMainStatus=0

No kubectl


Packages

Have dpkg
Output of "dpkg -l|egrep "(cc-oci-runtimecc-runtimerunv|kata-proxy|kata-runtime|kata-shim|kata-containers-image|linux-container|qemu-)"":

ii  qemu-keymaps                                          2.0.0+dfsg-2ubuntu1.40                              all          QEMU keyboard maps
ii  qemu-system-common                                    2.0.0+dfsg-2ubuntu1.40                              amd64        QEMU full system emulation binaries (common files)
ii  qemu-system-x86                                       2.0.0+dfsg-2ubuntu1.40                              amd64        QEMU full system emulation binaries (x86)
ii  qemu-utils                                            2.0.0+dfsg-2ubuntu1.40                              amd64        QEMU utilities

No rpm


More

Your script doesn't work well in my host (because of some different software versions).

About journalctl:

time="2018-08-14T10:59:30.167405206+08:00" level=error msg="Failed to check if grpc server is working: rpc error: code = DeadlineExceeded desc = context deadline exceeded" arch=amd64 command=create container=3e446a6269c3cfa8e87a16b0aefea32611b0851eff19421d586f8423b794a57c name=kata-runtime pid=17812 source=runtime
time="2018-08-14T10:59:30.427703769+08:00" level=error msg="Container ID (3e446a6269c3cfa8e87a16b0aefea32611b0851eff19421d586f8423b794a57c) does not exist" arch=amd64 command=delete container=3e446a6269c3cfa8e87a16b0aefea32611b0851eff19421d586f8423b794a57c name=kata-runtime pid=17897 source=runtime
time="2018-08-14T10:59:30.452613108+08:00" level=error msg="Container ID (3e446a6269c3cfa8e87a16b0aefea32611b0851eff19421d586f8423b794a57c) does not exist" arch=amd64 command=delete container=3e446a6269c3cfa8e87a16b0aefea32611b0851eff19421d586f8423b794a57c name=kata-runtime pid=17903 source=runtime

Add structured logging to rust agent

Add structured logging (with slog) to the rust agent. This will mean all log calls will require a logger object (as they do in the go agent).

This will require some reworking to add loggers to objects. gRPC (atleast the health API) may require a global logger fwics though.

As structured logging is in somewhat of a state of flux in the rust community atm, we may end up switching to the log crate when it eventually fully handles structured logging. However, we neeed such logging now for parity with the existing agent.

Namespace osbuilder variables for improved reliability

The osbuilder tool can be run natively or under docker by setting a special variable. It also supports various other variables to allow the build to change behaviour. However, it's easy to add new variables and forget to update the internal docker call to pass those new variables to the docker container.

By renaming the public variables to use an OSBUILDER_ prefix, we namespace those variables and make exporting them to docker reliable. For further details see: kata-containers/osbuilder#274

Tasks

Adding a host device to the container fails

docker run with --device option fails with error: Could not create destination mount point.

From test hot plug block device from kata-containers/tests repository:

Running command '/usr/bin/docker [docker run --runtime kata-runtime --device /dev/loop0 --device /dev/loop1 --device /dev/loop2 --device /dev/loop3 --device /dev/loop4 --device /dev/loop5 --device /dev/loop6 --d
evice /dev/loop7 --device /dev/loop8 --device /dev/loop9 --rm --name xT5A8Vn1i8f7VXEkeXnZG3Fq7X367e busybox stat /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4 /dev/loop5 /dev/loop6 /dev/loop7 /dev/loop8
 /dev/loop9]'
command failed error 'exit status 125'
[docker run --runtime kata-runtime --device /dev/loop0 --device /dev/loop1 --device /dev/loop2 --device /dev/loop3 --device /dev/loop4 --device /dev/loop5 --device /dev/loop6 --device /dev/loop7 --device /dev/lo
op8 --device /dev/loop9 --rm --name xT5A8Vn1i8f7VXEkeXnZG3Fq7X367e busybox stat /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4 /dev/loop5 /dev/loop6 /dev/loop7 /dev/loop8 /dev/loop9]
Timeout: 60 seconds
Exit Code: 125
Stdout: 
Stderr: docker: Error response from daemon: OCI runtime create failed: rpc error: code = Unknown desc = Could not create destination mount point: /dev/loop0: could not stat source location:: unknown.

Logs from kata-runtime-cc:

Jan 30 16:24:59 kata-test kata-runtime-cc[33939]: time="2018-01-30T16:24:59Z" level=info msg="proxy started" pod-id=b0bd2dfff665bd37552082b7a1887800cb23bf9e40a78a71e6df0d2b44637357 proxy-pid=33980 source=virtcontainers subsystem=pod
Jan 30 16:24:59 kata-test kata-runtime-cc[33939]: time="2018-01-30T16:24:59Z" level=debug msg="Replacing OCI mount (/etc/resolv.conf) source /var/lib/docker/containers/b0bd2dfff665bd37552082b7a1887800cb23bf9e40a78a71e6df0d2b44637357/resolv.conf with /tmp/kata-containers/shared/pods/b0bd2dfff665bd37552082b7a1887800cb23bf9e40a78a71e6df0d2b44637357-990bac11a1797731-resolv.conf" source=virtcontainers subsystem=kata_agent
Jan 30 16:24:59 kata-test kata-runtime-cc[33939]: time="2018-01-30T16:24:59Z" level=debug msg="Replacing OCI mount (/etc/hostname) source /var/lib/docker/containers/b0bd2dfff665bd37552082b7a1887800cb23bf9e40a78a71e6df0d2b44637357/hostname with /tmp/kata-containers/shared/pods/b0bd2dfff665bd37552082b7a1887800cb23bf9e40a78a71e6df0d2b44637357-ceffb31d0a9c8399-hostname" source=virtcontainers subsystem=kata_agent
Jan 30 16:24:59 kata-test kata-runtime-cc[33939]: time="2018-01-30T16:24:59Z" level=debug msg="Replacing OCI mount (/etc/hosts) source /var/lib/docker/containers/b0bd2dfff665bd37552082b7a1887800cb23bf9e40a78a71e6df0d2b44637357/hosts with /tmp/kata-containers/shared/pods/b0bd2dfff665bd37552082b7a1887800cb23bf9e40a78a71e6df0d2b44637357-f6e4d323fc2c5752-hosts" source=virtcontainers subsystem=kata_agent
Jan 30 16:24:59 kata-test kata-runtime-cc[33939]: time="2018-01-30T16:24:59Z" level=error msg="rpc error: code = Unknown desc = Could not create destination mount point: /dev/loop0: could not stat source location: " source=runtime

Logs from kata-proxy:

Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="[\x1b[0;32m  OK  \x1b[0m] Listening on Process Core Dump Socket.\n" name=kata-proxy pid=33980
Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="         Starting Create Static Device Nodes in /dev...\n" name=kata-proxy pid=33980
Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="         Mounting Temporary Directory (/tmp)...\n" name=kata-proxy pid=33980
Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="[    0.599888] systemd-journald[119]: Fixed min_use=1.0M max_use=100.1M max_size=12.5M min_size=512.0K keep_free=150.2M n_
max_files=100\n" name=kata-proxy pid=33980
Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="[\x1b[0;32m  OK  \x1b[0m] Started Load/Save Random Seed.\n" name=kata-proxy pid=33980
Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="[\x1b[0;32m  OK  \x1b[0m] Started Apply Kernel Variables.\n" name=kata-proxy pid=33980
Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="[    0.601763] systemd-journald[119]: Reserving 22791 entries in hash table.\n" name=kata-proxy pid=33980
Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="[\x1b[0;1;31mFAILED\x1b[0m] Failed to mount Temporary Directory (/tmp).\n" name=kata-proxy pid=33980
Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="See 'systemctl status tmp.mount' for details.\n" name=kata-proxy pid=33980
Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="[    0.602748] systemd-journald[119]: Vacuuming...\n" name=kata-proxy pid=33980
Jan 30 16:24:59 kata-test kata-proxy[33980]: time="2018-01-30T16:24:59Z" level=info msg="[    0.603096] systemd-journald[119]: Vacuuming done, freed 0B of archived journals from /run/log/journal/4702f8088df7437f
9087690659b381b6.\n" name=kata-proxy pid=33980

switch vendoring from dep to go modules

The proof-of-concept runtime PR has raised a few issues for moving from dep to the new go mod vendoring facility.

This issue has been raised for tracking the migration path across the various repos.

Tasks

  • In the tests repo:
    • Update check_vendor() in .ci/static-checks.sh to deal with go.mod files.
    • Move all go get calls into a function (which will do nothing for go mod vendoring).
  • In the community repo:
  • Switch each code repository to:
    • add go mod vendoring.
    • Ensure all non-golang files below vendor/ are ignored as we do today with dep using the non-go=true [prune] option (see kata-containers/.github#4 (comment)).
    • remove dep vendoring.
    • Update .travis.yml to remove go_import_path where appropriate.
    • Repos to update:
      • agent
      • ksm-throttler
      • proxy
      • runtime
      • shim
      • tests

Timing

From https://github.com/golang/go/wiki/Modules:

Modules are an experimental opt-in feature in Go 1.11, with the plan of incorporating feedback and finalizing the feature for Go 1.13.

This makes me wonder if we want to update our infrastructure (mostly in tests) to support go mod alongside supporting dep, but not actually switch the code repos to using go mod until golang 1.13 is out.

Decide on golang version strategy

Minimum supported version of golang

Currently, https://github.com/kata-containers/documentation/wiki/Developer-Guide#assumptions states we support "golang version 1.8.3 or newer.".

Range of golang versions supported

We need to decide on a strategy for determining which versions of golang we support:

$ cd $GOPATH/src/github.com/kata-containers
$ cat */.travis.yml|grep -A 4 "go:"|sed 's/^ *//g'|egrep -- "- (1.[0-9]|tip)"|sort -u 
- 1.8
- 1.9
- tip

Consistency

What isn't clear from the uniq(1)'d list above is that different components are testing with a different range of golang versions.

Introduce Process

We should be fine to retain go1.8.3 as our minimum version, but we do need a process to decide:

  • how we decide the range of go versions we support.
  • how we move to a new version for CI/PnP.
  • how we remove old versions.

Something similar to:

How do we handle the "bleeding edge"?

There is also the issue of whether we test with golang "tip" or not, and if we do, whether that should block a PR (probably not):

Travis-specifics

The problem becomes easier to manage once we move away from Travis (see kata-containers/ci#4) as we can centralise the logic rather than having 'n' different .travis.yml files to manage...

Where to store range of golang versions

Note that ideally we would specify a list of supported golang versions in a file like a versions.txt database (see kata-containers/runtime#11).

That way, we can have a central list that everything else that needs to know this version range can consume, namely:

Consumers of golang versions list

Kata container pods do not get created in Kubernetes 1.14

Description of problem

I recently attended the Kata containers workshop at OpenInfra days presented by Graham Whaley where we successfully deployed them in a Minikube environment with K8s 1.14. After the workshop, I've been attempting to deploy it on a bare metal setup with multiple nodes.

I adapted [this guide][https://gist.github.com/grahamwhaley/aadebd12a9ee832ea3f81bef1eca4156] which I applied to K8s 1.14 deployed using Kubespray and Flannel as network plugin. I understand that it is no longer necessary to apply runtimeClass CRD as it is include in-tree.

Expected result

For pods to be deployed as kata containers.

Actual result

Pods are deployed as regular cri-o containers.


Meta details

Running kata-collect-data.sh version 1.6.1 (commit 8efc5718813224722f87ad119edcf9753fd6147d) at 2019-04-11.13:16:59.961891976+0000.


Runtime is /opt/kata/bin/kata-runtime.

kata-env

Output of "/opt/kata/bin/kata-runtime kata-env":

[Meta]
  Version = "1.0.20"

[Runtime]
  Debug = false
  Trace = false
  DisableGuestSeccomp = true
  DisableNewNetNs = false
  Path = "/opt/kata/bin/kata-runtime"
  [Runtime.Version]
    Semver = "1.6.1"
    Commit = "8efc5718813224722f87ad119edcf9753fd6147d"
    OCI = "1.0.1-dev"
  [Runtime.Config]
    Path = "/opt/kata/share/defaults/kata-containers/configuration-qemu.toml"

[Hypervisor]
  MachineType = "pc"
  Version = "QEMU emulator version 2.11.2(kata-static)\nCopyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers"
  Path = "/opt/kata/bin/qemu-system-x86_64"
  BlockDeviceDriver = "virtio-scsi"
  EntropySource = "/dev/urandom"
  Msize9p = 8192
  MemorySlots = 10
  Debug = false
  UseVSock = false

[Image]
  Path = "/opt/kata/share/kata-containers/kata-containers-image_clearlinux_1.6.1_agent_992b4987a32.img"

[Kernel]
  Path = "/opt/kata/share/kata-containers/vmlinuz-4.19.28-31"
  Parameters = "init=/usr/lib/systemd/systemd systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket systemd.mask=systemd-journald.service systemd.mask=systemd-journald.socket systemd.mask=systemd-journal-flush.service systemd.mask=systemd-udevd.service systemd.mask=systemd-udevd.socket systemd.mask=systemd-udev-trigger.service systemd.mask=systemd-timesyncd.service systemd.mask=systemd-update-utmp.service systemd.mask=systemd-tmpfiles-setup.service systemd.mask=systemd-tmpfiles-cleanup.service systemd.mask=systemd-tmpfiles-cleanup.timer systemd.mask=tmp.mount"

[Initrd]
  Path = ""

[Proxy]
  Type = "kataProxy"
  Version = "kata-proxy version 1.6.1-6a6651d737ce6bd418154f6215af2902bfa13441"
  Path = "/opt/kata/libexec/kata-containers/kata-proxy"
  Debug = false

[Shim]
  Type = "kataShim"
  Version = "kata-shim version 1.6.1-39896627000d0305490e26440880a68f766ce45c"
  Path = "/opt/kata/libexec/kata-containers/kata-shim"
  Debug = false

[Agent]
  Type = "kata"

[Host]
  Kernel = "3.10.0-862.14.4.el7.x86_64"
  Architecture = "amd64"
  VMContainerCapable = true
  SupportVSocks = false
  [Host.Distro]
    Name = "CentOS Linux"
    Version = "7"
  [Host.CPU]
    Vendor = "GenuineIntel"
    Model = "Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz"

[Netmon]
  Version = "kata-netmon version 1.6.1"
  Path = "/opt/kata/libexec/kata-containers/kata-netmon"
  Debug = false
  Enable = false

Runtime config files

Runtime default config files

/etc/kata-containers/configuration.toml
/opt/kata/share/defaults/kata-containers/configuration.toml

Runtime config file contents

Config file /etc/kata-containers/configuration.toml not found
Output of "cat "/opt/kata/share/defaults/kata-containers/configuration.toml"":

# Copyright (c) 2017-2019 Intel Corporation
#
# SPDX-License-Identifier: Apache-2.0
#

# XXX: WARNING: this file is auto-generated.
# XXX:
# XXX: Source file: "cli/config/configuration-qemu.toml.in"
# XXX: Project:
# XXX:   Name: Kata Containers
# XXX:   Type: kata

[hypervisor.qemu]
path = "/opt/kata/bin/qemu-system-x86_64"
kernel = "/opt/kata/share/kata-containers/vmlinuz.container"
image = "/opt/kata/share/kata-containers/kata-containers.img"
machine_type = "pc"

# Optional space-separated list of options to pass to the guest kernel.
# For example, use `kernel_params = "vsyscall=emulate"` if you are having
# trouble running pre-2.15 glibc.
#
# WARNING: - any parameter specified here will take priority over the default
# parameter value of the same name used to start the virtual machine.
# Do not set values here unless you understand the impact of doing so as you
# may stop the virtual machine from booting.
# To see the list of default parameters, enable hypervisor debug, create a
# container and look for 'default-kernel-parameters' log entries.
kernel_params = ""

# Path to the firmware.
# If you want that qemu uses the default firmware leave this option empty
firmware = ""

# Machine accelerators
# comma-separated list of machine accelerators to pass to the hypervisor.
# For example, `machine_accelerators = "nosmm,nosmbus,nosata,nopit,static-prt,nofw"`
machine_accelerators=""

# Default number of vCPUs per SB/VM:
# unspecified or 0                --> will be set to 1
# < 0                             --> will be set to the actual number of physical cores
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores
default_vcpus = 1

# Default maximum number of vCPUs per SB/VM:
# unspecified or == 0             --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# WARNING: Depending of the architecture, the maximum number of vCPUs supported by KVM is used when
# the actual number of physical cores is greater than it.
# WARNING: Be aware that this value impacts the virtual machine's memory footprint and CPU
# the hotplug functionality. For example, `default_maxvcpus = 240` specifies that until 240 vCPUs
# can be added to a SB/VM, but the memory footprint will be big. Another example, with
# `default_maxvcpus = 8` the memory footprint will be small, but 8 will be the maximum number of
# vCPUs supported by the SB/VM. In general, we recommend that you do not edit this variable,
# unless you know what are you doing.
default_maxvcpus = 0

# Bridges can be used to hot plug devices.
# Limitations:
# * Currently only pci bridges are supported
# * Until 30 devices per bridge can be hot plugged.
# * Until 5 PCI bridges can be cold plugged per VM.
#   This limitation could be a bug in qemu or in the kernel
# Default number of bridges per SB/VM:
# unspecified or 0   --> will be set to 1
# > 1 <= 5           --> will be set to the specified number
# > 5                --> will be set to 5
default_bridges = 1

# Default memory size in MiB for SB/VM.
# If unspecified then it will be set 2048 MiB.
default_memory = 2048
#
# Default memory slots per SB/VM.
# If unspecified then it will be set 10.
# This is will determine the times that memory will be hotadded to sandbox/VM.
#memory_slots = 10

# The size in MiB will be plused to max memory of hypervisor.
# It is the memory address space for the NVDIMM devie.
# If set block storage driver (block_device_driver) to "nvdimm",
# should set memory_offset to the size of block device.
# Default 0
#memory_offset = 0

# Disable block device from being used for a container's rootfs.
# In case of a storage driver like devicemapper where a container's 
# root file system is backed by a block device, the block device is passed
# directly to the hypervisor for performance reasons. 
# This flag prevents the block device from being passed to the hypervisor, 
# 9pfs is used instead to pass the rootfs.
disable_block_device_use = false

# Block storage driver to be used for the hypervisor in case the container
# rootfs is backed by a block device. This is virtio-scsi, virtio-blk
# or nvdimm.
block_device_driver = "virtio-scsi"

# Specifies cache-related options will be set to block devices or not.
# Default false
#block_device_cache_set = true

# Specifies cache-related options for block devices.
# Denotes whether use of O_DIRECT (bypass the host page cache) is enabled.
# Default false
#block_device_cache_direct = true

# Specifies cache-related options for block devices.
# Denotes whether flush requests for the device are ignored.
# Default false
#block_device_cache_noflush = true

# Enable iothreads (data-plane) to be used. This causes IO to be
# handled in a separate IO thread. This is currently only implemented
# for SCSI.
#
enable_iothreads = false

# Enable pre allocation of VM RAM, default false
# Enabling this will result in lower container density
# as all of the memory will be allocated and locked
# This is useful when you want to reserve all the memory
# upfront or in the cases where you want memory latencies
# to be very predictable
# Default false
#enable_mem_prealloc = true

# Enable huge pages for VM RAM, default false
# Enabling this will result in the VM memory
# being allocated using huge pages.
# This is useful when you want to use vhost-user network
# stacks within the container. This will automatically 
# result in memory pre allocation
#enable_hugepages = true

# Enable swap of vm memory. Default false.
# The behaviour is undefined if mem_prealloc is also set to true
#enable_swap = true

# This option changes the default hypervisor and kernel parameters
# to enable debug output where available. This extra output is added
# to the proxy logs, but only when proxy debug is also enabled.
# 
# Default false
#enable_debug = true

# Disable the customizations done in the runtime when it detects
# that it is running on top a VMM. This will result in the runtime
# behaving as it would when running on bare metal.
# 
#disable_nesting_checks = true

# This is the msize used for 9p shares. It is the number of bytes 
# used for 9p packet payload.
#msize_9p = 8192

# If true and vsocks are supported, use vsocks to communicate directly
# with the agent and no proxy is started, otherwise use unix
# sockets and start a proxy to communicate with the agent.
# Default false
#use_vsock = true

# VFIO devices are hotplugged on a bridge by default. 
# Enable hotplugging on root bus. This may be required for devices with
# a large PCI bar, as this is a current limitation with hotplugging on 
# a bridge. This value is valid for "pc" machine type.
# Default false
#hotplug_vfio_on_root_bus = true

# If host doesn't support vhost_net, set to true. Thus we won't create vhost fds for nics.
# Default false
#disable_vhost_net = true
#
# Default entropy source.
# The path to a host source of entropy (including a real hardware RNG)
# /dev/urandom and /dev/random are two main options.
# Be aware that /dev/random is a blocking source of entropy.  If the host
# runs out of entropy, the VMs boot time will increase leading to get startup
# timeouts.
# The source of entropy /dev/urandom is non-blocking and provides a
# generally acceptable source of entropy. It should work well for pretty much
# all practical purposes.
#entropy_source= "/dev/urandom"

# Path to OCI hook binaries in the *guest rootfs*.
# This does not affect host-side hooks which must instead be added to
# the OCI spec passed to the runtime.
#
# You can create a rootfs with hooks by customizing the osbuilder scripts:
# https://github.com/kata-containers/osbuilder
#
# Hooks must be stored in a subdirectory of guest_hook_path according to their
# hook type, i.e. "guest_hook_path/{prestart,postart,poststop}".
# The agent will scan these directories for executable files and add them, in
# lexicographical order, to the lifecycle of the guest container.
# Hooks are executed in the runtime namespace of the guest. See the official documentation:
# https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#posix-platform-hooks
# Warnings will be logged if any error is encountered will scanning for hooks,
# but it will not abort container execution.
#guest_hook_path = "/usr/share/oci/hooks"

[factory]
# VM templating support. Once enabled, new VMs are created from template
# using vm cloning. They will share the same initial kernel, initramfs and
# agent memory by mapping it readonly. It helps speeding up new container
# creation and saves a lot of memory if there are many kata containers running
# on the same host.
#
# When disabled, new VMs are created from scratch.
#
# Note: Requires "initrd=" to be set ("image=" is not supported).
#
# Default false
#enable_template = true

# The number of caches of VMCache:
# unspecified or == 0   --> VMCache is disabled
# > 0                   --> will be set to the specified number
#
# VMCache is a function that creates VMs as caches before using it.
# It helps speed up new container creation.
# The function consists of a server and some clients communicating
# through Unix socket.  The protocol is gRPC in protocols/cache/cache.proto.
# The VMCache server will create some VMs and cache them by factory cache.
# It will convert the VM to gRPC format and transport it when gets
# requestion from clients.
# Factory grpccache is the VMCache client.  It will request gRPC format
# VM and convert it back to a VM.  If VMCache function is enabled,
# kata-runtime will request VM from factory grpccache when it creates
# a new sandbox.
#
# Default 0
#vm_cache_number = 0

# Specify the address of the Unix socket that is used by VMCache.
#
# Default /var/run/kata-containers/cache.sock
#vm_cache_endpoint = "/var/run/kata-containers/cache.sock"

[proxy.kata]
path = "/opt/kata/libexec/kata-containers/kata-proxy"

# If enabled, proxy messages will be sent to the system log
# (default: disabled)
#enable_debug = true

[shim.kata]
path = "/opt/kata/libexec/kata-containers/kata-shim"

# If enabled, shim messages will be sent to the system log
# (default: disabled)
#enable_debug = true

# If enabled, the shim will create opentracing.io traces and spans.
# (See https://www.jaegertracing.io/docs/getting-started).
#
# Note: By default, the shim runs in a separate network namespace. Therefore,
# to allow it to send trace details to the Jaeger agent running on the host,
# it is necessary to set 'disable_new_netns=true' so that it runs in the host
# network namespace.
#
# (default: disabled)
#enable_tracing = true

[agent.kata]
# There is no field for this section. The goal is only to be able to
# specify which type of agent the user wants to use.

[netmon]
# If enabled, the network monitoring process gets started when the
# sandbox is created. This allows for the detection of some additional
# network being added to the existing network namespace, after the
# sandbox has been created.
# (default: disabled)
#enable_netmon = true

# Specify the path to the netmon binary.
path = "/opt/kata/libexec/kata-containers/kata-netmon"

# If enabled, netmon messages will be sent to the system log
# (default: disabled)
#enable_debug = true

[runtime]
# If enabled, the runtime will log additional debug messages to the
# system log
# (default: disabled)
#enable_debug = true
#
# Internetworking model
# Determines how the VM should be connected to the
# the container network interface
# Options:
#
#   - bridged
#     Uses a linux bridge to interconnect the container interface to
#     the VM. Works for most cases except macvlan and ipvlan.
#
#   - macvtap
#     Used when the Container network interface can be bridged using
#     macvtap.
#
#   - none
#     Used when customize network. Only creates a tap device. No veth pair.
#
#   - tcfilter
#     Uses tc filter rules to redirect traffic from the network interface
#     provided by plugin to a tap interface connected to the VM.
#
internetworking_model="macvtap"

# disable guest seccomp
# Determines whether container seccomp profiles are passed to the virtual
# machine and applied by the kata agent. If set to true, seccomp is not applied
# within the guest
# (default: true)
disable_guest_seccomp=true

# If enabled, the runtime will create opentracing.io traces and spans.
# (See https://www.jaegertracing.io/docs/getting-started).
# (default: disabled)
#enable_tracing = true

# If enabled, the runtime will not create a network namespace for shim and hypervisor processes.
# This option may have some potential impacts to your host. It should only be used when you know what you're doing.
# `disable_new_netns` conflicts with `enable_netmon`
# `disable_new_netns` conflicts with `internetworking_model=bridged` and `internetworking_model=macvtap`. It works only
# with `internetworking_model=none`. The tap device will be in the host network namespace and can connect to a bridge
# (like OVS) directly.
# If you are using docker, `disable_new_netns` only works with `docker run --net=none`
# (default: false)
#disable_new_netns = true

Config file /usr/share/defaults/kata-containers/configuration.toml not found


KSM throttler

version

Output of " --version":

kata-collect-data.sh: line 175: --version: command not found

systemd service

Image details

---
osbuilder:
  url: "https://github.com/kata-containers/osbuilder"
  version: "unknown"
rootfs-creation-time: "2019-04-05T23:22:51.835016544+0000Z"
description: "osbuilder rootfs"
file-format-version: "0.0.2"
architecture: "x86_64"
base-distro:
  name: "Clear"
  version: "28680"
  packages:
    default:
      - "chrony"
      - "iptables-bin"
      - "libudev0-shim"
      - "systemd"
    extra:

agent:
  url: "https://github.com/kata-containers/agent"
  name: "kata-agent"
  version: "1.6.1-992b4987a322054ac27e708071198cd8215f1d93"
  agent-is-init-daemon: "no"

Initrd details

No initrd


Logfiles

Runtime logs

Recent runtime problems found in system journal:

time="2019-04-11T12:16:39.487161674Z" level=error msg="Missing container ID, should at least provide one" arch=amd64 command=ps name=kata-runtime pid=100596 source=runtime
time="2019-04-11T12:43:04.830149331Z" level=error msg="Missing container ID, should at least provide one" arch=amd64 command=ps name=kata-runtime pid=113274 source=runtime

Proxy logs

No recent proxy problems found in system journal.

Shim logs

No recent shim problems found in system journal.

Throttler logs

No recent throttler problems found in system journal.


Container manager details

No docker
No kubectl
Have crio

crio

Output of "crio --version":

crio version 1.11.11-1.rhaos3.11.git474f73d.el7

Output of "systemctl show crio":

Type=notify
Restart=on-abnormal
NotifyAccess=main
RestartUSec=100ms
TimeoutStartUSec=0
TimeoutStopUSec=1min 30s
WatchdogUSec=0
WatchdogTimestamp=Thu 2019-04-11 12:36:22 UTC
WatchdogTimestampMonotonic=11733814378
StartLimitInterval=10000000
StartLimitBurst=5
StartLimitAction=none
FailureAction=none
PermissionsStartOnly=no
RootDirectoryStartOnly=no
RemainAfterExit=no
GuessMainPID=yes
MainPID=110904
ControlPID=0
FileDescriptorStoreMax=0
StatusErrno=0
Result=success
ExecMainStartTimestamp=Thu 2019-04-11 12:36:18 UTC
ExecMainStartTimestampMonotonic=11729815981
ExecMainExitTimestampMonotonic=0
ExecMainPID=110904
ExecMainCode=0
ExecMainStatus=0
ExecStart={ path=/usr/bin/crio ; argv[]=/usr/bin/crio $CRIO_STORAGE_OPTIONS $CRIO_NETWORK_OPTIONS ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
ExecReload={ path=/bin/kill ; argv[]=/bin/kill -s HUP $MAINPID ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
Slice=system.slice
ControlGroup=/system.slice/crio.service
MemoryCurrent=18446744073709551615
TasksCurrent=62
Delegate=no
CPUAccounting=no
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=infinity
BlockIOAccounting=no
BlockIOWeight=18446744073709551615
StartupBlockIOWeight=18446744073709551615
MemoryAccounting=no
MemoryLimit=18446744073709551615
DevicePolicy=auto
TasksAccounting=no
TasksMax=18446744073709551615
Environment=GOTRACEBACK=crash
EnvironmentFile=/etc/sysconfig/crio-storage (ignore_errors=yes)
EnvironmentFile=/etc/sysconfig/crio-network (ignore_errors=yes)
UMask=0022
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=1048576
LimitAS=18446744073709551615
LimitNPROC=1048576
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=514472
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=-999
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSet=18446744073709551615
AmbientCapabilities=0
MountFlags=0
PrivateTmp=no
PrivateNetwork=no
PrivateDevices=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=no
IgnoreSIGPIPE=yes
NoNewPrivileges=no
SystemCallErrorNumber=0
RuntimeDirectoryMode=0755
KillMode=control-group
KillSignal=15
SendSIGKILL=yes
SendSIGHUP=no
Id=crio.service
Names=crio.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=network-online.target systemd-journald.socket system.slice basic.target
Documentation=https://github.com/kubernetes-sigs/cri-o
Description=Open Container Initiative Daemon
LoadState=loaded
ActiveState=active
SubState=running
FragmentPath=/usr/lib/systemd/system/crio.service
UnitFileState=enabled
UnitFilePreset=disabled
InactiveExitTimestamp=Thu 2019-04-11 12:36:18 UTC
InactiveExitTimestampMonotonic=11729816040
ActiveEnterTimestamp=Thu 2019-04-11 12:36:22 UTC
ActiveEnterTimestampMonotonic=11733814688
ActiveExitTimestamp=Thu 2019-04-11 12:36:18 UTC
ActiveExitTimestampMonotonic=11729805414
InactiveEnterTimestamp=Thu 2019-04-11 12:36:18 UTC
InactiveEnterTimestampMonotonic=11729814582
CanStart=yes
CanStop=yes
CanReload=yes
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnFailureJobMode=replace
IgnoreOnIsolate=no
IgnoreOnSnapshot=no
NeedDaemonReload=no
JobTimeoutUSec=0
JobTimeoutAction=none
ConditionResult=yes
AssertResult=yes
ConditionTimestamp=Thu 2019-04-11 12:36:18 UTC
ConditionTimestampMonotonic=11729815464
AssertTimestamp=Thu 2019-04-11 12:36:18 UTC
AssertTimestampMonotonic=11729815464
Transient=no

Output of "cat /etc/crio/crio.conf":


# The "crio" table contains all of the server options.
[crio]

# CRI-O reads its storage defaults from the containers/storage configuration
# file, /etc/containers/storage.conf. Modify storage.conf if you want to
# change default storage for all tools that use containers/storage.  If you
# want to modify just crio, you can change the storage configuration in this
# file.

# root is a path to the "root directory". CRIO stores all of its data,
# including container images, in this directory.
#root = "/var/lib/containers/storage"

# run is a path to the "run directory". CRIO stores all of its state
# in this directory.
#runroot = "/var/run/containers/storage"

# storage_driver select which storage driver is used to manage storage
# of images and containers.
storage_driver = "overlay2"

# storage_option is used to pass an option to the storage driver.
#storage_option = [
#]

# The "crio.api" table contains settings for the kubelet/gRPC interface.
[crio.api]

# listen is the path to the AF_LOCAL socket on which crio will listen.
listen = "/var/run/crio/crio.sock"

# stream_address is the IP address on which the stream server will listen
stream_address = ""

# stream_port is the port on which the stream server will listen
stream_port = "10010"

# stream_enable_tls enables encrypted tls transport of the stream server
stream_enable_tls = false

# stream_tls_cert is the x509 certificate file path used to serve the encrypted stream.
# This file can change, and CRIO will automatically pick up the changes within 5 minutes.
stream_tls_cert = ""

# stream_tls_key is the key file path used to serve the encrypted stream.
# This file can change, and CRIO will automatically pick up the changes within 5 minutes.
stream_tls_key = ""

# stream_tls_ca is the x509 CA(s) file used to verify and authenticate client
# communication with the tls encrypted stream.
# This file can change, and CRIO will automatically pick up the changes within 5 minutes.
stream_tls_ca = ""

# file_locking is whether file-based locking will be used instead of
# in-memory locking
file_locking = true

# The "crio.runtime" table contains settings pertaining to the OCI
# runtime used and options for how to set up and manage the OCI runtime.
[crio.runtime]
manage_network_ns_lifecycle = true

# runtime is the OCI compatible runtime used for trusted container workloads.
# This is a mandatory setting as this runtime will be the default one
# and will also be used for untrusted container workloads if
# runtime_untrusted_workload is not set.
runtime = "/usr/bin/runc"

# runtime_untrusted_workload is the OCI compatible runtime used for untrusted
# container workloads. This is an optional setting, except if
# default_container_trust is set to "untrusted".
runtime_untrusted_workload = ""

# default_workload_trust is the default level of trust crio puts in container
# workloads. It can either be "trusted" or "untrusted", and the default
# is "trusted".
# Containers can be run through different container runtimes, depending on
# the trust hints we receive from kubelet:
# - If kubelet tags a container workload as untrusted, crio will try first to
# run it through the untrusted container workload runtime. If it is not set,
# crio will use the trusted runtime.
# - If kubelet does not provide any information about the container workload trust
# level, the selected runtime will depend on the default_container_trust setting.
# If it is set to "untrusted", then all containers except for the host privileged
# ones, will be run by the runtime_untrusted_workload runtime. Host privileged
# containers are by definition trusted and will always use the trusted container
# runtime. If default_container_trust is set to "trusted", crio will use the trusted
# container runtime for all containers.
default_workload_trust = "trusted"

# no_pivot instructs the runtime to not use pivot_root, but instead use MS_MOVE
no_pivot = false

# conmon is the path to conmon binary, used for managing the runtime.
conmon = "/usr/libexec/crio/conmon"

# conmon_env is the environment variable list for conmon process,
# used for passing necessary environment variable to conmon or runtime.
conmon_env = [
	"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
]

# selinux indicates whether or not SELinux will be used for pod
# separation on the host. If you enable this flag, SELinux must be running
# on the host.
selinux = false

# seccomp_profile is the seccomp json profile path which is used as the
# default for the runtime.
seccomp_profile = "/etc/crio/seccomp.json"

# apparmor_profile is the apparmor profile name which is used as the
# default for the runtime.
apparmor_profile = "crio-default"

# cgroup_manager is the cgroup management implementation to be used
# for the runtime.
cgroup_manager = "cgroupfs"

# default_capabilities is the list of capabilities to add and can be modified here.
# If capabilities below is commented out, the default list of capabilities defined in the
# spec will be added.
# If capabilities is empty below, only the capabilities defined in the container json
# file by the user/kube will be added.
default_capabilities = [
	"CHOWN", 
	"DAC_OVERRIDE", 
	"FSETID", 
	"FOWNER", 
	"NET_RAW", 
	"SETGID", 
	"SETUID", 
	"SETPCAP", 
	"NET_BIND_SERVICE", 
	"SYS_CHROOT", 
	"KILL", 
]

# hooks_dir_path is the oci hooks directory for automatically executed hooks
hooks_dir_path = "/usr/share/containers/oci/hooks.d"

# default_mounts is the mounts list to be mounted for the container when created
# deprecated, will be taken out in future versions, add default mounts to either
# /usr/share/containers/mounts.conf or /etc/containers/mounts.conf
default_mounts = [
]

# CRI-O reads its default mounts from the following two files:
# 1) /etc/containers/mounts.conf - this is the override file, where users can
# either add in their own default mounts, or override the default mounts shipped
# with the package.
# 2) /usr/share/containers/mounts.conf - this is the default file read for mounts.
# If you want CRI-O to read from a different, specific mounts file, you can change
# the default_mounts_file path right below. Note, if this is done, CRI-O will only add
# mounts it finds in this file.

# default_mounts_file is the file path holding the default mounts to be mounted for the
# container when created.
# default_mounts_file = ""

# pids_limit is the number of processes allowed in a container
pids_limit = 1024

# log_size_max is the max limit for the container log size in bytes.
# Negative values indicate that no limit is imposed.
log_size_max = -1

# read-only indicates whether all containers will run in read-only mode
read_only = false

# The "crio.image" table contains settings pertaining to the
# management of OCI images.

# uid_mappings specifies the UID mappings to have in the user namespace.
# A range is specified in the form containerUID:HostUID:Size.  Multiple
# ranges are separed by comma.
uid_mappings = ""

# gid_mappings specifies the GID mappings to have in the user namespace.
# A range is specified in the form containerGID:HostGID:Size.  Multiple
# ranges are separed by comma.
gid_mappings = ""

[crio.image]

# default_transport is the prefix we try prepending to an image name if the
# image name as we receive it can't be parsed as a valid source reference
default_transport = "docker://"

# pause_image is the image which we use to instantiate infra containers.
pause_image = "docker://k8s.gcr.io/pause:3.1"

# pause_command is the command to run in a pause_image to have a container just
# sit there.  If the image contains the necessary information, this value need
# not be specified.
pause_command = "/pause"

# signature_policy is the name of the file which decides what sort of policy we
# use when deciding whether or not to trust an image that we've pulled.
# Outside of testing situations, it is strongly advised that this be left
# unspecified so that the default system-wide policy will be used.
signature_policy = ""

# image_volumes controls how image volumes are handled.
# The valid values are mkdir and ignore.
image_volumes = "mkdir"

# CRI-O reads its configured registries defaults from the containers/image configuration
# file, /etc/containers/registries.conf. Modify registries.conf if you want to
# change default registries for all tools that use containers/image.  If you
# want to modify just crio, you can change the registies configuration in this
# file.

# insecure_registries is used to skip TLS verification when pulling images.
insecure_registries = [
  "10.233.0.0/18"
]

# registries is used to specify a comma separated list of registries to be used
# when pulling an unqualified image (e.g. fedora:rawhide).
registries = [
  "docker.io"
]

# The "crio.network" table contains settings pertaining to the
# management of CNI plugins.
[crio.network]

# network_dir is where CNI network configuration
# files are stored.
network_dir = "/etc/cni/net.d/"

# plugin_dir is where CNI plugin binaries are stored.
plugin_dir = "/opt/cni/bin/"
[crio.runtime.runtimes.kata-qemu]
  runtime_path = "/opt/kata/bin/kata-qemu"
[crio.runtime.runtimes.kata-fc]
  runtime_path = "/opt/kata/bin/kata-fc"

No containerd


Packages

No dpkg
Have rpm
Output of "rpm -qa|egrep "(cc-oci-runtimecc-runtimerunv|kata-proxy|kata-runtime|kata-shim|kata-ksm-throttler|kata-containers-image|linux-container|qemu-)"":

qemu-guest-agent-2.8.0-2.el7_5.1.x86_64
qemu-kvm-common-1.5.3-160.el7_6.1.x86_64
ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch
libvirt-daemon-driver-qemu-4.5.0-10.el7_6.6.x86_64
qemu-img-1.5.3-160.el7_6.1.x86_64
qemu-kvm-1.5.3-160.el7_6.1.x86_64

Run CI tests with both agents

Before we consider switching to the new rust agent, we need to get a clean CI run in all environments. as such, we need to run the CI twice, once for the golang agent, once for the rust one.

raspberry pi 4

Description of problem

Hello,
I am trying to install kata container on a raspberry pi 4 following this page:
https://github.com/kata-containers/documentation/blob/master/Developer-Guide.md

However I can't obtain the busybox shell.

Expected result

a running shell

Actual result

sudo docker run -ti --runtime kata-runtime busybox sh
docker: Error response from daemon: OCI runtime create failed: fail to launch qemu: exit status 1, error messages from qemu log:: unknown.


tonio@ubuntu:~$ sudo kata-collect-data.sh

Show kata-collect-data.sh details

Meta details

Running kata-collect-data.sh version 1.9.0-alpha1 (commit 0cc1a6f6ed0228e6c70b1503436172d96a452f01) at 2019-09-10.08:50:28.594343010+0000.


Runtime is /usr/local/bin/kata-runtime.

kata-env

Output of "/usr/local/bin/kata-runtime kata-env":

[Meta]
  Version = "1.0.23"

[Runtime]
  Debug = true
  Trace = false
  DisableGuestSeccomp = true
  DisableNewNetNs = false
  SandboxCgroupOnly = false
  Path = "/usr/local/bin/kata-runtime"
  [Runtime.Version]
    Semver = "1.9.0-alpha1"
    Commit = "0cc1a6f6ed0228e6c70b1503436172d96a452f01"
    OCI = "1.0.1-dev"
  [Runtime.Config]
    Path = "/etc/kata-containers/configuration.toml"

[Hypervisor]
  MachineType = "virt"
  Version = "QEMU emulator version 4.1.50 (v4.1.0-733-g89ea03a7dc-dirty)\nCopyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers"
  Path = "/usr/bin/qemu-system-aarch64"
  BlockDeviceDriver = "virtio-scsi"
  EntropySource = "/dev/urandom"
  Msize9p = 8192
  MemorySlots = 10
  Debug = true
  UseVSock = false
  SharedFS = "virtio-9p"

[Image]
  Path = "/usr/share/kata-containers/kata-containers-2019-08-28-14:34:51.381609631+0000-64caa3f"

[Kernel]
  Path = "/usr/share/kata-containers/vmlinuz-4.19.65-48"
  Parameters = "systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket agent.log=debug agent.log=debug initcall_debug"

[Initrd]
  Path = ""

[Proxy]
  Type = "kataProxy"
  Version = "kata-proxy version 1.9.0-alpha0-c843aeddcf56d1e60b082b2223d77bfaf971a0d9"
  Path = "/usr/libexec/kata-containers/kata-proxy"
  Debug = true

[Shim]
  Type = "kataShim"
  Version = "kata-shim version 1.9.0-alpha1-cb4105fb2443aeb9a4de4894d3440b7403eb926b"
  Path = "/usr/libexec/kata-containers/kata-shim"
  Debug = true

[Agent]
  Type = "kata"
  Debug = true
  Trace = false
  TraceMode = ""
  TraceType = ""

[Host]
  Kernel = "5.2.10-v8+"
  Architecture = "arm64"
  VMContainerCapable = true
  SupportVSocks = true
  [Host.Distro]
    Name = "Ubuntu"
    Version = "19.04"
  [Host.CPU]
    Vendor = "ARM Limited"
    Model = "v8"

[Netmon]
  Version = "kata-netmon version 1.9.0-alpha1"
  Path = "/usr/libexec/kata-containers/kata-netmon"
  Debug = true
  Enable = false

Runtime config files

Runtime default config files

/etc/kata-containers/configuration.toml
/usr/share/defaults/kata-containers/configuration.toml

Runtime config file contents

Output of "cat "/etc/kata-containers/configuration.toml"":

# Copyright (c) 2017-2019 Intel Corporation
#
# SPDX-License-Identifier: Apache-2.0
#

# XXX: WARNING: this file is auto-generated.
# XXX:
# XXX: Source file: "cli/config/configuration-qemu.toml.in"
# XXX: Project:
# XXX:   Name: Kata Containers
# XXX:   Type: kata

[hypervisor.qemu]
path = "/usr/bin/qemu-system-aarch64"
kernel = "/usr/share/kata-containers/vmlinuz.container"
#initrd = "/usr/share/kata-containers/kata-containers-initrd.img"
image = "/usr/share/kata-containers/kata-containers.img"
machine_type = "virt"

# Optional space-separated list of options to pass to the guest kernel.
# For example, use `kernel_params = "vsyscall=emulate"` if you are having
# trouble running pre-2.15 glibc.
#
# WARNING: - any parameter specified here will take priority over the default
# parameter value of the same name used to start the virtual machine.
# Do not set values here unless you understand the impact of doing so as you
# may stop the virtual machine from booting.
# To see the list of default parameters, enable hypervisor debug, create a
# container and look for 'default-kernel-parameters' log entries.
kernel_params = " agent.log=debug initcall_debug"

# Path to the firmware.
# If you want that qemu uses the default firmware leave this option empty
firmware = ""

# Machine accelerators
# comma-separated list of machine accelerators to pass to the hypervisor.
# For example, `machine_accelerators = "nosmm,nosmbus,nosata,nopit,static-prt,nofw"`
machine_accelerators=""

# Default number of vCPUs per SB/VM:
# unspecified or 0                --> will be set to 1
# < 0                             --> will be set to the actual number of physical cores
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores
default_vcpus = 1

# Default maximum number of vCPUs per SB/VM:
# unspecified or == 0             --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# WARNING: Depending of the architecture, the maximum number of vCPUs supported by KVM is used when
# the actual number of physical cores is greater than it.
# WARNING: Be aware that this value impacts the virtual machine's memory footprint and CPU
# the hotplug functionality. For example, `default_maxvcpus = 240` specifies that until 240 vCPUs
# can be added to a SB/VM, but the memory footprint will be big. Another example, with
# `default_maxvcpus = 8` the memory footprint will be small, but 8 will be the maximum number of
# vCPUs supported by the SB/VM. In general, we recommend that you do not edit this variable,
# unless you know what are you doing.
default_maxvcpus = 0

# Bridges can be used to hot plug devices.
# Limitations:
# * Currently only pci bridges are supported
# * Until 30 devices per bridge can be hot plugged.
# * Until 5 PCI bridges can be cold plugged per VM.
#   This limitation could be a bug in qemu or in the kernel
# Default number of bridges per SB/VM:
# unspecified or 0   --> will be set to 1
# > 1 <= 5           --> will be set to the specified number
# > 5                --> will be set to 5
default_bridges = 1

# Default memory size in MiB for SB/VM.
# If unspecified then it will be set 2048 MiB.
default_memory = 512
#
# Default memory slots per SB/VM.
# If unspecified then it will be set 10.
# This is will determine the times that memory will be hotadded to sandbox/VM.
#memory_slots = 10

# The size in MiB will be plused to max memory of hypervisor.
# It is the memory address space for the NVDIMM devie.
# If set block storage driver (block_device_driver) to "nvdimm",
# should set memory_offset to the size of block device.
# Default 0
#memory_offset = 0

# Disable block device from being used for a container's rootfs.
# In case of a storage driver like devicemapper where a container's 
# root file system is backed by a block device, the block device is passed
# directly to the hypervisor for performance reasons. 
# This flag prevents the block device from being passed to the hypervisor, 
# 9pfs is used instead to pass the rootfs.
disable_block_device_use = false

# Shared file system type:
#   - virtio-9p (default)
#   - virtio-fs
shared_fs = "virtio-9p"

# Path to vhost-user-fs daemon.
virtio_fs_daemon = "/usr/bin/virtiofsd-x86_64"

# Default size of DAX cache in MiB
virtio_fs_cache_size = 1024

# Extra args for virtiofsd daemon
#
# Format example:
#   ["-o", "arg1=xxx,arg2", "-o", "hello world", "--arg3=yyy"]
#
# see `virtiofsd -h` for possible options.
virtio_fs_extra_args = []

# Cache mode:
#
#  - none
#    Metadata, data, and pathname lookup are not cached in guest. They are
#    always fetched from host and any changes are immediately pushed to host.
#
#  - auto
#    Metadata and pathname lookup cache expires after a configured amount of
#    time (default is 1 second). Data is cached while the file is open (close
#    to open consistency).
#
#  - always
#    Metadata, data, and pathname lookup are cached in guest and never expire.
virtio_fs_cache = "always"

# Block storage driver to be used for the hypervisor in case the container
# rootfs is backed by a block device. This is virtio-scsi, virtio-blk
# or nvdimm.
block_device_driver = "virtio-scsi"

# Specifies cache-related options will be set to block devices or not.
# Default false
#block_device_cache_set = true

# Specifies cache-related options for block devices.
# Denotes whether use of O_DIRECT (bypass the host page cache) is enabled.
# Default false
#block_device_cache_direct = true

# Specifies cache-related options for block devices.
# Denotes whether flush requests for the device are ignored.
# Default false
#block_device_cache_noflush = true

# Enable iothreads (data-plane) to be used. This causes IO to be
# handled in a separate IO thread. This is currently only implemented
# for SCSI.
#
enable_iothreads = false

# Enable pre allocation of VM RAM, default false
# Enabling this will result in lower container density
# as all of the memory will be allocated and locked
# This is useful when you want to reserve all the memory
# upfront or in the cases where you want memory latencies
# to be very predictable
# Default false
#enable_mem_prealloc = true

# Enable huge pages for VM RAM, default false
# Enabling this will result in the VM memory
# being allocated using huge pages.
# This is useful when you want to use vhost-user network
# stacks within the container. This will automatically 
# result in memory pre allocation
#enable_hugepages = true

# Enable file based guest memory support. The default is an empty string which
# will disable this feature. In the case of virtio-fs, this is enabled
# automatically and '/dev/shm' is used as the backing folder.
# This option will be ignored if VM templating is enabled.
#file_mem_backend = ""

# Enable swap of vm memory. Default false.
# The behaviour is undefined if mem_prealloc is also set to true
#enable_swap = true

# This option changes the default hypervisor and kernel parameters
# to enable debug output where available. This extra output is added
# to the proxy logs, but only when proxy debug is also enabled.
# 
# Default false
enable_debug = true

# Disable the customizations done in the runtime when it detects
# that it is running on top a VMM. This will result in the runtime
# behaving as it would when running on bare metal.
# 
#disable_nesting_checks = true

# This is the msize used for 9p shares. It is the number of bytes 
# used for 9p packet payload.
#msize_9p = 8192

# If true and vsocks are supported, use vsocks to communicate directly
# with the agent and no proxy is started, otherwise use unix
# sockets and start a proxy to communicate with the agent.
# Default false
#use_vsock = true

# VFIO devices are hotplugged on a bridge by default. 
# Enable hotplugging on root bus. This may be required for devices with
# a large PCI bar, as this is a current limitation with hotplugging on 
# a bridge. This value is valid for "pc" machine type.
# Default false
#hotplug_vfio_on_root_bus = true

# If host doesn't support vhost_net, set to true. Thus we won't create vhost fds for nics.
# Default false
#disable_vhost_net = true
#
# Default entropy source.
# The path to a host source of entropy (including a real hardware RNG)
# /dev/urandom and /dev/random are two main options.
# Be aware that /dev/random is a blocking source of entropy.  If the host
# runs out of entropy, the VMs boot time will increase leading to get startup
# timeouts.
# The source of entropy /dev/urandom is non-blocking and provides a
# generally acceptable source of entropy. It should work well for pretty much
# all practical purposes.
#entropy_source= "/dev/urandom"

# Path to OCI hook binaries in the *guest rootfs*.
# This does not affect host-side hooks which must instead be added to
# the OCI spec passed to the runtime.
#
# You can create a rootfs with hooks by customizing the osbuilder scripts:
# https://github.com/kata-containers/osbuilder
#
# Hooks must be stored in a subdirectory of guest_hook_path according to their
# hook type, i.e. "guest_hook_path/{prestart,postart,poststop}".
# The agent will scan these directories for executable files and add them, in
# lexicographical order, to the lifecycle of the guest container.
# Hooks are executed in the runtime namespace of the guest. See the official documentation:
# https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#posix-platform-hooks
# Warnings will be logged if any error is encountered will scanning for hooks,
# but it will not abort container execution.
#guest_hook_path = "/usr/share/oci/hooks"

[factory]
# VM templating support. Once enabled, new VMs are created from template
# using vm cloning. They will share the same initial kernel, initramfs and
# agent memory by mapping it readonly. It helps speeding up new container
# creation and saves a lot of memory if there are many kata containers running
# on the same host.
#
# When disabled, new VMs are created from scratch.
#
# Note: Requires "initrd=" to be set ("image=" is not supported).
#
# Default false
#enable_template = true

# Specifies the path of template.
#
# Default "/run/vc/vm/template"
#template_path = "/run/vc/vm/template"

# The number of caches of VMCache:
# unspecified or == 0   --> VMCache is disabled
# > 0                   --> will be set to the specified number
#
# VMCache is a function that creates VMs as caches before using it.
# It helps speed up new container creation.
# The function consists of a server and some clients communicating
# through Unix socket.  The protocol is gRPC in protocols/cache/cache.proto.
# The VMCache server will create some VMs and cache them by factory cache.
# It will convert the VM to gRPC format and transport it when gets
# requestion from clients.
# Factory grpccache is the VMCache client.  It will request gRPC format
# VM and convert it back to a VM.  If VMCache function is enabled,
# kata-runtime will request VM from factory grpccache when it creates
# a new sandbox.
#
# Default 0
#vm_cache_number = 0

# Specify the address of the Unix socket that is used by VMCache.
#
# Default /var/run/kata-containers/cache.sock
#vm_cache_endpoint = "/var/run/kata-containers/cache.sock"

[proxy.kata]
path = "/usr/libexec/kata-containers/kata-proxy"

# If enabled, proxy messages will be sent to the system log
# (default: disabled)
enable_debug = true

[shim.kata]
path = "/usr/libexec/kata-containers/kata-shim"

# If enabled, shim messages will be sent to the system log
# (default: disabled)
enable_debug = true

# If enabled, the shim will create opentracing.io traces and spans.
# (See https://www.jaegertracing.io/docs/getting-started).
#
# Note: By default, the shim runs in a separate network namespace. Therefore,
# to allow it to send trace details to the Jaeger agent running on the host,
# it is necessary to set 'disable_new_netns=true' so that it runs in the host
# network namespace.
#
# (default: disabled)
#enable_tracing = true

[agent.kata]
# If enabled, make the agent display debug-level messages.
# (default: disabled)
enable_debug = true

# Enable agent tracing.
#
# If enabled, the default trace mode is "dynamic" and the
# default trace type is "isolated". The trace mode and type are set
# explicity with the `trace_type=` and `trace_mode=` options.
#
# Notes:
#
# - Tracing is ONLY enabled when `enable_tracing` is set: explicitly
#   setting `trace_mode=` and/or `trace_type=` without setting `enable_tracing`
#   will NOT activate agent tracing.
#
# - See https://github.com/kata-containers/agent/blob/master/TRACING.md for
#   full details.
#
# (default: disabled)
#enable_tracing = true
#
#trace_mode = "dynamic"
#trace_type = "isolated"

# Comma separated list of kernel modules and their parameters.
# These modules will be loaded in the guest kernel using modprobe(8).
# The following example can be used to load two kernel modules with parameters
#  - kernel_modules=["e1000e InterruptThrottleRate=3000,3000,3000 EEE=1", "i915 enable_ppgtt=0"]
# The first word is considered as the module name and the rest as its parameters.
# Container will not be started when:
#  * A kernel module is specified and the modprobe command is not installed in the guest
#    or it fails loading the module.
#  * The module is not available in the guest or it doesn't met the guest kernel
#    requirements, like architecture and version.
#
kernel_modules=[]


[netmon]
# If enabled, the network monitoring process gets started when the
# sandbox is created. This allows for the detection of some additional
# network being added to the existing network namespace, after the
# sandbox has been created.
# (default: disabled)
#enable_netmon = true

# Specify the path to the netmon binary.
path = "/usr/libexec/kata-containers/kata-netmon"

# If enabled, netmon messages will be sent to the system log
# (default: disabled)
enable_debug = true

[runtime]
# If enabled, the runtime will log additional debug messages to the
# system log
# (default: disabled)
enable_debug = true
#
# Internetworking model
# Determines how the VM should be connected to the
# the container network interface
# Options:
#
#   - bridged (Deprecated)
#     Uses a linux bridge to interconnect the container interface to
#     the VM. Works for most cases except macvlan and ipvlan.
#     ***NOTE: This feature has been deprecated with plans to remove this
#     feature in the future. Please use other network models listed below.
#
#   - macvtap
#     Used when the Container network interface can be bridged using
#     macvtap.
#
#   - none
#     Used when customize network. Only creates a tap device. No veth pair.
#
#   - tcfilter
#     Uses tc filter rules to redirect traffic from the network interface
#     provided by plugin to a tap interface connected to the VM.
#
internetworking_model="tcfilter"

# disable guest seccomp
# Determines whether container seccomp profiles are passed to the virtual
# machine and applied by the kata agent. If set to true, seccomp is not applied
# within the guest
# (default: true)
disable_guest_seccomp=true

# If enabled, the runtime will create opentracing.io traces and spans.
# (See https://www.jaegertracing.io/docs/getting-started).
# (default: disabled)
#enable_tracing = true

# If enabled, the runtime will not create a network namespace for shim and hypervisor processes.
# This option may have some potential impacts to your host. It should only be used when you know what you're doing.
# `disable_new_netns` conflicts with `enable_netmon`
# `disable_new_netns` conflicts with `internetworking_model=bridged` and `internetworking_model=macvtap`. It works only
# with `internetworking_model=none`. The tap device will be in the host network namespace and can connect to a bridge
# (like OVS) directly.
# If you are using docker, `disable_new_netns` only works with `docker run --net=none`
# (default: false)
#disable_new_netns = true

# if enabled, the runtime will add all the kata processes inside one dedicated cgroup.
# The container cgroups in the host are not created, just one single cgroup per sandbox.
# The sandbox cgroup is not constrained by the runtime
# The runtime caller is free to restrict or collect cgroup stats of the overall Kata sandbox.
# The sandbox cgroup path is the parent cgroup of a container with the PodSandbox annotation.
# See: https://godoc.org/github.com/kata-containers/runtime/virtcontainers#ContainerType
sandbox_cgroup_only=false

# Enabled experimental feature list, format: ["a", "b"].
# Experimental features are features not stable enough for production,
# They may break compatibility, and are prepared for a big version bump.
# Supported experimental features:
# 1. "newstore": new persist storage driver which breaks backward compatibility,
#				expected to move out of experimental in 2.0.0.
# (default: [])
experimental=[]

Output of "cat "/usr/share/defaults/kata-containers/configuration.toml"":

# Copyright (c) 2017-2019 Intel Corporation
#
# SPDX-License-Identifier: Apache-2.0
#

# XXX: WARNING: this file is auto-generated.
# XXX:
# XXX: Source file: "cli/config/configuration-qemu.toml.in"
# XXX: Project:
# XXX:   Name: Kata Containers
# XXX:   Type: kata

[hypervisor.qemu]
path = "/usr/bin/qemu-system-aarch64"
kernel = "/usr/share/kata-containers/vmlinuz.container"
#initrd = "/usr/share/kata-containers/kata-containers-initrd.img"
image = "/usr/share/kata-containers/kata-containers.img"
machine_type = "virt"

# Optional space-separated list of options to pass to the guest kernel.
# For example, use `kernel_params = "vsyscall=emulate"` if you are having
# trouble running pre-2.15 glibc.
#
# WARNING: - any parameter specified here will take priority over the default
# parameter value of the same name used to start the virtual machine.
# Do not set values here unless you understand the impact of doing so as you
# may stop the virtual machine from booting.
# To see the list of default parameters, enable hypervisor debug, create a
# container and look for 'default-kernel-parameters' log entries.
kernel_params = ""

# Path to the firmware.
# If you want that qemu uses the default firmware leave this option empty
firmware = ""

# Machine accelerators
# comma-separated list of machine accelerators to pass to the hypervisor.
# For example, `machine_accelerators = "nosmm,nosmbus,nosata,nopit,static-prt,nofw"`
machine_accelerators=""

# Default number of vCPUs per SB/VM:
# unspecified or 0                --> will be set to 1
# < 0                             --> will be set to the actual number of physical cores
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores
default_vcpus = 1

# Default maximum number of vCPUs per SB/VM:
# unspecified or == 0             --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores or to the maximum number
#                                     of vCPUs supported by KVM if that number is exceeded
# WARNING: Depending of the architecture, the maximum number of vCPUs supported by KVM is used when
# the actual number of physical cores is greater than it.
# WARNING: Be aware that this value impacts the virtual machine's memory footprint and CPU
# the hotplug functionality. For example, `default_maxvcpus = 240` specifies that until 240 vCPUs
# can be added to a SB/VM, but the memory footprint will be big. Another example, with
# `default_maxvcpus = 8` the memory footprint will be small, but 8 will be the maximum number of
# vCPUs supported by the SB/VM. In general, we recommend that you do not edit this variable,
# unless you know what are you doing.
default_maxvcpus = 0

# Bridges can be used to hot plug devices.
# Limitations:
# * Currently only pci bridges are supported
# * Until 30 devices per bridge can be hot plugged.
# * Until 5 PCI bridges can be cold plugged per VM.
#   This limitation could be a bug in qemu or in the kernel
# Default number of bridges per SB/VM:
# unspecified or 0   --> will be set to 1
# > 1 <= 5           --> will be set to the specified number
# > 5                --> will be set to 5
default_bridges = 1

# Default memory size in MiB for SB/VM.
# If unspecified then it will be set 2048 MiB.
default_memory = 512
#
# Default memory slots per SB/VM.
# If unspecified then it will be set 10.
# This is will determine the times that memory will be hotadded to sandbox/VM.
#memory_slots = 10

# The size in MiB will be plused to max memory of hypervisor.
# It is the memory address space for the NVDIMM devie.
# If set block storage driver (block_device_driver) to "nvdimm",
# should set memory_offset to the size of block device.
# Default 0
#memory_offset = 0

# Disable block device from being used for a container's rootfs.
# In case of a storage driver like devicemapper where a container's 
# root file system is backed by a block device, the block device is passed
# directly to the hypervisor for performance reasons. 
# This flag prevents the block device from being passed to the hypervisor, 
# 9pfs is used instead to pass the rootfs.
disable_block_device_use = false

# Shared file system type:
#   - virtio-9p (default)
#   - virtio-fs
shared_fs = "virtio-9p"

# Path to vhost-user-fs daemon.
virtio_fs_daemon = "/usr/bin/virtiofsd-x86_64"

# Default size of DAX cache in MiB
virtio_fs_cache_size = 1024

# Extra args for virtiofsd daemon
#
# Format example:
#   ["-o", "arg1=xxx,arg2", "-o", "hello world", "--arg3=yyy"]
#
# see `virtiofsd -h` for possible options.
virtio_fs_extra_args = []

# Cache mode:
#
#  - none
#    Metadata, data, and pathname lookup are not cached in guest. They are
#    always fetched from host and any changes are immediately pushed to host.
#
#  - auto
#    Metadata and pathname lookup cache expires after a configured amount of
#    time (default is 1 second). Data is cached while the file is open (close
#    to open consistency).
#
#  - always
#    Metadata, data, and pathname lookup are cached in guest and never expire.
virtio_fs_cache = "always"

# Block storage driver to be used for the hypervisor in case the container
# rootfs is backed by a block device. This is virtio-scsi, virtio-blk
# or nvdimm.
block_device_driver = "virtio-scsi"

# Specifies cache-related options will be set to block devices or not.
# Default false
#block_device_cache_set = true

# Specifies cache-related options for block devices.
# Denotes whether use of O_DIRECT (bypass the host page cache) is enabled.
# Default false
#block_device_cache_direct = true

# Specifies cache-related options for block devices.
# Denotes whether flush requests for the device are ignored.
# Default false
#block_device_cache_noflush = true

# Enable iothreads (data-plane) to be used. This causes IO to be
# handled in a separate IO thread. This is currently only implemented
# for SCSI.
#
enable_iothreads = false

# Enable pre allocation of VM RAM, default false
# Enabling this will result in lower container density
# as all of the memory will be allocated and locked
# This is useful when you want to reserve all the memory
# upfront or in the cases where you want memory latencies
# to be very predictable
# Default false
#enable_mem_prealloc = true

# Enable huge pages for VM RAM, default false
# Enabling this will result in the VM memory
# being allocated using huge pages.
# This is useful when you want to use vhost-user network
# stacks within the container. This will automatically 
# result in memory pre allocation
#enable_hugepages = true

# Enable file based guest memory support. The default is an empty string which
# will disable this feature. In the case of virtio-fs, this is enabled
# automatically and '/dev/shm' is used as the backing folder.
# This option will be ignored if VM templating is enabled.
#file_mem_backend = ""

# Enable swap of vm memory. Default false.
# The behaviour is undefined if mem_prealloc is also set to true
#enable_swap = true

# This option changes the default hypervisor and kernel parameters
# to enable debug output where available. This extra output is added
# to the proxy logs, but only when proxy debug is also enabled.
# 
# Default false
#enable_debug = true

# Disable the customizations done in the runtime when it detects
# that it is running on top a VMM. This will result in the runtime
# behaving as it would when running on bare metal.
# 
#disable_nesting_checks = true

# This is the msize used for 9p shares. It is the number of bytes 
# used for 9p packet payload.
#msize_9p = 8192

# If true and vsocks are supported, use vsocks to communicate directly
# with the agent and no proxy is started, otherwise use unix
# sockets and start a proxy to communicate with the agent.
# Default false
#use_vsock = true

# VFIO devices are hotplugged on a bridge by default. 
# Enable hotplugging on root bus. This may be required for devices with
# a large PCI bar, as this is a current limitation with hotplugging on 
# a bridge. This value is valid for "pc" machine type.
# Default false
#hotplug_vfio_on_root_bus = true

# If host doesn't support vhost_net, set to true. Thus we won't create vhost fds for nics.
# Default false
#disable_vhost_net = true
#
# Default entropy source.
# The path to a host source of entropy (including a real hardware RNG)
# /dev/urandom and /dev/random are two main options.
# Be aware that /dev/random is a blocking source of entropy.  If the host
# runs out of entropy, the VMs boot time will increase leading to get startup
# timeouts.
# The source of entropy /dev/urandom is non-blocking and provides a
# generally acceptable source of entropy. It should work well for pretty much
# all practical purposes.
#entropy_source= "/dev/urandom"

# Path to OCI hook binaries in the *guest rootfs*.
# This does not affect host-side hooks which must instead be added to
# the OCI spec passed to the runtime.
#
# You can create a rootfs with hooks by customizing the osbuilder scripts:
# https://github.com/kata-containers/osbuilder
#
# Hooks must be stored in a subdirectory of guest_hook_path according to their
# hook type, i.e. "guest_hook_path/{prestart,postart,poststop}".
# The agent will scan these directories for executable files and add them, in
# lexicographical order, to the lifecycle of the guest container.
# Hooks are executed in the runtime namespace of the guest. See the official documentation:
# https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#posix-platform-hooks
# Warnings will be logged if any error is encountered will scanning for hooks,
# but it will not abort container execution.
#guest_hook_path = "/usr/share/oci/hooks"

[factory]
# VM templating support. Once enabled, new VMs are created from template
# using vm cloning. They will share the same initial kernel, initramfs and
# agent memory by mapping it readonly. It helps speeding up new container
# creation and saves a lot of memory if there are many kata containers running
# on the same host.
#
# When disabled, new VMs are created from scratch.
#
# Note: Requires "initrd=" to be set ("image=" is not supported).
#
# Default false
#enable_template = true

# Specifies the path of template.
#
# Default "/run/vc/vm/template"
#template_path = "/run/vc/vm/template"

# The number of caches of VMCache:
# unspecified or == 0   --> VMCache is disabled
# > 0                   --> will be set to the specified number
#
# VMCache is a function that creates VMs as caches before using it.
# It helps speed up new container creation.
# The function consists of a server and some clients communicating
# through Unix socket.  The protocol is gRPC in protocols/cache/cache.proto.
# The VMCache server will create some VMs and cache them by factory cache.
# It will convert the VM to gRPC format and transport it when gets
# requestion from clients.
# Factory grpccache is the VMCache client.  It will request gRPC format
# VM and convert it back to a VM.  If VMCache function is enabled,
# kata-runtime will request VM from factory grpccache when it creates
# a new sandbox.
#
# Default 0
#vm_cache_number = 0

# Specify the address of the Unix socket that is used by VMCache.
#
# Default /var/run/kata-containers/cache.sock
#vm_cache_endpoint = "/var/run/kata-containers/cache.sock"

[proxy.kata]
path = "/usr/libexec/kata-containers/kata-proxy"

# If enabled, proxy messages will be sent to the system log
# (default: disabled)
#enable_debug = true

[shim.kata]
path = "/usr/libexec/kata-containers/kata-shim"

# If enabled, shim messages will be sent to the system log
# (default: disabled)
#enable_debug = true

# If enabled, the shim will create opentracing.io traces and spans.
# (See https://www.jaegertracing.io/docs/getting-started).
#
# Note: By default, the shim runs in a separate network namespace. Therefore,
# to allow it to send trace details to the Jaeger agent running on the host,
# it is necessary to set 'disable_new_netns=true' so that it runs in the host
# network namespace.
#
# (default: disabled)
#enable_tracing = true

[agent.kata]
# If enabled, make the agent display debug-level messages.
# (default: disabled)
#enable_debug = true

# Enable agent tracing.
#
# If enabled, the default trace mode is "dynamic" and the
# default trace type is "isolated". The trace mode and type are set
# explicity with the `trace_type=` and `trace_mode=` options.
#
# Notes:
#
# - Tracing is ONLY enabled when `enable_tracing` is set: explicitly
#   setting `trace_mode=` and/or `trace_type=` without setting `enable_tracing`
#   will NOT activate agent tracing.
#
# - See https://github.com/kata-containers/agent/blob/master/TRACING.md for
#   full details.
#
# (default: disabled)
#enable_tracing = true
#
#trace_mode = "dynamic"
#trace_type = "isolated"

# Comma separated list of kernel modules and their parameters.
# These modules will be loaded in the guest kernel using modprobe(8).
# The following example can be used to load two kernel modules with parameters
#  - kernel_modules=["e1000e InterruptThrottleRate=3000,3000,3000 EEE=1", "i915 enable_ppgtt=0"]
# The first word is considered as the module name and the rest as its parameters.
# Container will not be started when:
#  * A kernel module is specified and the modprobe command is not installed in the guest
#    or it fails loading the module.
#  * The module is not available in the guest or it doesn't met the guest kernel
#    requirements, like architecture and version.
#
kernel_modules=[]


[netmon]
# If enabled, the network monitoring process gets started when the
# sandbox is created. This allows for the detection of some additional
# network being added to the existing network namespace, after the
# sandbox has been created.
# (default: disabled)
#enable_netmon = true

# Specify the path to the netmon binary.
path = "/usr/libexec/kata-containers/kata-netmon"

# If enabled, netmon messages will be sent to the system log
# (default: disabled)
#enable_debug = true

[runtime]
# If enabled, the runtime will log additional debug messages to the
# system log
# (default: disabled)
enable_debug = true
#
# Internetworking model
# Determines how the VM should be connected to the
# the container network interface
# Options:
#
#   - bridged (Deprecated)
#     Uses a linux bridge to interconnect the container interface to
#     the VM. Works for most cases except macvlan and ipvlan.
#     ***NOTE: This feature has been deprecated with plans to remove this
#     feature in the future. Please use other network models listed below.
#
#   - macvtap
#     Used when the Container network interface can be bridged using
#     macvtap.
#
#   - none
#     Used when customize network. Only creates a tap device. No veth pair.
#
#   - tcfilter
#     Uses tc filter rules to redirect traffic from the network interface
#     provided by plugin to a tap interface connected to the VM.
#
internetworking_model="tcfilter"

# disable guest seccomp
# Determines whether container seccomp profiles are passed to the virtual
# machine and applied by the kata agent. If set to true, seccomp is not applied
# within the guest
# (default: true)
disable_guest_seccomp=true

# If enabled, the runtime will create opentracing.io traces and spans.
# (See https://www.jaegertracing.io/docs/getting-started).
# (default: disabled)
#enable_tracing = true

# If enabled, the runtime will not create a network namespace for shim and hypervisor processes.
# This option may have some potential impacts to your host. It should only be used when you know what you're doing.
# `disable_new_netns` conflicts with `enable_netmon`
# `disable_new_netns` conflicts with `internetworking_model=bridged` and `internetworking_model=macvtap`. It works only
# with `internetworking_model=none`. The tap device will be in the host network namespace and can connect to a bridge
# (like OVS) directly.
# If you are using docker, `disable_new_netns` only works with `docker run --net=none`
# (default: false)
#disable_new_netns = true

# if enabled, the runtime will add all the kata processes inside one dedicated cgroup.
# The container cgroups in the host are not created, just one single cgroup per sandbox.
# The sandbox cgroup is not constrained by the runtime
# The runtime caller is free to restrict or collect cgroup stats of the overall Kata sandbox.
# The sandbox cgroup path is the parent cgroup of a container with the PodSandbox annotation.
# See: https://godoc.org/github.com/kata-containers/runtime/virtcontainers#ContainerType
sandbox_cgroup_only=false

# Enabled experimental feature list, format: ["a", "b"].
# Experimental features are features not stable enough for production,
# They may break compatibility, and are prepared for a big version bump.
# Supported experimental features:
# 1. "newstore": new persist storage driver which breaks backward compatibility,
#				expected to move out of experimental in 2.0.0.
# (default: [])
experimental=[]

KSM throttler

version

Output of " --version":

/usr/local/bin/kata-collect-data.sh: line 178: --version: command not found

systemd service

Image details

---
osbuilder:
  url: "https://github.com/kata-containers/osbuilder"
  version: "unknown"
rootfs-creation-time: "Failed at 173: date -u -d@${SOURCE_DATE_EPOCH:-$(date +%s.%N)} '+%Y-%m-%dT%T.%N%zZ'"
description: "osbuilder rootfs"
file-format-version: "0.0.2"
architecture: "aarch64"
base-distro:
  name: "Alpine"
  version: "v3.7"
  packages:
    default:
      - "iptables"
    extra:

agent:
  url: "https://github.com/kata-containers/agent"
  name: "kata-agent"
  version: "1.9.0-alpha0-dfbcc01c5444a344e98a85986a012c5b3412181f"
  agent-is-init-daemon: "yes"

Initrd details

No initrd


Logfiles

Runtime logs

Recent runtime problems found in system journal:

time="2019-09-03T12:08:33.283691466Z" level=warning msg="load sandbox devices failed" arch=arm64 command=create container=acd33e08be7d7a0e442be45f2224c2b086f3966f11bf7b276f86832f3e2f90b3 error="open /run/vc/sbs/acd33e08be7d7a0e442be45f2224c2b086f3966f11bf7b276f86832f3e2f90b3/devices.json: no such file or directory" name=kata-runtime pid=3341 sandbox=acd33e08be7d7a0e442be45f2224c2b086f3966f11bf7b276f86832f3e2f90b3 sandboxid=acd33e08be7d7a0e442be45f2224c2b086f3966f11bf7b276f86832f3e2f90b3 source=virtcontainers subsystem=sandbox
time="2019-09-03T12:08:34.295807834Z" level=error msg="Unable to launch /usr/bin/qemu-system-aarch64: exit status 1" arch=arm64 command=create container=acd33e08be7d7a0e442be45f2224c2b086f3966f11bf7b276f86832f3e2f90b3 name=kata-runtime pid=3341 source=virtcontainers subsystem=qmp
time="2019-09-03T12:08:34.296775922Z" level=error msg="Could not access KVM kernel module: No such file or directory\nqemu-system-aarch64: failed to initialize KVM: No such file or directory\n" arch=arm64 command=create container=acd33e08be7d7a0e442be45f2224c2b086f3966f11bf7b276f86832f3e2f90b3 name=kata-runtime pid=3341 source=virtcontainers subsystem=qmp
time="2019-09-03T12:08:34.374380838Z" level=warning msg="failed to cleanup netns" arch=arm64 command=create container=acd33e08be7d7a0e442be45f2224c2b086f3966f11bf7b276f86832f3e2f90b3 error="failed to get netns /var/run/netns/cni-bb969b12-6c66-a0aa-d62a-30a522b98009: failed to Statfs \"/var/run/netns/cni-bb969b12-6c66-a0aa-d62a-30a522b98009\": no such file or directory" name=kata-runtime path=/var/run/netns/cni-bb969b12-6c66-a0aa-d62a-30a522b98009 pid=3341 source=katautils
time="2019-09-03T12:08:34.374734096Z" level=error msg="fail to launch qemu: exit status 1, error messages from qemu log: Could not access KVM kernel module: No such file or directory\nqemu-system-aarch64: failed to initialize KVM: No such file or directory\n" arch=arm64 command=create container=acd33e08be7d7a0e442be45f2224c2b086f3966f11bf7b276f86832f3e2f90b3 name=kata-runtime pid=3341 source=runtime
time="2019-09-03T14:04:38.787561791Z" level=warning msg="VM memory (512MB) smaller than image \"/usr/share/kata-containers/kata-containers-2019-08-28-14:34:51.381609631+0000-64caa3f\" size (1024MB)" arch=arm64 command=create name=kata-runtime pid=1167 source=katautils
time="2019-09-03T14:04:39.106638492Z" level=info msg="Unable to know if the system is running inside a VM" arch=arm64 command=create container=a4082a21d99b0c3a08afcd9d20ec0c127a7890e0b78bc983378e9aa18fa432c2 name=kata-runtime pid=1167 source=virtcontainers
time="2019-09-03T14:04:39.107237003Z" level=warning msg="load sandbox devices failed" arch=arm64 command=create container=a4082a21d99b0c3a08afcd9d20ec0c127a7890e0b78bc983378e9aa18fa432c2 error="open /run/vc/sbs/a4082a21d99b0c3a08afcd9d20ec0c127a7890e0b78bc983378e9aa18fa432c2/devices.json: no such file or directory" name=kata-runtime pid=1167 sandbox=a4082a21d99b0c3a08afcd9d20ec0c127a7890e0b78bc983378e9aa18fa432c2 sandboxid=a4082a21d99b0c3a08afcd9d20ec0c127a7890e0b78bc983378e9aa18fa432c2 source=virtcontainers subsystem=sandbox
time="2019-09-03T14:04:40.552777585Z" level=error msg="Unable to launch /usr/bin/qemu-system-aarch64: exit status 1" arch=arm64 command=create container=a4082a21d99b0c3a08afcd9d20ec0c127a7890e0b78bc983378e9aa18fa432c2 name=kata-runtime pid=1167 source=virtcontainers subsystem=qmp
time="2019-09-03T14:04:40.552998835Z" level=error msg="qemu-system-aarch64: -device nvdimm,id=nv0,memdev=mem0: 'nvdimm' is not a valid device model name\n" arch=arm64 command=create container=a4082a21d99b0c3a08afcd9d20ec0c127a7890e0b78bc983378e9aa18fa432c2 name=kata-runtime pid=1167 source=virtcontainers subsystem=qmp
time="2019-09-03T14:04:40.634089735Z" level=warning msg="failed to cleanup netns" arch=arm64 command=create container=a4082a21d99b0c3a08afcd9d20ec0c127a7890e0b78bc983378e9aa18fa432c2 error="failed to get netns /var/run/netns/cni-cb2391c7-b376-378a-0720-e0830ced025f: failed to Statfs \"/var/run/netns/cni-cb2391c7-b376-378a-0720-e0830ced025f\": no such file or directory" name=kata-runtime path=/var/run/netns/cni-cb2391c7-b376-378a-0720-e0830ced025f pid=1167 source=katautils
time="2019-09-03T14:04:40.634305689Z" level=error msg="fail to launch qemu: exit status 1, error messages from qemu log: qemu-system-aarch64: -device nvdimm,id=nv0,memdev=mem0: 'nvdimm' is not a valid device model name\n" arch=arm64 command=create container=a4082a21d99b0c3a08afcd9d20ec0c127a7890e0b78bc983378e9aa18fa432c2 name=kata-runtime pid=1167 source=runtime
time="2019-09-03T14:18:41.515793435Z" level=warning msg="VM memory (512MB) smaller than image \"/usr/share/kata-containers/kata-containers-2019-08-28-14:34:51.381609631+0000-64caa3f\" size (1024MB)" arch=arm64 command=create name=kata-runtime pid=1972 source=katautils
time="2019-09-03T14:18:42.285774217Z" level=info msg="Unable to know if the system is running inside a VM" arch=arm64 command=create container=782f083ffa53575ac71beecedd85bad3022710abe70ac490093a46d6105c06da name=kata-runtime pid=1972 source=virtcontainers
time="2019-09-03T14:18:42.286794084Z" level=warning msg="load sandbox devices failed" arch=arm64 command=create container=782f083ffa53575ac71beecedd85bad3022710abe70ac490093a46d6105c06da error="open /run/vc/sbs/782f083ffa53575ac71beecedd85bad3022710abe70ac490093a46d6105c06da/devices.json: no such file or directory" name=kata-runtime pid=1972 sandbox=782f083ffa53575ac71beecedd85bad3022710abe70ac490093a46d6105c06da sandboxid=782f083ffa53575ac71beecedd85bad3022710abe70ac490093a46d6105c06da source=virtcontainers subsystem=sandbox
time="2019-09-03T14:18:43.308144028Z" level=error msg="Unable to launch /usr/bin/qemu-system-aarch64: exit status 1" arch=arm64 command=create container=782f083ffa53575ac71beecedd85bad3022710abe70ac490093a46d6105c06da name=kata-runtime pid=1972 source=virtcontainers subsystem=qmp
time="2019-09-03T14:18:43.308367064Z" level=error msg="qemu-system-aarch64: Property '.virt' not found\n" arch=arm64 command=create container=782f083ffa53575ac71beecedd85bad3022710abe70ac490093a46d6105c06da name=kata-runtime pid=1972 source=virtcontainers subsystem=qmp
time="2019-09-03T14:18:43.384422032Z" level=warning msg="failed to cleanup netns" arch=arm64 command=create container=782f083ffa53575ac71beecedd85bad3022710abe70ac490093a46d6105c06da error="failed to get netns /var/run/netns/cni-93861221-dd62-bf90-0749-e9ce8c012ce0: failed to Statfs \"/var/run/netns/cni-93861221-dd62-bf90-0749-e9ce8c012ce0\": no such file or directory" name=kata-runtime path=/var/run/netns/cni-93861221-dd62-bf90-0749-e9ce8c012ce0 pid=1972 source=katautils
time="2019-09-03T14:18:43.384696105Z" level=error msg="fail to launch qemu: exit status 1, error messages from qemu log: qemu-system-aarch64: Property '.virt' not found\n" arch=arm64 command=create container=782f083ffa53575ac71beecedd85bad3022710abe70ac490093a46d6105c06da name=kata-runtime pid=1972 source=runtime
time="2019-09-03T14:24:04.163837562Z" level=warning msg="VM memory (512MB) smaller than image \"/usr/share/kata-containers/kata-containers-2019-08-28-14:34:51.381609631+0000-64caa3f\" size (1024MB)" arch=arm64 command=create name=kata-runtime pid=2650 source=katautils
time="2019-09-03T14:24:04.700306427Z" level=info msg="Unable to know if the system is running inside a VM" arch=arm64 command=create container=64965ec0551b7180d22f1e6b64cceb3ea6c3c6e937532d271519c7fb22819c46 name=kata-runtime pid=2650 source=virtcontainers
time="2019-09-03T14:24:04.701305474Z" level=warning msg="load sandbox devices failed" arch=arm64 command=create container=64965ec0551b7180d22f1e6b64cceb3ea6c3c6e937532d271519c7fb22819c46 error="open /run/vc/sbs/64965ec0551b7180d22f1e6b64cceb3ea6c3c6e937532d271519c7fb22819c46/devices.json: no such file or directory" name=kata-runtime pid=2650 sandbox=64965ec0551b7180d22f1e6b64cceb3ea6c3c6e937532d271519c7fb22819c46 sandboxid=64965ec0551b7180d22f1e6b64cceb3ea6c3c6e937532d271519c7fb22819c46 source=virtcontainers subsystem=sandbox
time="2019-09-03T14:24:05.466759329Z" level=error msg="Unable to launch /usr/bin/qemu-system-aarch64: exit status 1" arch=arm64 command=create container=64965ec0551b7180d22f1e6b64cceb3ea6c3c6e937532d271519c7fb22819c46 name=kata-runtime pid=2650 source=virtcontainers subsystem=qmp
time="2019-09-03T14:24:05.467006049Z" level=error msg="qemu-system-aarch64: Property '.virto-blk' not found\n" arch=arm64 command=create container=64965ec0551b7180d22f1e6b64cceb3ea6c3c6e937532d271519c7fb22819c46 name=kata-runtime pid=2650 source=virtcontainers subsystem=qmp
time="2019-09-03T14:24:05.547597686Z" level=warning msg="failed to cleanup netns" arch=arm64 command=create container=64965ec0551b7180d22f1e6b64cceb3ea6c3c6e937532d271519c7fb22819c46 error="failed to get netns /var/run/netns/cni-8156911f-806f-597e-3bc1-aa8ef92098f8: failed to Statfs \"/var/run/netns/cni-8156911f-806f-597e-3bc1-aa8ef92098f8\": no such file or directory" name=kata-runtime path=/var/run/netns/cni-8156911f-806f-597e-3bc1-aa8ef92098f8 pid=2650 source=katautils
time="2019-09-03T14:24:05.547771722Z" level=error msg="fail to launch qemu: exit status 1, error messages from qemu log: qemu-system-aarch64: Property '.virto-blk' not found\n" arch=arm64 command=create container=64965ec0551b7180d22f1e6b64cceb3ea6c3c6e937532d271519c7fb22819c46 name=kata-runtime pid=2650 source=runtime
time="2019-09-03T14:30:14.003398032Z" level=warning msg="VM memory (512MB) smaller than image \"/usr/share/kata-containers/kata-containers-2019-08-28-14:34:51.381609631+0000-64caa3f\" size (1024MB)" arch=arm64 command=create name=kata-runtime pid=3259 source=katautils
time="2019-09-03T14:30:15.69201395Z" level=info msg="Unable to know if the system is running inside a VM" arch=arm64 command=create container=7c6837dfe1ff10570520a9173201a10e9e6fcf5154bdc1cf111e9db88430ae77 name=kata-runtime pid=3259 source=virtcontainers
time="2019-09-03T14:30:15.692984188Z" level=warning msg="load sandbox devices failed" arch=arm64 command=create container=7c6837dfe1ff10570520a9173201a10e9e6fcf5154bdc1cf111e9db88430ae77 error="open /run/vc/sbs/7c6837dfe1ff10570520a9173201a10e9e6fcf5154bdc1cf111e9db88430ae77/devices.json: no such file or directory" name=kata-runtime pid=3259 sandbox=7c6837dfe1ff10570520a9173201a10e9e6fcf5154bdc1cf111e9db88430ae77 sandboxid=7c6837dfe1ff10570520a9173201a10e9e6fcf5154bdc1cf111e9db88430ae77 source=virtcontainers subsystem=sandbox
time="2019-09-03T14:30:16.749254689Z" level=error msg="Unable to launch /usr/bin/qemu-system-aarch64: exit status 1" arch=arm64 command=create container=7c6837dfe1ff10570520a9173201a10e9e6fcf5154bdc1cf111e9db88430ae77 name=kata-runtime pid=3259 source=virtcontainers subsystem=qmp
time="2019-09-03T14:30:16.749492651Z" level=error msg="qemu-system-aarch64: Property '.virtio-blk' not found\n" arch=arm64 command=create container=7c6837dfe1ff10570520a9173201a10e9e6fcf5154bdc1cf111e9db88430ae77 name=kata-runtime pid=3259 source=virtcontainers subsystem=qmp
time="2019-09-03T14:30:16.83235203Z" level=warning msg="failed to cleanup netns" arch=arm64 command=create container=7c6837dfe1ff10570520a9173201a10e9e6fcf5154bdc1cf111e9db88430ae77 error="failed to get netns /var/run/netns/cni-24130e52-726a-3a80-203d-1bff5a501862: failed to Statfs \"/var/run/netns/cni-24130e52-726a-3a80-203d-1bff5a501862\": no such file or directory" name=kata-runtime path=/var/run/netns/cni-24130e52-726a-3a80-203d-1bff5a501862 pid=3259 source=katautils
time="2019-09-03T14:30:16.832928232Z" level=error msg="fail to launch qemu: exit status 1, error messages from qemu log: qemu-system-aarch64: Property '.virtio-blk' not found\n" arch=arm64 command=create container=7c6837dfe1ff10570520a9173201a10e9e6fcf5154bdc1cf111e9db88430ae77 name=kata-runtime pid=3259 source=runtime
time="2019-09-03T14:32:28.547073422Z" level=warning msg="VM memory (512MB) smaller than image \"/usr/share/kata-containers/kata-containers-2019-08-28-14:34:51.381609631+0000-64caa3f\" size (1024MB)" arch=arm64 command=create name=kata-runtime pid=3861 source=katautils
time="2019-09-03T14:32:28.849962319Z" level=info msg="Unable to know if the system is running inside a VM" arch=arm64 command=create container=fb00b8a28eafbfb1157bcf468f6a3a1c0b90a576357d6c3a2a2750ccc47e1a9f name=kata-runtime pid=3861 source=virtcontainers
time="2019-09-03T14:32:28.85096002Z" level=warning msg="load sandbox devices failed" arch=arm64 command=create container=fb00b8a28eafbfb1157bcf468f6a3a1c0b90a576357d6c3a2a2750ccc47e1a9f error="open /run/vc/sbs/fb00b8a28eafbfb1157bcf468f6a3a1c0b90a576357d6c3a2a2750ccc47e1a9f/devices.json: no such file or directory" name=kata-runtime pid=3861 sandbox=fb00b8a28eafbfb1157bcf468f6a3a1c0b90a576357d6c3a2a2750ccc47e1a9f sandboxid=fb00b8a28eafbfb1157bcf468f6a3a1c0b90a576357d6c3a2a2750ccc47e1a9f source=virtcontainers subsystem=sandbox
time="2019-09-03T14:32:28.967019088Z" level=error msg="Unable to launch /usr/bin/qemu-system-aarch64: exit status 1" arch=arm64 command=create container=fb00b8a28eafbfb1157bcf468f6a3a1c0b90a576357d6c3a2a2750ccc47e1a9f name=kata-runtime pid=3861 source=virtcontainers subsystem=qmp
time="2019-09-03T14:32:28.967248143Z" level=error msg="qemu-system-aarch64: Property '.virtio-scsi' not found\n" arch=arm64 command=create container=fb00b8a28eafbfb1157bcf468f6a3a1c0b90a576357d6c3a2a2750ccc47e1a9f name=kata-runtime pid=3861 source=virtcontainers subsystem=qmp
time="2019-09-03T14:32:29.044400498Z" level=warning msg="failed to cleanup netns" arch=arm64 command=create container=fb00b8a28eafbfb1157bcf468f6a3a1c0b90a576357d6c3a2a2750ccc47e1a9f error="failed to get netns /var/run/netns/cni-40c890a1-36c6-05c1-bf28-13984e3406cc: failed to Statfs \"/var/run/netns/cni-40c890a1-36c6-05c1-bf28-13984e3406cc\": no such file or directory" name=kata-runtime path=/var/run/netns/cni-40c890a1-36c6-05c1-bf28-13984e3406cc pid=3861 source=katautils
time="2019-09-03T14:32:29.044708756Z" level=error msg="fail to launch qemu: exit status 1, error messages from qemu log: qemu-system-aarch64: Property '.virtio-scsi' not found\n" arch=arm64 command=create container=fb00b8a28eafbfb1157bcf468f6a3a1c0b90a576357d6c3a2a2750ccc47e1a9f name=kata-runtime pid=3861 source=runtime
time="2019-09-10T08:41:27.729594114Z" level=warning msg="VM memory (512MB) smaller than image \"/usr/share/kata-containers/kata-containers-2019-08-28-14:34:51.381609631+0000-64caa3f\" size (1024MB)" arch=arm64 command=create name=kata-runtime pid=4175 source=katautils
time="2019-09-10T08:41:28.064227015Z" level=info msg="Unable to know if the system is running inside a VM" arch=arm64 command=create container=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b name=kata-runtime pid=4175 source=virtcontainers
time="2019-09-10T08:41:28.064840585Z" level=debug msg="Could not retrieve anything from storage" arch=arm64 command=create container=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b name=kata-runtime pid=4175 source=virtcontainers subsystem=kata_agent
time="2019-09-10T08:41:28.064983102Z" level=warning msg="load sandbox devices failed" arch=arm64 command=create container=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b error="open /run/vc/sbs/c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b/devices.json: no such file or directory" name=kata-runtime pid=4175 sandbox=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b sandboxid=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b source=virtcontainers subsystem=sandbox
time="2019-09-10T08:41:28.182967239Z" level=debug arch=arm64 command=create container=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b default-kernel-parameters="console=hvc0 console=hvc1 iommu.passthrough=0 root=/dev/pmem0p1 rootflags=data=ordered,errors=remount-ro ro rootfstype=ext4 debug systemd.show_status=true systemd.log_level=debug" name=kata-runtime pid=4175 source=virtcontainers subsystem=qemu
time="2019-09-10T08:41:29.113178433Z" level=error msg="Unable to launch /usr/bin/qemu-system-aarch64: exit status 1" arch=arm64 command=create container=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b name=kata-runtime pid=4175 source=virtcontainers subsystem=qmp
time="2019-09-10T08:41:29.114285795Z" level=error arch=arm64 command=create container=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b name=kata-runtime pid=4175 source=virtcontainers subsystem=qmp
time="2019-09-10T08:41:29.191321454Z" level=warning msg="sandox cgroups path is empty" arch=arm64 command=create container=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b name=kata-runtime pid=4175 sandbox=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b source=virtcontainers subsystem=sandbox
time="2019-09-10T08:41:29.196055235Z" level=warning msg="failed to cleanup netns" arch=arm64 command=create container=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b error="failed to get netns /var/run/netns/cni-4aa4ee3c-6fbb-06dd-3337-2c3db991643e: failed to Statfs \"/var/run/netns/cni-4aa4ee3c-6fbb-06dd-3337-2c3db991643e\": no such file or directory" name=kata-runtime path=/var/run/netns/cni-4aa4ee3c-6fbb-06dd-3337-2c3db991643e pid=4175 source=katautils
time="2019-09-10T08:41:29.196626786Z" level=error msg="fail to launch qemu: exit status 1, error messages from qemu log: " arch=arm64 command=create container=c9232a90e81ed5f6dab154b5164a3c4db9131a83107c690538d6e517d45f680b name=kata-runtime pid=4175 source=runtime

Proxy logs

No recent proxy problems found in system journal.

Shim logs

No recent shim problems found in system journal.

Throttler logs

No recent throttler problems found in system journal.


Container manager details

Have docker

Docker

Output of "docker version":

Client: Docker Engine - Community
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        6a30dfc
 Built:             Thu Aug 29 05:32:20 2019
 OS/Arch:           linux/arm64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       6a30dfc
  Built:            Thu Aug 29 05:30:52 2019
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of "docker info":

Client:
 Debug Mode: false

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 1
 Server Version: 19.03.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: kata-runtime runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.2.10-v8+
 Operating System: Ubuntu 19.04
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 1.84GiB
 Name: ubuntu
 ID: 2COC:BESL:UDHX:3BYE:K5RD:WHKK:I7BI:7EO3:3HWX:6UZQ:RGYC:LHBE
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 21
  Goroutines: 35
  System Time: 2019-09-10T08:50:35.790140249Z
  EventsListeners: 0
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support

Output of "systemctl show docker":

Type=notify
Restart=always
NotifyAccess=main
RestartUSec=2s
TimeoutStartUSec=infinity
TimeoutStopUSec=infinity
RuntimeMaxUSec=infinity
WatchdogUSec=0
WatchdogTimestampMonotonic=0
RootDirectoryStartOnly=no
RemainAfterExit=no
GuessMainPID=yes
MainPID=3973
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
UID=[not set]
GID=[not set]
NRestarts=0
ExecMainStartTimestamp=Tue 2019-09-10 08:41:08 UTC
ExecMainStartTimestampMonotonic=863762198
ExecMainExitTimestampMonotonic=0
ExecMainPID=3973
ExecMainCode=0
ExecMainStatus=0
ExecStart={ path=/usr/bin/dockerd ; argv[]=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --add-runtime kata-runtime=/usr/local/bin/kata-runtime ; ignore_errors=no ; start_time=[Tue 2019-09-10 08:41:08 UTC] ; stop_time=[n/a] ; pid=3973 ; code=(null) ; status=0/0 }
ExecReload={ path=/bin/kill ; argv[]=/bin/kill -s HUP $MAINPID ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
Slice=system.slice
ControlGroup=/system.slice/docker.service
MemoryCurrent=86310912
CPUUsageNSec=[not set]
TasksCurrent=[not set]
IPIngressBytes=18446744073709551615
IPIngressPackets=18446744073709551615
IPEgressBytes=18446744073709551615
IPEgressPackets=18446744073709551615
Delegate=yes
DelegateControllers=cpu cpuacct io blkio memory devices pids bpf-firewall bpf-devices
CPUAccounting=no
CPUWeight=[not set]
StartupCPUWeight=[not set]
CPUShares=[not set]
StartupCPUShares=[not set]
CPUQuotaPerSecUSec=infinity
IOAccounting=no
IOWeight=[not set]
StartupIOWeight=[not set]
BlockIOAccounting=no
BlockIOWeight=[not set]
StartupBlockIOWeight=[not set]
MemoryAccounting=yes
MemoryMin=0
MemoryLow=0
MemoryHigh=infinity
MemoryMax=infinity
MemorySwapMax=infinity
MemoryLimit=infinity
DevicePolicy=auto
TasksAccounting=yes
TasksMax=infinity
IPAccounting=no
UMask=0022
LimitCPU=infinity
LimitCPUSoft=infinity
LimitFSIZE=infinity
LimitFSIZESoft=infinity
LimitDATA=infinity
LimitDATASoft=infinity
LimitSTACK=infinity
LimitSTACKSoft=8388608
LimitCORE=infinity
LimitCORESoft=infinity
LimitRSS=infinity
LimitRSSSoft=infinity
LimitNOFILE=infinity
LimitNOFILESoft=infinity
LimitAS=infinity
LimitASSoft=infinity
LimitNPROC=infinity
LimitNPROCSoft=infinity
LimitMEMLOCK=67108864
LimitMEMLOCKSoft=67108864
LimitLOCKS=infinity
LimitLOCKSSoft=infinity
LimitSIGPENDING=1613
LimitSIGPENDINGSoft=1613
LimitMSGQUEUE=819200
LimitMSGQUEUESoft=819200
LimitNICE=0
LimitNICESoft=0
LimitRTPRIO=0
LimitRTPRIOSoft=0
LimitRTTIME=infinity
LimitRTTIMESoft=infinity
OOMScoreAdjust=0
Nice=0
IOSchedulingClass=0
IOSchedulingPriority=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardInputData=
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SyslogLevel=6
SyslogFacility=3
LogLevelMax=-1
LogRateLimitIntervalUSec=0
LogRateLimitBurst=0
SecureBits=0
CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock cap_ipc_owner cap_sys_module cap_sys_rawio cap_sys_chroot cap_sys_ptrace cap_sys_pacct cap_sys_admin cap_sys_boot cap_sys_nice cap_sys_resource cap_sys_time cap_sys_tty_config cap_mknod cap_lease cap_audit_write cap_audit_control cap_setfcap cap_mac_override cap_mac_admin cap_syslog cap_wake_alarm cap_block_suspend
AmbientCapabilities=
DynamicUser=no
RemoveIPC=no
MountFlags=
PrivateTmp=no
PrivateDevices=no
ProtectKernelTunables=no
ProtectKernelModules=no
ProtectControlGroups=no
PrivateNetwork=no
PrivateUsers=no
PrivateMounts=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=no
UtmpMode=init
IgnoreSIGPIPE=yes
NoNewPrivileges=no
SystemCallErrorNumber=0
LockPersonality=no
RuntimeDirectoryPreserve=no
RuntimeDirectoryMode=0755
StateDirectoryMode=0755
CacheDirectoryMode=0755
LogsDirectoryMode=0755
ConfigurationDirectoryMode=0755
MemoryDenyWriteExecute=no
RestrictRealtime=no
RestrictNamespaces=no
MountAPIVFS=no
KeyringMode=private
KillMode=process
KillSignal=15
FinalKillSignal=9
SendSIGKILL=yes
SendSIGHUP=no
WatchdogSignal=6
Id=docker.service
Names=docker.service
Requires=system.slice docker.socket sysinit.target
Wants=network-online.target
BindsTo=containerd.service
WantedBy=multi-user.target
ConsistsOf=docker.socket
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=network-online.target sysinit.target docker.socket containerd.service system.slice firewalld.service basic.target systemd-journald.socket
TriggeredBy=docker.socket
Documentation=https://docs.docker.com
Description=Docker Application Container Engine
LoadState=loaded
ActiveState=active
SubState=running
FragmentPath=/lib/systemd/system/docker.service
UnitFileState=enabled
UnitFilePreset=enabled
StateChangeTimestamp=Tue 2019-09-10 08:41:11 UTC
StateChangeTimestampMonotonic=866437946
InactiveExitTimestamp=Tue 2019-09-10 08:41:08 UTC
InactiveExitTimestampMonotonic=863763358
ActiveEnterTimestamp=Tue 2019-09-10 08:41:11 UTC
ActiveEnterTimestampMonotonic=866437946
ActiveExitTimestamp=Tue 2019-09-10 08:41:08 UTC
ActiveExitTimestampMonotonic=863741721
InactiveEnterTimestamp=Tue 2019-09-10 08:41:08 UTC
InactiveEnterTimestampMonotonic=863747571
CanStart=yes
CanStop=yes
CanReload=yes
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnFailureJobMode=replace
IgnoreOnIsolate=no
NeedDaemonReload=no
JobTimeoutUSec=infinity
JobRunningTimeoutUSec=infinity
JobTimeoutAction=none
ConditionResult=yes
AssertResult=yes
ConditionTimestamp=Tue 2019-09-10 08:41:08 UTC
ConditionTimestampMonotonic=863759136
AssertTimestamp=Tue 2019-09-10 08:41:08 UTC
AssertTimestampMonotonic=863759136
Transient=no
Perpetual=no
StartLimitIntervalUSec=1min
StartLimitBurst=3
StartLimitAction=none
FailureAction=none
FailureActionExitStatus=-1
SuccessAction=none
SuccessActionExitStatus=-1
InvocationID=dba538197cb841809c24d1beb51fac54
CollectMode=inactive

No kubectl
No crio
Have containerd

containerd

Output of "containerd --version":

containerd containerd.io 1.2.6 894b81a4b802e4eb2a91d1ce216b8817763c29fb

Output of "systemctl show containerd":

Type=simple
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=1min 30s
TimeoutStopUSec=1min 30s
RuntimeMaxUSec=infinity
WatchdogUSec=0
WatchdogTimestampMonotonic=0
RootDirectoryStartOnly=no
RemainAfterExit=no
GuessMainPID=yes
MainPID=1003
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
UID=[not set]
GID=[not set]
NRestarts=0
ExecMainStartTimestamp=Tue 2019-09-10 08:32:07 UTC
ExecMainStartTimestampMonotonic=322479497
ExecMainExitTimestampMonotonic=0
ExecMainPID=1003
ExecMainCode=0
ExecMainStatus=0
ExecStartPre={ path=/sbin/modprobe ; argv[]=/sbin/modprobe overlay ; ignore_errors=yes ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
ExecStart={ path=/usr/bin/containerd ; argv[]=/usr/bin/containerd ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
Slice=system.slice
ControlGroup=/system.slice/containerd.service
MemoryCurrent=92733440
CPUUsageNSec=[not set]
TasksCurrent=[not set]
IPIngressBytes=18446744073709551615
IPIngressPackets=18446744073709551615
IPEgressBytes=18446744073709551615
IPEgressPackets=18446744073709551615
Delegate=yes
DelegateControllers=cpu cpuacct io blkio memory devices pids bpf-firewall bpf-devices
CPUAccounting=no
CPUWeight=[not set]
StartupCPUWeight=[not set]
CPUShares=[not set]
StartupCPUShares=[not set]
CPUQuotaPerSecUSec=infinity
IOAccounting=no
IOWeight=[not set]
StartupIOWeight=[not set]
BlockIOAccounting=no
BlockIOWeight=[not set]
StartupBlockIOWeight=[not set]
MemoryAccounting=yes
MemoryMin=0
MemoryLow=0
MemoryHigh=infinity
MemoryMax=infinity
MemorySwapMax=infinity
MemoryLimit=infinity
DevicePolicy=auto
TasksAccounting=yes
TasksMax=infinity
IPAccounting=no
UMask=0022
LimitCPU=infinity
LimitCPUSoft=infinity
LimitFSIZE=infinity
LimitFSIZESoft=infinity
LimitDATA=infinity
LimitDATASoft=infinity
LimitSTACK=infinity
LimitSTACKSoft=8388608
LimitCORE=infinity
LimitCORESoft=infinity
LimitRSS=infinity
LimitRSSSoft=infinity
LimitNOFILE=1048576
LimitNOFILESoft=1048576
LimitAS=infinity
LimitASSoft=infinity
LimitNPROC=infinity
LimitNPROCSoft=infinity
LimitMEMLOCK=67108864
LimitMEMLOCKSoft=67108864
LimitLOCKS=infinity
LimitLOCKSSoft=infinity
LimitSIGPENDING=1613
LimitSIGPENDINGSoft=1613
LimitMSGQUEUE=819200
LimitMSGQUEUESoft=819200
LimitNICE=0
LimitNICESoft=0
LimitRTPRIO=0
LimitRTPRIOSoft=0
LimitRTTIME=infinity
LimitRTTIMESoft=infinity
OOMScoreAdjust=0
Nice=0
IOSchedulingClass=0
IOSchedulingPriority=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardInputData=
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SyslogLevel=6
SyslogFacility=3
LogLevelMax=-1
LogRateLimitIntervalUSec=0
LogRateLimitBurst=0
SecureBits=0
CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock cap_ipc_owner cap_sys_module cap_sys_rawio cap_sys_chroot cap_sys_ptrace cap_sys_pacct cap_sys_admin cap_sys_boot cap_sys_nice cap_sys_resource cap_sys_time cap_sys_tty_config cap_mknod cap_lease cap_audit_write cap_audit_control cap_setfcap cap_mac_override cap_mac_admin cap_syslog cap_wake_alarm cap_block_suspend
AmbientCapabilities=
DynamicUser=no
RemoveIPC=no
MountFlags=
PrivateTmp=no
PrivateDevices=no
ProtectKernelTunables=no
ProtectKernelModules=no
ProtectControlGroups=no
PrivateNetwork=no
PrivateUsers=no
PrivateMounts=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=no
UtmpMode=init
IgnoreSIGPIPE=yes
NoNewPrivileges=no
SystemCallErrorNumber=0
LockPersonality=no
RuntimeDirectoryPreserve=no
RuntimeDirectoryMode=0755
StateDirectoryMode=0755
CacheDirectoryMode=0755
LogsDirectoryMode=0755
ConfigurationDirectoryMode=0755
MemoryDenyWriteExecute=no
RestrictRealtime=no
RestrictNamespaces=no
MountAPIVFS=no
KeyringMode=private
KillMode=process
KillSignal=15
FinalKillSignal=9
SendSIGKILL=yes
SendSIGHUP=no
WatchdogSignal=6
Id=containerd.service
Names=containerd.service
Requires=sysinit.target system.slice
WantedBy=multi-user.target
BoundBy=docker.service
Conflicts=shutdown.target
Before=shutdown.target docker.service multi-user.target
After=network.target sysinit.target system.slice systemd-journald.socket basic.target
Documentation=https://containerd.io
Description=containerd container runtime
LoadState=loaded
ActiveState=active
SubState=running
FragmentPath=/lib/systemd/system/containerd.service
UnitFileState=enabled
UnitFilePreset=enabled
StateChangeTimestamp=Tue 2019-09-10 08:32:07 UTC
StateChangeTimestampMonotonic=322479789
InactiveExitTimestamp=Tue 2019-09-10 08:32:07 UTC
InactiveExitTimestampMonotonic=322474060
ActiveEnterTimestamp=Tue 2019-09-10 08:32:07 UTC
ActiveEnterTimestampMonotonic=322479789
ActiveExitTimestamp=Tue 2019-09-10 08:24:55 UTC
ActiveExitTimestampMonotonic=43695663
InactiveEnterTimestamp=Tue 2019-09-10 08:24:55 UTC
InactiveEnterTimestampMonotonic=43695663
CanStart=yes
CanStop=yes
CanReload=no
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnFailureJobMode=replace
IgnoreOnIsolate=no
NeedDaemonReload=no
JobTimeoutUSec=infinity
JobRunningTimeoutUSec=infinity
JobTimeoutAction=none
ConditionResult=yes
AssertResult=yes
ConditionTimestamp=Tue 2019-09-10 08:32:07 UTC
ConditionTimestampMonotonic=322470519
AssertTimestamp=Tue 2019-09-10 08:32:07 UTC
AssertTimestampMonotonic=322470520
Transient=no
Perpetual=no
StartLimitIntervalUSec=10s
StartLimitBurst=5
StartLimitAction=none
FailureAction=none
FailureActionExitStatus=-1
SuccessAction=none
SuccessActionExitStatus=-1
InvocationID=e725f792a03843b5a599287d8d595ff0
CollectMode=inactive

Output of "cat /etc/containerd/config.toml":

disabled_plugins = ["cri"]

#root = "/var/lib/containerd"
#state = "/run/containerd"
#subreaper = true
#oom_score = 0

#[grpc]
#  address = "/run/containerd/containerd.sock"
#  uid = 0
#  gid = 0

#[debug]
#  address = "/run/containerd/debug.sock"
#  uid = 0
#  gid = 0
#  level = "info"

Packages

Have dpkg
Output of "dpkg -l|egrep "(cc-oci-runtimecc-runtimerunv|kata-proxy|kata-runtime|kata-shim|kata-ksm-throttler|kata-containers-image|linux-container|qemu-)"":

/usr/bin/dpkg-query: 1: /usr/bin/dpkg-query: Syntax error: Unterminated quoted string

No rpm


Add support for structured errors

Background

All the Kata components use structured logging. This is extremely useful as it allows the log entries to be split into fields that can be queried. We have a very basic tool that currently validates log entries and can perform basic conversions to other formats for more sophisticated filtering here:

Observations

Although the logs are now very useful, the errors returned by various parts of the system and other packages are less useful as they are not structured. An "error" in go is basically a free-format string.

Added to this, the following idiom can be seen in various places:

err := doSomething()
if err != nil {
    logger().WithError(err).Error("the foo died!")
    return err
}

Or more normally:

err := doSomething()
if err != nil {
    return err
}

The problem with the first snippet is that doSomething() might be calling many levels lower so although the error is logged, the reader of the logs cannot know that the error didn't actually occur here - it occurred maybe ten levels below doSomething().

The problem with the second snippet is that although the error is being returned, it's being passed up to a higher level and is not recording any details of where (file, line, function) the error was first detected.

Idea

Enrich errors with:

  • the logger fields that are active at the time of detecting an error.
  • details of where the error was first detected to simplify debugging.

Advantages

  • Errors provide more precise information on where the problem was first detected.

    This makes problem determination easier.

  • The code doesn't need to be littered with lots of log calls if an error is detected.

  • Test code could be improved.

    Current test code checks either that an error occurred or it didn't. This is very crude and in fact hides issues - what if the test is assuming the error was generated due to a contrived test scenario but in fact was resulting from some other issue (say EPERM)?

    With structured errors, the test code could check for precisely the expected behaviour by considering the fields inside the error.

API

We can introduce a tiny package that provides a single API:

package e

func Log(entry *logrus.Entry) error

That API accepts a logger entry which is assumed to hold an error (hold that thought!) We can then make calls like the following to produce structured errors (or enriched errors):

Description current call new call
Handle existing error return err return e.Log(logger().WithError(err))
Create static error return errrors.New(...) return e.Log(logger().WithField("error", "..."))
Create formatted error return fmt.Errorf(...) return e.Log(logger().WithField("error", fmt.Sprintf(...))

That's a little verbose, but bearable (I think).

Note: an earlier version of the API added a SetLog(logger *logrus.Entry) API, but that approach is flawed (see "Original API Idea" on containers/virtcontainers#657 (comment)).

Example structured errors

This shows a basic example of what an error would look like:

time="2018-03-02T14:40:30.311729832Z" level=error arch=amd64 error="Container not ready or running, impossible to signal the container" error-time="2018-03-02T14:40:30.311705732Z" file="\"/home/james/go/src/github.com/clearcontainers/runtime/vendor/github.com/containers/virtcontainers/container.go\"" function="github.com/clearcontainers/runtime/vendor/github.com/containers/virtcontainers.(*Container).kill" hello=world line=628 name=cc-runtime pid=22469 source=virtcontainers

... and here's the log-parser reformatted version of that line:

- count: 1
  timedelta: 0
  filename: /home/james/tmp/vc.log
  line: 1
  time: !!timestamp 2018-03-02T14:40:30.311729832Z
  pid: 22469
  level: error
  msg: ""
  source: virtcontainers
  name: cc-runtime
  data:
    arch: amd64
    error: Container not ready or running, impossible to signal the container                                                                                                                 
    error-time: "2018-03-02T14:40:30.311705732Z"
    file: '"/home/james/go/src/github.com/clearcontainers/runtime/vendor/github.com/containers/virtcontainers/container.go"'
    function: github.com/clearcontainers/runtime/vendor/github.com/containers/virtcontainers.(*Container).kill
    hello: world
    line: "628"

Notes:

  • We now get two timestamps - one showing the time the error was logged (time) and the other showing the time the error was generated (error-time).
  • The file, line number and function where the error was generated are now logged.
  • The source now correctly shows virtcontainers.

In fact I've changed my test code locally in fact so that rather than adding error-file, erorr-line and error-function, the error contains a single error-backtrace which encodes the full backtrace at the point e.Log() is called.

The complication

The problem is now more about where the calls to e.Log() are placed. There are
hundreds of code locations that return errors, but it doesn't make sense to change all
of them to use e.Log(): if we do that, we'll end up with errors containing multiple sets
of fields. The code handles this fine, but we'll essentially get "too much" detail when
all we actually want is the full stacktrace for the location where the error was first
detected.

In summary:

  • If we generate the structured errors only at the highest level, the additional fields
    (stacktrace and logger fields) won't be very useful.

  • If we generate the structured errors at all levels (the "search'n'replace" approach to
    adding e.Log() calls), we'll end up with overly "large" errors (errors with duplicate
    fields). Although the code supports creating a structured error from an existing
    structured error, it results in larger and larger error objects which is going to make
    the returned error less clear. It could also have a performance impact.

The solution therefore would seem to be to only create structured errors at the lowest
possible layers:

  • In pseudo-leaf functions

    Functions that do not call any functions in "lower" virtcontainers packages).

  • In the pkg/* packages

    Problem: these don't have access to a logger, so the next-best approach is...

  • At package boundaries

    In functions where virtcontainers calls code from other packages.

  • At plugin boundaries (see #667).

Layers

virtcontainers is structured at the file level, something like the following:

Level files
high api.go, pkg/oci.go
pod.go, container.go
hypervisor.go, agent.go, shim.go, proxy.go
medium qemu*.go, agent_*.go, shim_*.go, proxy_*.go
asset.go, bridge.go, cni.go, cnm.go, device.go, filesystem.go, hook.go, mount.go, network.go, syscall.go, utils.go
low pkg/*/*.go (excluding pkg/oci.go)

Application approaches

Although the code can be updated manually to introduce the structured error API call:

  • Adding the API to a subset of code locations (a subset of functions in a subset of
    files) is going to be error-prone.

  • It will also be error-prone to update the API calls when code when changes are required.

The best approach might be to find/write a tool to identify such code locations and error
if there is no call to e.Log().

What might help is if we split the main package into sub-packages as suggested on #631.

See also

Originally raised as containers/virtcontainers#656.

tracking issue for github label improvements

We need to make better use of GitHub labels. This issue is for tracking required repo, infrastructure and process changes.

See the main PR at: kata-containers/tests#1466.

TODO

More tasks to follow (using probot maybe?)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.