-
Notifications
You must be signed in to change notification settings - Fork 373
cgroups v2 in the guest #2494
Comments
Although I do believe it does make sense, I would not enforce this. I'd take the follow (conservative) approach:
Does this make sense? The reason I'd take the conservative approach is that some distros may not support cgroups v2 yet and we'd face some issues with CI and whatnot. For instance, do CentOS 7 or Ubuntu 18.04 support cgroups v2 (this is almost a retorical question that I'll try to answer Tomorrow ;-))? Don't we test on both? |
@fidencio thanks for replying,
yeah, this makes sense to me, I can start working on the second point. thanks for the feedback 👍 |
I agree with @fidencio. It also makes a big use case for kata containers as it allows the container payload to use a different cgroup version than on the host. Other OCI runtimes don't support (due to kernel limitations) mixing the two versions. |
I am late here, but yeah agree with @fidencio. We need to wait to flip the switch till distros start supporting cgroupsv2. It will be useful to have the ability to use cgroupsv2 in the guest through configuration till then. |
I agree, I raised kata-containers/agent#750 to allow users (like me) to play with v2 in the guest |
Should kata use cgroups v2 in the guest?
tasks:
systemd.unified_cgroup_hierarchy=1
to the kernel command line-t cgroup2
when running as init processcc @fidencio @crobinso @amshinde
The text was updated successfully, but these errors were encountered: