[pve-devel] [PATCH qemu-server 1/1] fix #4507 : increase qemu max openfiles limit

Thomas Lamprecht t.lamprecht at proxmox.com
Tue Dec 12 12:55:33 CET 2023

Am 12/12/2023 um 10:21 schrieb Fiona Ebner:
> Am 11.12.23 um 17:29 schrieb DERUMIER, Alexandre:
>>>> So not sure if that's really nicer. This suggests QEMU should raise
>>>> the
>>>> limit itself.
>> Yes, but it don't raise the limit :/ But it's really working with more
>> than 1024 file descriptor.
> From a quick look, I didn't find an option to pass along QEMU for this,
> so it would likely need to be implemented first/discussed with upstream.
> But thinking about it a bit, it feels wrong for each application to be
> responsible for raising the limit itself. Sure the application needs to
> avoid using select(), but IMHO such limits are better set from the
> outside. I think your approach is fine, can you please send a v2 with a
> Signed-off-by and my nits addressed?

Meh, I think the application that actually can use many FDs, which are not
*that* many, should just raise it to the highest limit possible, so I'd
rather do this inside QEMU.
Doing such stuff from the outside is almost always a bit more maintenance
burden, e.g., cue to our various hacks over multiple releases for correctly
waiting for the VMID scope to exit.

We can just patch it in for now downstream while checking if upstream would
accept that, IMO in modern times FD limits are not much a protection,
especially if raised from 1024 to a few hundreds of thousands, especially
as in QEMU the amount isn't really controllable via the guest (i.e.,
unprivileged code).

More information about the pve-devel mailing list