--cpu fails with podman run in the vm for macos

[jarrellmark]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Using podman run --cpu flag fails under macOS using the podman machine vm.

This can be solved by doing:

podman machine ssh

And following these instructions: https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-cpu-limits-fails-with-a-permissions-error

I'd recommend the podman machine to have /etc/systemd/system/[email protected]/delegate.conf configured by default to allow the --cpu flag to work.

Steps to reproduce the issue:

On macOS

1. Start a new podman machine: podman machine init

2. Start the podman machine: podman machine start

3. Try running a container with the --cpu flag: podman run --cpu 1 -it alpine /bin/sh

Describe the results you received:

Error: opening file cpu.max for writing: Permission denied: OCI runtime permission denied error

Describe the results you expected:

Expected to see a busybox shell running in alpine.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

podman version 3.4.4

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.30-2.fc35.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.30, commit: '
  cpus: 4
  distribution:
    distribution: fedora
    variant: coreos
    version: "35"
  eventLogger: journald
  hostname: localhost.localdomain
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.15.10-200.fc35.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 3660603392
  memTotal: 4103524352
  ociRuntime:
    name: crun
    package: crun-1.4-1.fc35.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.4
      commit: 3daded072ef008ef0840e8eccb0b52a7efbd165d
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc35.x86_64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 11.59s
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /var/home/core/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 0
    stopped: 1
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/core/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 150
  runRoot: /run/user/1000/containers
  volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 1638999907
  BuiltTime: Wed Dec  8 21:45:07 2021
  GitCommit: ""
  GoVersion: go1.16.8
  OsArch: linux/amd64
  Version: 3.4.4

Package info (e.g. output of rpm -q podman or apt list podman):

% brew list podman
/usr/local/Cellar/podman/3.4.4/bin/podman
/usr/local/Cellar/podman/3.4.4/bin/podman-remote
/usr/local/Cellar/podman/3.4.4/etc/bash_completion.d/podman
/usr/local/Cellar/podman/3.4.4/libexec/gvproxy
/usr/local/Cellar/podman/3.4.4/share/fish/vendor_completions.d/podman.fish
/usr/local/Cellar/podman/3.4.4/share/man/ (160 files)
/usr/local/Cellar/podman/3.4.4/share/zsh/site-functions/_podman

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

No

Additional environment details (AWS, VirtualBox, physical, etc.):

macOS

[rhatdan]

@baude @ashley-cui @flouthoc is this something we should do in the ignition script?

[flouthoc]

If systemd path exists we could do that in ignition or i guess it should even work if we prepopulate the path, I'll try this .

We should only do it if its cgroupv2 cause if its cgroupv1 then delegation does not looks safe to me for unprivileged users and I think even systemd would not allow it. But the current VM image is already using cgroupv2 so that should not be any issue.

@giuseppe Could you suggest if is there any other problem if CPU delegation is done by default for non root users and its cgroupv2 with manager as systemd.

[giuseppe]

@giuseppe Could you suggest if is there any other problem if CPU delegation is done by default for non root users and its cgroupv2 with manager as systemd.

I don't see any risk for the Podman VM. The only reason systemd doesn't do that by default is because the CPU controller is expensive, so creating many cgroups could slowdown the kernel.

[flouthoc]

@giuseppe Thanks for confirming I created a PR which delegates cpu,io along with memory, pid cgroup controllers and working as expected.

@jarrellmark Above PR should close this issue. Could you please try this patch on your macOS. I have verified it already with

podman-remote run --cpus 1 -it alpine /bin/sh