What were you trying to do that didn't work?

We have an issue reported at https://issues.redhat.com/browse/RHEL-28947, if there are many virtio-blk devices, disks are used and the VM caused a lot of I/Os to disks, like ODF node, it hit an issue in RHEL-28947.

What is the impact of this issue to you?

If this issue in RHEL-28947 happens, the qemu process is crashed and VM suddenly is shut down. This caused heavy support workload at customer side and support team side.

Please provide the package NVR for which the bug is seen:

All shipped tuned version.

How reproducible is this bug?:

Sometimes

Steps to reproduce

Please refer to RHEL-28947

Expected results

The issue doesn't happen.

Actual results

The issue observed.

Additional information

In github's code for tuned, other profiles have the same kernel parameter.

$ grep vm.max_map_count -r *
profiles/mssql/tuned.conf:vm.max_map_count=1600000
profiles/openshift/tuned.conf:vm.max_map_count=262144
profiles/sap-netweaver/tuned.conf:vm.max_map_count = 2147483647

I think the key point of the resolution is how we calculate the better value to the parameter.
For example, we assume the maximum configuration for a VM is half number of vCPUs (when there is 24 vCPUs, 12 as assumed maximum) and maximum PCI-E devices connected to virtio-blk device in q35 platform.

The equation will be

 Calculated vm.max_map_count = half of all vCPUS * queue size(256) * max PCI devices(23)