kata-containers / runtime

Kata Containers version 1.x runtime (for version 2.x see https://github.com/kata-containers/kata-containers).
https://katacontainers.io/
Apache License 2.0
2.1k stars 376 forks source link

Unable to start docker in docker with virtio-fs #1888

Closed awprice closed 3 years ago

awprice commented 5 years ago

Description of problem

We are having issues starting docker in docker containers when using virtio-fs for sharing files.

We are using the following branch: https://github.com/kata-containers/runtime/tree/stable-1.8 with https://github.com/kata-containers/runtime/pull/1882 merged in manually.

Expected result

The docker container to start up without issues.

Actual result

When running the following command to start a docker container in docker, the following error is outputted and the container does not start:

$ kubectl exec -it -c docker test sh
# docker run -it --rm ubuntu bash
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
5b7339215d1d: Pull complete 
14ca88e9f672: Pull complete 
a31c3b1caad4: Pull complete 
b054a26005b7: Pull complete 
Digest: sha256:9b1702dcfe32c873a770a32cfd306dd7fc1c4fd134adfb783db68defc8894b3c
Status: Downloaded newer image for ubuntu:latest
docker: Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/ea8c67204094468d6aab0540d5de4e4cfb88fb073418d12d03767df7e7ee6815-init/merged: invalid argument.
See 'docker run --help'.

We can see the following error in the docker in docker daemon logs:

time="2019-07-18T04:11:30.749699935Z" level=error msg="error unmounting /var/lib/docker/overlay2/ea8c67204094468d6aab0540d5de4e4cfb88fb073418d12d03767df7e7ee6815-init/merged: invalid argument" storage-driver=overlay2
time="2019-07-18T04:11:30.750986399Z" level=error msg="Handler for POST /v1.39/containers/create returned error: error creating overlay mount to /var/lib/docker/overlay2/ea8c67204094468d6aab0540d5de4e4cfb88fb073418d12d03767df7e7ee6815-init/merged: invalid argument"

The following pod spec can be used to replicate:

apiVersion: v1
kind: Pod
metadata:
  name: test
  namespace: default
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  containers:
    - name: docker
      image: docker:stable-dind
      imagePullPolicy: Always
      command:
        - sleep
        - "3600"
      env:
        - name: DOCKER_HOST
          value: tcp://localhost:2375
    - name: dind
      image: docker:18.09.8-dind
      imagePullPolicy: Always
      securityContext:
        privileged: true
Show kata-collect-data.sh details

# Meta details Running `kata-collect-data.sh` version `1.8.0-rc0 (commit 43f2680e4c45f673765958b6b0566e514f217f6e)` at `2019-07-19.06:20:44.741140811+0000`. --- Runtime is `/opt/kata/bin/kata-runtime`. # `kata-env` Output of "`/opt/kata/bin/kata-runtime kata-env`": ```toml [Meta] Version = "1.0.23" [Runtime] Debug = false Trace = false DisableGuestSeccomp = true DisableNewNetNs = false Path = "/opt/kata/bin/kata-runtime" [Runtime.Version] Semver = "1.8.0" Commit = "31b8cb3fbc7b1de9c94201aed7c54ddb73e97587" OCI = "1.0.1-dev" [Runtime.Config] Path = "/etc/kata-containers/configuration.toml" [Hypervisor] MachineType = "virt" Version = "NEMU (like QEMU) version 4.0.0 (kata-static)\nCopyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers" Path = "/opt/kata/bin/nemu-system-x86_64" BlockDeviceDriver = "virtio-scsi" EntropySource = "/dev/urandom" Msize9p = 8192 MemorySlots = 10 Debug = false UseVSock = false SharedFS = "virtio-fs" [Image] Path = "/opt/kata/share/kata-containers/kata-containers-ubuntu-console-1.7.2-913c8fd.img" [Kernel] Path = "/opt/kata/share/kata-containers/vmlinuz-4.19.52-44" Parameters = "init=/usr/lib/systemd/systemd systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket" [Initrd] Path = "" [Proxy] Type = "kataProxy" Version = "kata-proxy version 1.8.0-rc0-ff08b9676ace92047d6ed6a5b96cde559c0963f4" Path = "/opt/kata/libexec/kata-containers/kata-proxy" Debug = false [Shim] Type = "kataShim" Version = "kata-shim version 1.8.0-rc0-9f25c0dde30937121783cc493e063808cc0cc0ad" Path = "/opt/kata/libexec/kata-containers/kata-shim" Debug = false [Agent] Type = "kata" Debug = false Trace = false TraceMode = "" TraceType = "" [Host] Kernel = "4.19.50-coreos-r1" Architecture = "amd64" VMContainerCapable = true SupportVSocks = true [Host.Distro] Name = "Container Linux by CoreOS" Version = "2135.4.0" [Host.CPU] Vendor = "GenuineIntel" Model = "Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz" [Netmon] Version = "kata-netmon version 1.8.0-rc0" Path = "/opt/kata/libexec/kata-containers/kata-netmon" Debug = false 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"`": ```toml # Copyright (c) 2019 Intel Corporation # # SPDX-License-Identifier: Apache-2.0 # # XXX: WARNING: this file is auto-generated. # XXX: # XXX: Source file: "cli/config/configuration-nemu.toml.in" # XXX: Project: # XXX: Name: Kata Containers # XXX: Type: kata # nemu utilizes the 'qemu' hypervisor template type, since it closely matches qemu [hypervisor.qemu] path = "/opt/kata/bin/nemu-system-x86_64" kernel = "/opt/kata/share/kata-containers/vmlinuz.container" image = "/opt/kata/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 = "/opt/kata/share/kata-nemu/OVMF.fd" # 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 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 # Shared file system type: # - virtio-fs (default) # - virtio-9p shared_fs = "virtio-fs" # Path to vhost-user-fs daemon. virtio_fs_daemon = "/opt/kata/bin/virtiofsd-x86_64" # Default size of DAX cache in MiB virtio_fs_cache_size = 2048 # 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 = "auto" # 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 = false # 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 (no proxy is started). # Default true #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 = "/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] # 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" [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="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 # 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 "/opt/kata/share/defaults/kata-containers/configuration.toml"`": ```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 # Shared file system type: # - virtio-9p (default) # - virtio-fs shared_fs = "virtio-9p" # Path to vhost-user-fs daemon. virtio_fs_daemon = "/opt/kata/bin/virtiofsd-x86_64" # Default size of DAX cache in MiB virtio_fs_cache_size = 1024 # 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 = "/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] # 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" [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="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 # 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=[] ``` Config file `/usr/share/defaults/kata-containers/configuration.toml` not found --- # KSM throttler ## version Output of "` --version`": ``` ./kata-collect-data.sh: line 178: --version: command not found ``` ## systemd service # Image details ```yaml --- osbuilder: url: "https://github.com/kata-containers/osbuilder" version: "unknown" rootfs-creation-time: "2019-07-05T02:08:07.059974670+0000Z" description: "osbuilder rootfs" file-format-version: "0.0.2" architecture: "x86_64" base-distro: name: "bionic" version: "18.04" packages: default: - "systemd,iptables,init,chrony,fuse,bash" extra: - "bash" - "fuse" agent: url: "https://github.com/kata-containers/agent" name: "kata-agent" version: "1.7.2-152276729a0b9027fbbdac34ccc27587bba77025" 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. ## Throttler logs No recent throttler problems found in system journal. --- # Container manager details Have `docker` ## Docker Output of "`docker version`": ``` Client: Version: 18.06.3-ce API version: 1.38 Go version: go1.10.8 Git commit: d7080c1 Built: Tue Feb 19 23:07:53 2019 OS/Arch: linux/amd64 Experimental: false Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? ``` Output of "`docker info`": ``` Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? ``` Output of "`systemctl show docker`": ``` 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=0 ControlPID=0 FileDescriptorStoreMax=0 NFileDescriptorStore=0 StatusErrno=0 Result=success UID=[not set] GID=[not set] NRestarts=0 ExecMainStartTimestampMonotonic=0 ExecMainExitTimestampMonotonic=0 ExecMainPID=0 ExecMainCode=0 ExecMainStatus=0 MemoryCurrent=[not set] CPUUsageNSec=[not set] TasksCurrent=[not set] IPIngressBytes=18446744073709551615 IPIngressPackets=18446744073709551615 IPEgressBytes=18446744073709551615 IPEgressPackets=18446744073709551615 Delegate=no 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=73727 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=1073741816 LimitNOFILESoft=1073741816 LimitAS=infinity LimitASSoft=infinity LimitNPROC=2063281 LimitNPROCSoft=2063281 LimitMEMLOCK=67108864 LimitMEMLOCKSoft=67108864 LimitLOCKS=infinity LimitLOCKSSoft=infinity LimitSIGPENDING=2063281 LimitSIGPENDINGSoft=2063281 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=inherit 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=control-group KillSignal=15 FinalKillSignal=9 SendSIGKILL=yes SendSIGHUP=no WatchdogSignal=6 Id=docker.service Names=docker.service WantedBy=kitt-init.service ConsistsOf=docker.socket Before=kitt-init.service After=docker.socket TriggeredBy=docker.socket Description=docker.service LoadState=masked ActiveState=inactive SubState=dead FragmentPath=/dev/null UnitFileState=masked StateChangeTimestampMonotonic=0 InactiveExitTimestampMonotonic=0 ActiveEnterTimestampMonotonic=0 ActiveExitTimestampMonotonic=0 InactiveEnterTimestampMonotonic=0 CanStart=no 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=no AssertResult=no ConditionTimestampMonotonic=0 AssertTimestampMonotonic=0 LoadError=org.freedesktop.systemd1.UnitMasked "Unit docker.service is masked." Transient=no Perpetual=no StartLimitIntervalUSec=10s StartLimitBurst=5 StartLimitAction=none FailureAction=none FailureActionExitStatus=-1 SuccessAction=none SuccessActionExitStatus=-1 CollectMode=inactive ``` No `kubectl` No `crio` Have `containerd` ## containerd Output of "`containerd --version`": ``` containerd github.com/containerd/containerd v1.2.0-575-gb99a66c2 b99a66c267d04740628634d7d038f9ce1753b339 ``` Output of "`systemctl show containerd`": ``` Type=simple Restart=always NotifyAccess=none RestartUSec=5s TimeoutStartUSec=1min 30s TimeoutStopUSec=1min 30s RuntimeMaxUSec=infinity WatchdogUSec=0 WatchdogTimestampMonotonic=0 RootDirectoryStartOnly=no RemainAfterExit=no GuessMainPID=yes MainPID=31077 ControlPID=0 FileDescriptorStoreMax=0 NFileDescriptorStore=0 StatusErrno=0 Result=success UID=[not set] GID=[not set] NRestarts=0 ExecMainStartTimestamp=Fri 2019-07-19 04:59:42 UTC ExecMainStartTimestampMonotonic=1810428852 ExecMainExitTimestampMonotonic=0 ExecMainPID=31077 ExecMainCode=0 ExecMainStatus=0 ExecStartPre={ path=/sbin/modprobe ; argv[]=/sbin/modprobe overlay ; ignore_errors=no ; start_time=[Fri 2019-07-19 04:59:40 UTC] ; stop_time=[Fri 2019-07-19 04:59:40 UTC] ; pid=30996 ; code=exited ; status=0 } ExecStartPre={ path=/opt/bin/containerd-init.sh ; argv[]=/opt/bin/containerd-init.sh ; ignore_errors=no ; start_time=[Fri 2019-07-19 04:59:40 UTC] ; stop_time=[Fri 2019-07-19 04:59:42 UTC] ; pid=30999 ; code=exited ; status=0 } ExecStart={ path=/opt/containerd/bin/containerd ; argv[]=/opt/containerd/bin/containerd --log-level=info --config=/etc/containerd/config.toml ; ignore_errors=no ; start_time=[Fri 2019-07-19 04:59:42 UTC] ; stop_time=[n/a] ; pid=31077 ; code=(null) ; status=0/0 } Slice=system.slice ControlGroup=/system.slice/containerd.service MemoryCurrent=10033016832 CPUUsageNSec=[not set] TasksCurrent=335 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=73727 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=65536 LimitMEMLOCKSoft=65536 LimitLOCKS=infinity LimitLOCKSSoft=infinity LimitSIGPENDING=2063281 LimitSIGPENDINGSoft=2063281 LimitMSGQUEUE=819200 LimitMSGQUEUESoft=819200 LimitNICE=0 LimitNICESoft=0 LimitRTPRIO=0 LimitRTPRIOSoft=0 LimitRTTIME=infinity LimitRTTIMESoft=infinity OOMScoreAdjust=-999 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 Conflicts=shutdown.target Before=multi-user.target shutdown.target After=system.slice containerd-devicemapper-init.service sysinit.target basic.target systemd-journald.socket kata-init.service Documentation=https://containerd.io Description=containerd container runtime LoadState=loaded ActiveState=active SubState=running FragmentPath=/etc/systemd/system/containerd.service UnitFileState=enabled UnitFilePreset=enabled StateChangeTimestamp=Fri 2019-07-19 04:59:42 UTC StateChangeTimestampMonotonic=1810428909 InactiveExitTimestamp=Fri 2019-07-19 04:59:40 UTC InactiveExitTimestampMonotonic=1808328354 ActiveEnterTimestamp=Fri 2019-07-19 04:59:42 UTC ActiveEnterTimestampMonotonic=1810428909 ActiveExitTimestamp=Fri 2019-07-19 04:59:40 UTC ActiveExitTimestampMonotonic=1808318004 InactiveEnterTimestamp=Fri 2019-07-19 04:59:40 UTC InactiveEnterTimestampMonotonic=1808325906 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=Fri 2019-07-19 04:59:40 UTC ConditionTimestampMonotonic=1808326684 AssertTimestamp=Fri 2019-07-19 04:59:40 UTC AssertTimestampMonotonic=1808326684 Transient=no Perpetual=no StartLimitIntervalUSec=10s StartLimitBurst=5 StartLimitAction=none FailureAction=none FailureActionExitStatus=-1 SuccessAction=none SuccessActionExitStatus=-1 InvocationID=753ef34855474477a741c9fe1f3af593 CollectMode=inactive ``` Output of "`cat /etc/containerd/config.toml`": ``` [grpc] address = "/run/containerd/containerd.sock" uid = 0 gid = 0 [plugins] [plugins.devmapper] pool_name = "containerd-thinpool" base_image_size = "32GB" [plugins.cri.containerd] snapshotter = "overlayfs" [plugins.cri.containerd.default_runtime] runtime_type = "io.containerd.runtime.v1.linux" runtime_engine = "/usr/bin/runc" runtime_root = "" [plugins.cri.containerd.untrusted_workload_runtime] runtime_type = "io.containerd.kata.v2" [plugins.cri] max_container_log_line_size = 262144 [plugins.linux] shim = "/opt/containerd/bin/containerd-shim" runtime = "runc" [plugins.cri.registry] [plugins.cri.registry.mirrors] [plugins.cri.registry.mirrors."docker.io"] endpoint = [] ``` --- # Packages No `dpkg` No `rpm` ---

egernst commented 5 years ago

/cc @ganeshmaharaj @amshinde @dagrh

ganeshmaharaj commented 5 years ago

testing this now. Will add more stuff on what i find.

ganeshmaharaj commented 5 years ago

This seems to be what i am getting from the journal logs.

ul 22 23:41:05 f-03 kubelet[5200]: E0722 23:41:05.720783    5200 pod_workers.go:190] Error syncing pod 54abcdc0-b47a-4ee7-b856-785463fc1513 ("test_default(54abcdc0-b47a-4ee7-b856-785463fc1513)"), skipping: failed to "CreatePodSandbox" for "test_default(54abcdc0-b47a-4e
e7-b856-785463fc1513)" with CreatePodSandboxError: "CreatePodSandbox for pod \"test_default(54abcdc0-b47a-4ee7-b856-785463fc1513)\" failed: rpc error: code = Unknown desc = failed to get sandbox runtime: no runtime for \"untrusted\" is configured"
Jul 22 23:41:07 f-03 containerd[7834]: time="2019-07-22T23:41:07.375109947-07:00" level=error msg="UpdateContainerResources for "05f5223203d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353" failed" error="failed to update resources: failed to update resources: runc
 did not terminate sucessfully: failed to write a *:* rwm to devices.allow: write /sys/fs/cgroup/devices/kubepods/besteffort/podf6ffdf29-95dd-4c4d-b18d-a11c39f169ce/05f5223203d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353/devices.allow: invalid argument
Jul 22 23:41:07 f-03 kubelet[5200]: E0722 23:41:07.375492    5200 remote_runtime.go:321] UpdateContainerResources "05f5223203d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353" from runtime service failed: rpc error: code = Unknown desc = failed to update resources:
 failed to update resources: runc did not terminate sucessfully: failed to write a *:* rwm to devices.allow: write /sys/fs/cgroup/devices/kubepods/besteffort/podf6ffdf29-95dd-4c4d-b18d-a11c39f169ce/05f5223203d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353/devices
.allow: invalid argument
Jul 22 23:41:07 f-03 kubelet[5200]: E0722 23:41:07.375562    5200 cpu_manager.go:183] [cpumanager] AddContainer error: rpc error: code = Unknown desc = failed to update resources: failed to update resources: runc did not terminate sucessfully: failed to write a *:* rwm
to devices.allow: write /sys/fs/cgroup/devices/kubepods/besteffort/podf6ffdf29-95dd-4c4d-b18d-a11c39f169ce/05f5223203d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353/devices.allow: invalid argument
Jul 22 23:41:07 f-03 kubelet[5200]: E0722 23:41:07.375604    5200 cpu_manager.go:252] [cpumanager] reconcileState: failed to add container (pod: kube-proxy-vmz9g, container: kube-proxy, container id: 05f5223203d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353, erro
r: rpc error: code = Unknown desc = failed to update resources: failed to update resources: runc did not terminate sucessfully: failed to write a *:* rwm to devices.allow: write /sys/fs/cgroup/devices/kubepods/besteffort/podf6ffdf29-95dd-4c4d-b18d-a11c39f169ce/05f522320
3d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353/devices.allow: invalid argument
Jul 22 23:41:17 f-03 containerd[7834]: time="2019-07-22T23:41:17.817230515-07:00" level=error msg="UpdateContainerResources for "05f5223203d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353" failed" error="failed to update resources: failed to update resources: runc
 did not terminate sucessfully: failed to write a *:* rwm to devices.allow: write /sys/fs/cgroup/devices/kubepods/besteffort/podf6ffdf29-95dd-4c4d-b18d-a11c39f169ce/05f5223203d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353/devices.allow: invalid argument
Jul 22 23:41:17 f-03 kubelet[5200]: E0722 23:41:17.817558    5200 remote_runtime.go:321] UpdateContainerResources "05f5223203d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353" from runtime service failed: rpc error: code = Unknown desc = failed to update resources:
 failed to update resources: runc did not terminate sucessfully: failed to write a *:* rwm to devices.allow: write /sys/fs/cgroup/devices/kubepods/besteffort/podf6ffdf29-95dd-4c4d-b18d-a11c39f169ce/05f5223203d3e65a9fd7e4941be31a51e0f71ec18c9415e71a984e962dc6a353/devices
.allow: invalid argument
ganeshmaharaj commented 5 years ago

Chasing this down and with some googling, it lands me at https://github.com/moby/moby/issues/35476#issuecomment-344067052 for an issue with nfs https://github.com/moby/moby/issues/35476. Could this be the reason @dagrh ?

ganeshmaharaj commented 5 years ago

/cc @rhvgoyal does virtiofs support trusted extended attributes. seems like overlay2 depends on that and the symptoms (previous issues) are pointing to that.

rhvgoyal commented 5 years ago

So this is the case of virtio-fs on top of overlayfs? Here overlayfs mount failed with -EINVAL. I am not sure why it failed. Can you please search journal for any overlayfs messages. Other messages you have pasted from journal don't seem related to this mount failure.

ganeshmaharaj commented 5 years ago

@rhvgoyal this is the case of overlay2 on top of virtiofs not the other way around. from the journal logs there was not much other than this.

Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.510595233-07:00" level=debug msg="   unique: 51466, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.510006869-07:00" level=debug msg="   unique: 51465, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.509519287-07:00" level=debug msg="   unique: 51464, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.509114626-07:00" level=debug msg="   unique: 51463, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.500355184-07:00" level=debug msg="reading guest console" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd sandbox=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtcontainers subsystem=kata_agent vmconsole="time=\"2019-07-23T07:09:27.444713239Z\" level=debug msg=\"request end\" debug_console=false duration=42.849886616s name=kata-agent pid=81 request=/grpc.AgentService/ReadStderr resp=\"data:\\\"time=\\\\\\\"2019-07-23T07:09:27.443701120Z\\\\\\\" level=error msg=\\\\\\\"error unmounting /var/lib/docker/overlay2/b25781382ea5d7a1d252e487c64681f3a709c25cc122a6b40f8b95958bb6ede8-init/merged: invalid argument\\\\\\\" storage-driver=overlay2\\\\n\\\" \" sandbox=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=agent"
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.499393322-07:00" level=debug msg="   unique: 51457, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.499162749-07:00" level=debug msg="   unique: 51456, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.498937345-07:00" level=debug msg="   unique: 51455, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.485205995-07:00" level=debug msg="   unique: 51444, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.482138894-07:00" level=debug msg="   unique: 51434, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.48197557-07:00" level=debug msg="   unique: 51433, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.479615497-07:00" level=debug msg="   unique: 51426, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.478872079-07:00" level=debug msg="   unique: 51424, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
Jul 23 00:09:27 f-03 kata[9623]: time="2019-07-23T00:09:27.477411014-07:00" level=debug msg="   unique: 51421, error: -2 (No such file or directory), outsize: 16" ID=a58a251b239861ab72e3d01d526525da540d3a3b2240a2c3204a288172f523cd source=virtiofsd subsystem=qemu
awprice commented 5 years ago

Not sure if this has been commented yet, but I found this in the kernel logs inside the guest when starting the docker container:

[  175.178778] overlayfs: filesystem on '/var/lib/docker/overlay2/f20e882d90c6556223ca3bd8a5c7a2831b7d4c2b91a6c19a482fae2390813da1-init/diff' not supported as upperdir
awprice commented 5 years ago

Here's another method to replicate that doesn't involve Docker, which might make it a bit more simpler to debug:

Pod:

apiVersion: v1
kind: Pod
metadata:
  name: test
  namespace: default
  annotations:
    io.kubernetes.cri.untrusted-workload: "true"
spec:
  containers:
    - image: ubuntu:18.04
      imagePullPolicy: Always
      name: test
      command:
        - sleep
        - "3600"
      securityContext:
        privileged: true

Steps:

$ kubectl exec -it test bash
# mkdir /lower /upper /work /merged
# mount -t overlay overlay -o lowerdir=/lower,upperdir=/upper,workdir=/work /merged
mount: /merged: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.

Error from dmesg:

[   39.245684] overlayfs: filesystem on '/upper' not supported as upperdir
rhvgoyal commented 5 years ago

Ok, following check in overlayfs fails.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/overlayfs/super.c#n753

fuse does define ->d_revalidate to make sure after a certain period of timeout, attrs are refereshed from host.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/fuse/dir.c#n259

So this case is similar to nfs. Overlayfs does not support nfs as upper dir. And it does not support virtio-fs as upper dir. I think virtio-fs as lower dir might work though.

awprice commented 5 years ago

@rhvgoyal Yep, found this in the overlayfs docs:

The upper filesystem will normally be writable and if it is it must support the creation of trusted.* extended attributes, and must provide valid d_type in readdir responses, so NFS is not suitable.

From https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt

@rhvgoyal Is virtio-fs ever going to be able to support overlayfs? It is quite an important feature for us to be able to configure overlayfs mounts and run docker inside Kata.

coreyjohnston commented 5 years ago

@egernst - Did you have a chance to talk to the virtiofs team about this following our call last week? Curious to understand if virtiofs will ever be able to support the extended file attributes that overlay requires.

rhvgoyal commented 5 years ago

So what's this use case? Docker is running both on host as well as inside VM? How does fs stack look like, xfs/ext4 --> overlayfs --> virtio-fs --->overlayfs (inside VM)?

Talked to Miklos about lifting restriction in overlayfs (upper can't be remote fs) and he seemed to be open to idea of lifting it and experiment how do things go.

rhvgoyal commented 5 years ago

cc @rhatdan

rhvgoyal commented 5 years ago

How does docker in docker use case work as of now without virtio-fs. Dan mentioned that overlay on top of overlay is not allowed. So are you using devicemapper graph driver on host and overlayfs in guest/container to avoid that limitation?

egernst commented 5 years ago

How does docker in docker use case work as of now without virtio-fs. Dan mentioned that overlay on top of overlay is not allowed. So are you using devicemapper graph driver on host and overlayfs

Devicemapper is what we are suggesting as the storage driver on the host @rhvgoyal. @awprice can you share

You can quickly play with dind as follows or following the pod example @awprice provided :

docker run -it --privileged docker:18.06.1-ce-dind sh

You can then start dockerd and start going forward with running (nested) containers.

rhatdan commented 5 years ago

We can support this in podman and buildah using the fuse-overlayfs driver.

awprice commented 5 years ago

@rhvgoyal Yep, currently we use devicemapper as the snapshotter in containerd (i.e. on the host) and then overlayfs in the guest as the current solution. But if we switch solely to virtio-fs for the rootfs and sharing, overlayfs doesn't function.

xfs/ext4 --> overlayfs --> virtio-fs --->overlayfs looks correct to me.

The use case for running docker in docker within a Kata container is to be able to give customers the ability to build and run docker containers that could potentially contain untrusted code in an isolated environment.

Unfortunately, the above requires overlayfs to work.

egernst commented 4 years ago

@rhvgoyal @rhatdan -- Is it feasible for virtio-fs to implement support for trusted extended attributes (and/or valid d_type in readdir responses)? Is this just a gap in implementation today, or is there a specific reason this is not supported?

Or, can you clarify potential next steps here?

Talked to Miklos about lifting restriction in overlayfs (upper can't be remote fs) and he seemed to be open to idea of lifting it and experiment how do things go.

rhvgoyal commented 4 years ago

I think we will have to figure out if overlayfs can support an upper directory on nfs/virtio-fs and get rid of check on d_type during mount. Getting rid of check is trivial but it will probably break other things. I can't remember off the top of my head that what exactly are the reasons for not supporting NFS as upper. Miklos Szeredi might be able to explain this in detail. I will suggest sending him an email.

rhvgoyal commented 4 years ago

Miklos posted patches upstream for review to support overlayfs on top of virtiofs.

https://lwn.net/ml/linux-fsdevel/20200131115004.17410-1-mszeredi@redhat.com/

atlas-comstock commented 4 years ago

Any plan to fix this issue?

dagrh commented 4 years ago

Maybe it's worth backporting the patchset mentioned in @rhvgoyal's comment into the Kata guest kernel.

amshinde commented 4 years ago

@dagrh Yes, I think we should add that patch to the guest kernel used for virtio-fs. We need an update to a newer kernel as is so that https://github.com/kata-containers/runtime/pull/2463 can be unblocked as well. @dagrh @rhvgoyal Can we add this to https://gitlab.com/virtio-fs/linux/?

dadux commented 4 years ago

Hi @rhvgoyal ! I saw that you merged the overlayfs patches in https://gitlab.com/virtio-fs/linux/ a few days ago and decided to give it a try.

Using @awprice command to test the mount

# mkdir /lower /upper /work /merged
# mount -t overlay overlay -o lowerdir=/lower,upperdir=/upper,workdir=/work /merged

I now get the following errors :

[   41.024409] overlayfs: upper fs does not support tmpfile.
[   41.024789] overlayfs: upper fs does not support RENAME_WHITEOUT.
[   41.024813] overlayfs: upper fs does not support xattr, falling back to index=off and metacopy=off.
[   41.024813] overlayfs: upper fs missing required features

So I went rogue and commented out that check in the kernel https://gitlab.com/virtio-fs/linux/-/blob/virtio-fs-dev/fs/overlayfs/super.c#L1202 , just to see if it was working.

I was able to successfully mount, and even run docker containers on top of virtiofs !

/ # mount
kataShared on / type virtiofs (rw,relatime,dax)
...

/ # docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                            NAMES
4729cbbe583e        nginx               "nginx -g 'daemon of…"   48 seconds ago      Up 48 seconds       80/tcp, 0.0.0.0:8080->8080/tcp   nostalgic_germain

That's great progress 🎉

So what works remain to support RENAME_WHITEOUT , and tmpfile ?

dadux commented 4 years ago

Also, when running virtiofsd with the -o xattr , directories are mounted ReadOnly ? What am I missing ?

/ # mkdir /lower /upper /work /merged
/ # mount -t overlay overlay -o lowerdir=/lower,upperdir=/upper,workdir=/work /merged
/ # touch /merged/test42
touch: /merged/test42: Read-only file system

# mount | grep overlay
overlay on /merged type overlay (ro,relatime,lowerdir=/lower,upperdir=/upper,workdir=/work,index=off)
dagrh commented 4 years ago

Hi Dadux, Does your virtiofsd have the commit bdfd66788349acc43cd3f1298718ad491663cfcc in from upstream qemu/virtiofsd - 'virtiofsd: Fix xattr operations' - I know that was supposed to fix a problem on directories, whether it's the problem you're hitting I don't know.

rhvgoyal commented 4 years ago

@dadux You need to use virtio-fs-dev branch. That has the latest code.

https://gitlab.com/virtio-fs/linux/-/tree/virtio-fs-dev

Also make sure virtiofsd is running with "-o xattr" option enabled.

rhvgoyal commented 4 years ago

@dadux I just tested virtio-fs-dev branch and I am able to mount overlayfs on top of virtiofs without any issues. Only warning I get during mount time is "overlayfs: upper fs does not support tmpfile". You can ignore that warning as overlayfs will work even without tmpfile support from underlying fs.

dadux commented 4 years ago

Yes I am building the kernel from the latest virtio-fs-dev.

Are you using qemu from the virtio-fs-dev branch too ?

I've tried building it from the kata packaging repo without success. Is there a binary somewhere I can pull to try ?

[edit] Got it working finally, needed to build qemu too !

skaegi commented 3 years ago

We've been working with dind on top of virtiofs for four or so months and at this point understand some of the main issues and can share. Our primary use-case is for Kubernetes native CI with a pod lasting really no longer than a few hours but also for things like providing a remote shell which is actually not all that different.

We use the 1.12.x kata runtime and use kata packaging to build/package our own kernel (5.9.x but will stick with the 5.10.x LTS kernel in a month or so) and qemu (5.1.x + recent patches) but I think most of what we've learned is applicable to the standard Kata release as well as upcoming releases ... and yes we build kata, the kernel, qemu, etc. inside of kata.

As many have found, you can run dind with virtiofs however... unless you know what you're doing it's going to use "vfs" instead of "overlay" which is a non-starter for performance and stability reasons. With help from several of the RHers above we bumped to a standard 5.7.x kernel and qemu 5.x with additional virtio_fs config and have had some success with caveats.

For virtio_fs config we use...

# Anxiously await DAX support in kernel 5.10 and qemu
virtio_fs_cache_size = 0

# we absolutely need xattr and sys_admin cap
# allow_direct_io just seems sensible but is not required
# we had been using -o writeback which improved performance however users were reporting problems so removed it
virtio_fs_extra_args = ["-o", "xattr", "-o", "modcaps=+sys_admin", "-o", "allow_direct_io"]

# "auto" is the best balance for us. ("none" does not allow most containers to start, "always" does not work with downward api)
virtio_fs_cache = "auto"

One thing we've figured out (again with help from RHers above) is that to create an overlayfs in virtiofs your bottom layer must not also be overlay -- (e.g. it needs to be ext4, xfs, etc). In our environment (IBM Cloud Kubernetes Service) what we found is that both the root fs and emptyDir volumes are unfortunately backed by overlay. Image volumes (example) do work though, as will local, hostPath, and most other mounted PV types. So long as you keep things simple a docker:dind like the following should work...

spec:
  containers:
    - name: docker
      image: docker:dind
      securityContext:
        privileged: true

If /var/lib/docker matches the above criteria and you launch dockerd when you look at docker info you'll see something like...

 Storage Driver: overlay2
  Backing Filesystem: <unknown>

Hurray (sort of)! This works quite well and we hope is the correct future approach but currently the performance is mediocre and we have had many cases where we get metadata synchronization problems similar to issues building on NFS. npm install and golang builds inside a Dockerfile generate problems fairly consistently.

So... we're down to the hacks we use in the interim... We can mount a Kubernetes block device, format, and mount it at /var/lib/docker and this works great but is a bit complex. Currently the approach we promote is as follows...

spec:
  containers:
    - name: docker
      image: docker:dind
      command: ["sh", "-c"]
      args:
      - if [[ $(df -PT /var/lib/docker | awk 'NR==2 {print $2}') == virtiofs ]]; then 
          apk add e2fsprogs && 
          truncate -s 20G /tmp/disk.img && 
          mkfs.ext4 /tmp/disk.img && 
          mount /tmp/disk.img /var/lib/docker; fi &&
        dockerd-entrypoint.sh;
      securityContext:
        privileged: true

Basically if we detect virtiofs at /var/lib/docker create and mount a loop device in its place.

We've expanded this approach for buildkit and other tools. It's not pretty but relatively painless to integrate and at least so far seems stable and performs well. I would definitely appreciate feedback and maybe thoughts on how to improve on it. I feel this is a bit of a stop gap approach but at least wanted to share our experience here as it might help unblock adoption by other teams.

haslersn commented 3 years ago

Why is this closed / Done? Was there some update that makes overlay on virtio-fs work?