-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release-1.1] cgroupsv2: reconstruct device allowlist/drop internal device allow list state #10714
[release-1.1] cgroupsv2: reconstruct device allowlist/drop internal device allow list state #10714
Conversation
When a block volume is non-hotpluggable (i.e. it is specified explicitly in the VMI spec), the device cgroup permissions are managed purely by Kubernetes and CRI. For v2, that means a BPF program is assigned to the POD's cgroup. However, when we manage hotplug volumes, we overwrite the BPF program to allow access to the new block device. The problem is that we do not know what the existing BPF program does, hence we just follow some assumptions about the 'default' devices that we need to allow (e.g. /dev/kvm and some others). We need to also consider the non-hotpluggable volumes, otherwise a VM with a block PVC or DV will fail to start if a hotplug volume is attached to it. Signed-off-by: Vasiliy Ulyanov <vulyanov@suse.de> Signed-off-by: Alex Kalenyuk <akalenyu@redhat.com>
Signed-off-by: Vasiliy Ulyanov <vulyanov@suse.de> Signed-off-by: Alex Kalenyuk <akalenyu@redhat.com>
Keep the existing device rules within the manager state. Signed-off-by: Vasiliy Ulyanov <vulyanov@suse.de> Signed-off-by: Alex Kalenyuk <akalenyu@redhat.com>
…rsistent disk Signed-off-by: Alex Kalenyuk <akalenyu@redhat.com>
/lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: xpivarc The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
/test pull-kubevirt-e2e-k8s-1.26-sig-storage |
@akalenyu: The specified target(s) for
The following commands are available to trigger optional jobs:
Use
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/test pull-kubevirt-e2e-k8s-1.26-sig-storage-1.1 |
This is an automated cherry-pick of #10689
/assign akalenyu