public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Fiona Ebner <f.ebner@proxmox.com>,
	"DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>,
	"aderumier@odiso.com" <aderumier@odiso.com>
Subject: Re: [pve-devel] [PATCH qemu-server 1/1] fix #4507 : increase qemu max openfiles limit
Date: Tue, 12 Dec 2023 12:55:33 +0100	[thread overview]
Message-ID: <5ab928ae-2191-465d-90b8-570895f56d8f@proxmox.com> (raw)
In-Reply-To: <ab1a0105-8590-4b22-8bf2-af9572cf6730@proxmox.com>

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).




  parent reply	other threads:[~2023-12-12 11:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-10 14:49 [pve-devel] [PATCH qemu-server 0/1] " Alexandre Derumier
2023-12-10 14:49 ` [pve-devel] [PATCH qemu-server 1/1] fix #4507 : " Alexandre Derumier
2023-12-11  9:46   ` Fiona Ebner
2023-12-11 16:29     ` DERUMIER, Alexandre
2023-12-12  9:21       ` Fiona Ebner
2023-12-12 11:10         ` DERUMIER, Alexandre
2023-12-12 11:55         ` Thomas Lamprecht [this message]
2023-12-12 12:20           ` Fiona Ebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ab928ae-2191-465d-90b8-570895f56d8f@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=aderumier@odiso.com \
    --cc=alexandre.derumier@groupe-cyllene.com \
    --cc=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal