The SRU Team discussed this bug this morning during the Fortnightly SRU Team meeting.
The general consensus is that the patch may be okay, even with the feeling that noble users might not get as much value from the patch, as other users might, such as running the noble qemu package on a noble container on a jammy or lower host with a lower vm.max_map_count. Subject to having a few questions answered of course. 1) There is a concern that currently qemu can allocate right up to the limit of VMAs in vm.max_map_count, and that under the new patch, this will be much smaller. For example, if a user is on a jammy system with vm.max_map_count at 65530, and they have an existing VM that is near, but not hitting the limit, like at 62000 for example. Under the new scheme, the calculation for the maximum would be (65530 - 5000) / 2 = 30265 co-routines or 60500 VMAs more or less. Would this user still be able to start their virtual machine after starting the package? Or would it error out and cause an outage? For existing noble users, would they see any tangible difference? Could a user still start a VM with 128 vcpus at 40 disks attached before vs after the patch? Forcing user interaction for existing deployments to increase vm.max_map_count is not acceptable. 2) Following up with the error out case, is there any way for the user to be informed that they are exceeding or getting close to the VMA limit? In the new implementation ideally. Is there any logging or indication that a qemu process has hit the VMA ceiling? 3) The SRU template does mention that libvirt needs to be patched to get an apparmor profile to be able to read vm.max_map_count correctly. The SRU template does not explain what happens if this apparmor profile is not present. We assume that we get a map count of UINT_MAX right? What is the risk of the user not getting this apparmor profile fix at the same time, e.g. only using -security and not -updates, and later on they get a qemu CVE fix and not the libvirt patch, and suddenly their VMs don't start or crash due to attempting to hit UINT_MAX? What are the odds of this happening, especially on systems with a low vm.max_map_count like jammy at 65530? Ideally we don't want to introduce a hard dependency on the fixed libvirt package. 4) Have you explored adding a maximum limit to the current implementation, as a smaller, more targeted patch? Would it look any different to the upstream patch? Would it be more risky, or less, since we currently have unbounded thread local co-routines and you would have to clean them up or recycle somehow? (Personally I think this is more risky than using the upstream implementation). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2168803 Title: QEMU 8.2.2 guests crash by exhausting vm.max_map_count with coroutines To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2168803/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
