From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 9641AB9648 for ; Mon, 11 Dec 2023 10:47:30 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 71C2C13F48 for ; Mon, 11 Dec 2023 10:47:00 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 11 Dec 2023 10:46:59 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 81E1844F19; Mon, 11 Dec 2023 10:46:59 +0100 (CET) Message-ID: <468db986-a957-4216-b4c7-ce9243f9f092@proxmox.com> Date: Mon, 11 Dec 2023 10:46:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Proxmox VE development discussion , Alexandre Derumier References: <20231210144940.2031248-1-aderumier@odiso.com> <20231210144940.2031248-2-aderumier@odiso.com> From: Fiona Ebner In-Reply-To: <20231210144940.2031248-2-aderumier@odiso.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.077 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH qemu-server 1/1] fix #4507 : increase qemu max openfiles limit X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2023 09:47:30 -0000 Much of the cover letter would be nice to have as a commit message here. Missing your Signed-off-by. Am 10.12.23 um 15:49 schrieb Alexandre Derumier: > --- > PVE/QemuServer.pm | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm > index 2063e66..eba26f3 100644 > --- a/PVE/QemuServer.pm > +++ b/PVE/QemuServer.pm > @@ -5991,6 +5991,12 @@ sub vm_start_nolock { > eval { PVE::QemuServer::PCI::reserve_pci_usage($pci_reserve_list, $vmid, undef, $pid) }; > warn $@ if $@; > > + #increase OpenFile limit Nit: why is "OpenFile" capitalized like this? I'd rather put the bug number in the comment, because the "what" is rather obvious while the "why" is less so. > + eval { > + run_command(['/usr/bin/prlimit', '--nofile=524288:524288', "--pid", $pid]); > + }; Some short mention that this is the default hard limit would be nice. We don't usually write an absolute path to the binary with run_command. > + warn $@ if $@; > + Please use log_warn() so it will be visible as a task warning too. > if (defined($res->{migrate})) { > print "migration listens on $res->{migrate}->{uri}\n"; > } elsif ($statefile) { I thought: can't we instead do this as part of setting up the systemd scope/qemu.slice with LimitNOFILE? But that would also affect the swtpm process spawned there :/ and the systemd.exec man page says: > │LimitNOFILE= │ ulimit -n │ Number of File Descriptors │ Don't use. Be careful when raising the soft limit above 1024, since select() cannot │ > │ │ │ │ function with file descriptors above 1023 on Linux. Nowadays, the hard limit │ > │ │ │ │ defaults to 524288, a very high value compared to historical defaults. Typically │ > │ │ │ │ applications should increase their soft limit to the hard limit on their own, if │ > │ │ │ │ they are OK with working with file descriptors above 1023, i.e. do not use │ > │ │ │ │ select(). Note that file descriptors are nowadays accounted like any other form of │ > │ │ │ │ memory, thus there should not be any need to lower the hard limit. Use MemoryMax= │ > │ │ │ │ to control overall service memory use, including file descriptor memory. │ So not sure if that's really nicer. This suggests QEMU should raise the limit itself.