Am 12.12.23 um 12:55 schrieb Thomas Lamprecht:
> 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
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
>
>>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
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
>>I thought: can't we instead do this as part of setting up the systemd
>>scope/qemu.slice with LimitNOFILE?
I have tried (see my cover-letter ;), I can't get it work.
"start failed: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set
property LimitNOFILE, or unknown property.
"
I don't
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
---
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 {
