[BUG] `/proc/sys/vm/max_map_count` from host is not leveraged for running containers

[irishgordo]

Actual Behavior

There are instances where running a container will need an increase within the vm.max_map_count from the host. An example would be running Elasticsearch in containers, cross-ref here.

Steps to Reproduce

• remember your original max_map_count, via cat /proc/sys/vm/max_map_count, in order to revert back later
• have Rancher Desktop Electron application not running
• in this distinct example leveraging Elasticsearch per their docs for v6.8, for a 'production' style environment we'll need to have the max_map_count increased, via something like: sudo sysctl -w vm.max_map_count=262144
• then you can re-cat /proc/sys/vm/max_map_count
• then launching the electron Rancher Desktop application
• then running Elasticsearch for instance of:

  docker run --name elasticsearch -p 9200:9200 -p 9300:9300 -e xpack.security.enabled=false -e node.name=es01 -it docker.elastic.co/elasticsearch/elasticsearch:6.8.23

• you'll be able to audit that the run should fail

Result

From the interactive container logs it shows exit status code 1 and a comment that the max_map_count is too low and needs to be increased:

[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

Expected Behavior

That setting the vm.max_map_count on the host machine would be picked up by Rancher Desktop.

Additional Information

No response

Rancher Desktop Version

1.6.2

Rancher Desktop K8s Version

1.23.4

Which container engine are you using?

moby (docker cli)

What operating system are you using?

Ubuntu

Operating System / Build Version

Ubuntu based distro -> Pop!_OS 22.04 LTS

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

No response

Windows User Only

No response

[adamkpickering]

Thanks for filing an issue!

You may be aware of this, but you can likely work around this by getting a shell inside the Rancher Desktop VM and then modifying vm.max_map_count from there. I think this setting will be stable across restarts. But, you'll definitely have to set it again if you do a factory reset.

As for mapping the value on the host to the value in the VM, that needs some design work. Without delving into the issue, I think it would be better to have a setting for this in the Rancher Desktop preferences. Of course, there is the question of which /proc/sys variables we implement this for (there are many). @jandubois what do you think?

[ejensler]

@adamkpickering Thanks for describing the workaround! I was able to get this working on macOS with the following:

1. docker compose down the relevant docker container(s).
2. Open the Rancher Desktop VM shell: rdctl shell
3. Set the vm.max_map_count to the desired value: sudo sysctl -w vm.max_map_count=262144
4. docker compose up the container.

Not really an expert on VM configuration, but as for the design work, I could see something like this:

(with the relevant preferences needed in the panel of course)

[waynekhan]

Hello, I ran into this same problem of kernel params not being preserved across reboots, this despite me adding a custom .conf file in /etc/sysctl.d/.

It was getting annoying having to rdctl shell from time to time; the fix for me was to rename it (to local.conf), have a try?

PS: I'm not sure exposing kernel parameters in the UI makes a lot of sense, as there would be a lot more than just the 3.

[chamanjain199]

This solution work for me https://stackoverflow.com/questions/42111566/elasticsearch-in-windows-docker-image-vm-max-map-count#:~:text=1)%20wsl%20%2Dd%20docker%2Ddesktop%0A2)%20sysctl%20%2Dw%20vm.max_map_count%3D262144