virtiofs and running out of file handles is a real pain in Proxmox VMs. The fix is raising the limit on the host and the guest, but which knob actually works? I tested a few.
Reproduce it first
Don’t guess. Make a test workload that opens a ton of files. This shell loop does it:
for i in $(seq 1 50000); do
touch /mnt/virtiofs/testfile_$i
exec 9Run it inside the VM with the virtiofs mount. You'll hit "Too many open files" way before 50k.
Why it happens
virtiofs passes file handles from the guest to the host's virtiofsd daemon. Each open file eats a handle on both sides. The default limit is often 1024 on the guest, and the host's virtiofsd has its own cap. It's a double ceiling.
The workarounds
Three things people try. Only one really moves the needle.
- ulimit -n in the guest: raises the guest limit, but the host still caps you.
- --rlimit-nofile flag on virtiofsd: sets the daemon's limit. This is the key one.
- fs.file-max sysctl: changes the system-wide max, but rarely the bottleneck.
I'd go straight for the virtiofsd flag. On Proxmox, edit the VM config: args: -chardev socket,id=char0,path=/var/run/virtiofsd.sock -device vhost-user-fs-pci,chardev=char0,tag=shared. Then start virtiofsd manually with --rlimit-nofile=65536.
Guest side, set LimitNOFILE=65536 in the systemd service or just ulimit -n 65536 before running your app.
Measure it
After the fix, rerun the loop. I got past 50k opens without a hiccup. Before, it died at 1021. That's the proof.
If you're on a newer Proxmox, the virtiofsd options moved into the args line. Check your version. The Proxmox wiki covers the basics but skips this limit stuff.
For a related mount headache, see Container mount point GID mapping works, but no write access.
