This repository has been archived by the owner on May 12, 2021. It is now read-only.
Resource governance doesn't work with kata 1.6.0 #1521
Assignees
Comments
devimc
pushed a commit
to devimc/kata-runtime
that referenced
this issue
Apr 12, 2019
Don't set a default CPU constraint if period and quota are not specified, that way the container will inherit the CPU constraint from its parent. Container creation won't fail if the parent CPU constraint is smaller than the default number of vCPUs. fixes kata-containers#1521 Signed-off-by: Julio Montes <[email protected]>
devimc
pushed a commit
to devimc/kata-runtime
that referenced
this issue
Apr 12, 2019
Don't set a default CPU constraint if period and quota are not specified, that way the container will inherit the CPU constraint from its parent. Container creation won't fail if the parent CPU constraint is smaller than the default number of vCPUs. fixes kata-containers#1521 Signed-off-by: Julio Montes <[email protected]>
devimc
pushed a commit
to devimc/kata-runtime
that referenced
this issue
Apr 12, 2019
Don't set a default CPU constraint if period and quota are not specified, that way the container will inherit the CPU constraint from its parent. Container creation won't fail if the parent CPU constraint is smaller than the default number of vCPUs. fixes kata-containers#1521 Signed-off-by: Julio Montes <[email protected]>
ganeshmaharaj
pushed a commit
to ganeshmaharaj/kata-runtime
that referenced
this issue
Apr 19, 2019
Don't set a default CPU constraint if period and quota are not specified, that way the container will inherit the CPU constraint from its parent. Container creation won't fail if the parent CPU constraint is smaller than the default number of vCPUs. fixes kata-containers#1521 Signed-off-by: Julio Montes <[email protected]> (cherry picked from commit 59e3956) Signed-off-by: Ganesh Maharaj Mahalingam <[email protected]>
ganeshmaharaj
pushed a commit
to ganeshmaharaj/kata-runtime
that referenced
this issue
Apr 30, 2019
Don't set a default CPU constraint if period and quota are not specified, that way the container will inherit the CPU constraint from its parent. Container creation won't fail if the parent CPU constraint is smaller than the default number of vCPUs. fixes kata-containers#1521 Signed-off-by: Julio Montes <[email protected]> (cherry picked from commit 59e3956)
ganeshmaharaj
pushed a commit
to ganeshmaharaj/kata-runtime
that referenced
this issue
Apr 30, 2019
Don't set a default CPU constraint if period and quota are not specified, that way the container will inherit the CPU constraint from its parent. Container creation won't fail if the parent CPU constraint is smaller than the default number of vCPUs. fixes kata-containers#1521 Signed-off-by: Julio Montes <[email protected]> (cherry picked from commit 59e3956) Signed-off-by: Ganesh Maharaj Mahalingam <[email protected]>
ganeshmaharaj
pushed a commit
to ganeshmaharaj/kata-runtime
that referenced
this issue
Apr 30, 2019
Don't set a default CPU constraint if period and quota are not specified, that way the container will inherit the CPU constraint from its parent. Container creation won't fail if the parent CPU constraint is smaller than the default number of vCPUs. fixes kata-containers#1521 Signed-off-by: Julio Montes <[email protected]> (cherry picked from commit 59e3956) Signed-off-by: Ganesh Maharaj Mahalingam <[email protected]>
jcvenegas
added a commit
to jcvenegas/runtime
that referenced
this issue
Aug 6, 2020
Highlights for cloud-hypervisor version 0.9.0 include:
virtiofs updates to new dax implementation based in qemu 5.0
Fixed random issues caused due to seccomp filters
io_uring Based Block Device Support
If the io_uring feature is enabled and the host kernel supports it then io_uring will be used for block devices. This results a very significant performance improvement.
Block and Network Device Statistics
Statistics for activity of the virtio network and block devices is now exposed through a new vm.counters HTTP API entry point. These take the form of simple counters which can be used to observe the activity of the VM.
HTTP API Responses
The HTTP API for adding devices now responds with the name that was assigned to the device as well the PCI BDF.
CPU Topology
A topology parameter has been added to --cpus which allows the configuration of the guest CPU topology allowing the user to specify the numbers of sockets, packages per socket, cores per package and threads per core.
Release Build Optimization
Our release build is now built with LTO (Link Time Optimization) which results in a ~20% reduction in the binary size.
Hypervisor Abstraction
A new abstraction has been introduced, in the form of a hypervisor crate so as to enable the support of additional hypervisors beyond KVM.
Snapshot/Restore Improvements
Multiple improvements have been made to the VM snapshot/restore support that was added in the last release. This includes persisting more vCPU state and in particular preserving the guest paravirtualized clock in order to avoid vCPU hangs inside the guest when running with multiple vCPUs.
Virtio Memory Ballooning Support
A virtio-balloon device has been added, controlled through the resize control, which allows the reclamation of host memory by resizing a memory balloon inside the guest.
Enhancements to ARM64 Support
The ARM64 support introduced in the last release has been further enhanced with support for using PCI for exposing devices into the guest as well as multiple bug fixes. It also now supports using an initramfs when booting.
Intel SGX Support
The guest can now use Intel SGX if the host supports it. Details can be found in the dedicated SGX documentation.
Seccomp Sandbox Improvements
The most frequently used virtio devices are now isolated with their own seccomp filters. It is also now possible to pass --seccomp=log which result in the logging of requests that would have otherwise been denied to further aid development.
Notable Bug Fixes
Our virtio-vsock implementation has been resynced with the implementation from Firecracker and includes multiple bug fixes.
CPU hotplug has been fixed so that it is now possible to add, remove, and re-add vCPUs (kata-containers#1338)
A workaround is now in place for when KVM reports MSRs available MSRs that are in fact unreadable preventing snapshot/restore from working correctly (kata-containers#1543).
virtio-mmio based devices are now more widely tested (kata-containers#275).
Multiple issues have been fixed with virtio device configuration (kata-containers#1217)
Console input was wrongly consumed by both virtio-console and the serial. (kata-containers#1521)
Fixes: kata-containers#2864
Signed-off-by: Jose Carlos Venegas Munoz <[email protected]>
jcvenegas
added a commit
to jcvenegas/runtime
that referenced
this issue
Aug 11, 2020
Highlights for cloud-hypervisor version 0.9.0 include:
virtiofs updates to new dax implementation based in qemu 5.0
Fixed random issues caused due to seccomp filters
io_uring Based Block Device Support
If the io_uring feature is enabled and the host kernel supports it then io_uring will be used for block devices. This results a very significant performance improvement.
Block and Network Device Statistics
Statistics for activity of the virtio network and block devices is now exposed through a new vm.counters HTTP API entry point. These take the form of simple counters which can be used to observe the activity of the VM.
HTTP API Responses
The HTTP API for adding devices now responds with the name that was assigned to the device as well the PCI BDF.
CPU Topology
A topology parameter has been added to --cpus which allows the configuration of the guest CPU topology allowing the user to specify the numbers of sockets, packages per socket, cores per package and threads per core.
Release Build Optimization
Our release build is now built with LTO (Link Time Optimization) which results in a ~20% reduction in the binary size.
Hypervisor Abstraction
A new abstraction has been introduced, in the form of a hypervisor crate so as to enable the support of additional hypervisors beyond KVM.
Snapshot/Restore Improvements
Multiple improvements have been made to the VM snapshot/restore support that was added in the last release. This includes persisting more vCPU state and in particular preserving the guest paravirtualized clock in order to avoid vCPU hangs inside the guest when running with multiple vCPUs.
Virtio Memory Ballooning Support
A virtio-balloon device has been added, controlled through the resize control, which allows the reclamation of host memory by resizing a memory balloon inside the guest.
Enhancements to ARM64 Support
The ARM64 support introduced in the last release has been further enhanced with support for using PCI for exposing devices into the guest as well as multiple bug fixes. It also now supports using an initramfs when booting.
Intel SGX Support
The guest can now use Intel SGX if the host supports it. Details can be found in the dedicated SGX documentation.
Seccomp Sandbox Improvements
The most frequently used virtio devices are now isolated with their own seccomp filters. It is also now possible to pass --seccomp=log which result in the logging of requests that would have otherwise been denied to further aid development.
Notable Bug Fixes
Our virtio-vsock implementation has been resynced with the implementation from Firecracker and includes multiple bug fixes.
CPU hotplug has been fixed so that it is now possible to add, remove, and re-add vCPUs (kata-containers#1338)
A workaround is now in place for when KVM reports MSRs available MSRs that are in fact unreadable preventing snapshot/restore from working correctly (kata-containers#1543).
virtio-mmio based devices are now more widely tested (kata-containers#275).
Multiple issues have been fixed with virtio device configuration (kata-containers#1217)
Console input was wrongly consumed by both virtio-console and the serial. (kata-containers#1521)
Fixes: kata-containers#2864
Signed-off-by: Jose Carlos Venegas Munoz <[email protected]>
jcvenegas
added a commit
to jcvenegas/runtime
that referenced
this issue
Aug 11, 2020
Highlights for cloud-hypervisor version 0.9.0 include:
virtiofs updates to new dax implementation based in qemu 5.0
Fixed random issues caused due to seccomp filters
io_uring Based Block Device Support
If the io_uring feature is enabled and the host kernel supports it then io_uring will be used for block devices. This results a very significant performance improvement.
Block and Network Device Statistics
Statistics for activity of the virtio network and block devices is now exposed through a new vm.counters HTTP API entry point. These take the form of simple counters which can be used to observe the activity of the VM.
HTTP API Responses
The HTTP API for adding devices now responds with the name that was assigned to the device as well the PCI BDF.
CPU Topology
A topology parameter has been added to --cpus which allows the configuration of the guest CPU topology allowing the user to specify the numbers of sockets, packages per socket, cores per package and threads per core.
Release Build Optimization
Our release build is now built with LTO (Link Time Optimization) which results in a ~20% reduction in the binary size.
Hypervisor Abstraction
A new abstraction has been introduced, in the form of a hypervisor crate so as to enable the support of additional hypervisors beyond KVM.
Snapshot/Restore Improvements
Multiple improvements have been made to the VM snapshot/restore support that was added in the last release. This includes persisting more vCPU state and in particular preserving the guest paravirtualized clock in order to avoid vCPU hangs inside the guest when running with multiple vCPUs.
Virtio Memory Ballooning Support
A virtio-balloon device has been added, controlled through the resize control, which allows the reclamation of host memory by resizing a memory balloon inside the guest.
Enhancements to ARM64 Support
The ARM64 support introduced in the last release has been further enhanced with support for using PCI for exposing devices into the guest as well as multiple bug fixes. It also now supports using an initramfs when booting.
Intel SGX Support
The guest can now use Intel SGX if the host supports it. Details can be found in the dedicated SGX documentation.
Seccomp Sandbox Improvements
The most frequently used virtio devices are now isolated with their own seccomp filters. It is also now possible to pass --seccomp=log which result in the logging of requests that would have otherwise been denied to further aid development.
Notable Bug Fixes
Our virtio-vsock implementation has been resynced with the implementation from Firecracker and includes multiple bug fixes.
CPU hotplug has been fixed so that it is now possible to add, remove, and re-add vCPUs (kata-containers#1338)
A workaround is now in place for when KVM reports MSRs available MSRs that are in fact unreadable preventing snapshot/restore from working correctly (kata-containers#1543).
virtio-mmio based devices are now more widely tested (kata-containers#275).
Multiple issues have been fixed with virtio device configuration (kata-containers#1217)
Console input was wrongly consumed by both virtio-console and the serial. (kata-containers#1521)
Fixes: kata-containers#2864
Signed-off-by: Jose Carlos Venegas Munoz <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Recent tests have shown a problem with this check-in - #1189 where containers are not activated at all if parent cgroup with resource limits is passed to kata. When test was changed in a way that container is requesting the whole machine, this container activated (as parent and child cgroup will have the same limits).
In our clusters default number of vcpus is -1 (entire machine) and as parent cgroup can’t have stricter limits than the child cgroup, container activation fails with this error:
"Could not update cgroup /fabric/SingleInstance_0_App1:myCpuServicePkg@3016e3dc-60b9-8746-a897-4f1bb73dd80a@0c665905-47af-8147-b616-8a0c099ca7a5/crio-5e4f661e9035b89d190a34bcec617a75ac0006b47b784dab207f02bda98736d1: write /sys/fs/cgroup/cpu/fabric/SingleInstance_0_App1:myCpuServicePkg@3016e3dc-60b9-8746-a897-4f1bb73dd80a@0c665905-47af-8147-b616-8a0c099ca7a5/crio-5e4f661e9035b89d190a34bcec617a75ac0006b47b784dab207f02bda98736d1/cpu.cfs_quota_us: invalid argument"
I believe the problem is this code snippet in virtcontainers/cgroups.go - as this will govern containers even though they do not have constraints - which is not expected.
Without the code snippet above, our resource governance would have worked out of the box.
Expected result
Container is activated and governed (restricted by limits on parent cgroup level that is passed to kata).
Actual result
Container is not activated at all - the error received:
CreateContainer gRPC-error: 2: container create failed: Could not update cgroup /fabric/SingleInstance_0_App1:myCpuServicePkg@3016e3dc-60b9-8746-a897-4f1bb73dd80a@0c665905-47af-8147-b616-8a0c099ca7a5/crio-5e4f661e9035b89d190a34bcec617a75ac0006b47b784dab207f02bda98736d1: write /sys/fs/cgroup/cpu/fabric/SingleInstance_0_App1:myCpuServicePkg@3016e3dc-60b9-8746-a897-4f1bb73dd80a@0c665905-47af-8147-b616-8a0c099ca7a5/crio-5e4f661e9035b89d190a34bcec617a75ac0006b47b784dab207f02bda98736d1/cpu.cfs_quota_us: invalid argument
The text was updated successfully, but these errors were encountered: