I took a closer look at this recently.

For the first part, one can get the shm size using statfs and use this for setting up the shm mount. With this, Docker --shm-size option can easily be supported.
For the CRI case, both cri-o and cri-containerd setup a sandbox level shm mount in case -ipc is not set to host.
The other containers then bind-mount this sandbox-level shm mount. In case ipc is set to host, the host /dev/shm is used. We cannot really support this case where ipc is shared with the host.

Currently, we do not the shm mount as a bind mount but change this to a tmpfs mount before passing this to the agent, so that it is not passed through 9pfs.
https://github.com/kata-containers/runtime/blob/9fb0b337ef997079b304fe895dacd5d96d6f2fb6/virtcontainers/kata_agent.go#L617-L622

But we do create a separate shm mount for every container in a pod.

This looks like another case where we cannot support the OCI spec. My proposal is to pass the shm-size as part of the CreateSandbox request and delete all shm mounts from the OCI spec that we pass to the agent. The agent would then setup a shared shm mount using the size passed to it while creating the sandbox, and every container would then bind mount this shared shm mount.

@bergwolf @sboeuf What do you think?

Support "docker run --shm-size <bytes>" #21

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions