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

["DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>]

>>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 seem to be available in scope object
https://www.freedesktop.org/wiki/Software/systemd/dbus/



>>But that would also affect the swtpm process spawned there :/

Yes, not sure about the impact on other process


 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.

Yes, but it don't raise the limit :/ But it's really working with more
than 1024 file descriptor.