Environment
Proxmox VE 9.2.5
pve-qemu-kvm 11.0.2-2
qemu-server 9.2.1
VM uses virtiofs backed by CephFS:
Example generated virtiofsd command:
Issue
virtiofsd has an option: --inode-file-handles=prefer which avoids keeping raw file descriptors open for inode tracking and prevents deleted-but-open inode accumulation during metadata-heavy workloads. This option is currently automatically enabled by Proxmox only when the VM ostype is detected as Windows.
Relevant code:
Problem case
There are valid Linux guest workloads which have the same filesystem access pattern as Windows guests.
Example:
Changing ostype: l26 to ostype: win11 does enable the inode file handle behaviour, but it is not usable as Proxmox then applies Windows virtiofs restrictions and refuses configurations using ACLs:
For Linux guests using CephFS and sharing via CIFS to windows clients, POSIX ACL support is required.
Therefore:
Proposed change
Add an explicit virtiofs configuration option independent of guest OS detection.
For example:
or:
but ideally as a first-class pve-qm-virtiofs property. The resulting logic would become:
prefer inode handles if:
guest is Windows
OR
user explicitly configured inode-file-handles=prefer
Current workaround
Manually modifying: /usr/share/perl5/PVE/QemuServer/Virtiofs.pm to force: my $prefer_inode_fh = 1; but this is not upgrade-safe.
Request
Please expose --inode-file-handles as a configurable virtiofs option instead of tying it exclusively to Windows guest detection. This would support Linux guests providing Windows-compatible file services (Samba/CIFS) without sacrificing POSIX ACL support.
Proxmox VE 9.2.5
pve-qemu-kvm 11.0.2-2
qemu-server 9.2.1
VM uses virtiofs backed by CephFS:
Example generated virtiofsd command:
Code:
/usr/libexec/virtiofsd \
--fd=17 \
--shared-dir=/mnt/pve/cephfs-storage/backup \
--posix-acl \
--announce-submounts \
--syslog
Issue
virtiofsd has an option: --inode-file-handles=prefer which avoids keeping raw file descriptors open for inode tracking and prevents deleted-but-open inode accumulation during metadata-heavy workloads. This option is currently automatically enabled by Proxmox only when the VM ostype is detected as Windows.
Relevant code:
Code:
/usr/share/perl5/PVE/QemuServer/Virtiofs.pm
# See https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1136
my $prefer_inode_fh = PVE::QemuServer::Helpers::windows_version($conf->{ostype}) ? 1 : 0;
Problem case
There are valid Linux guest workloads which have the same filesystem access pattern as Windows guests.
Example:
- Linux VM
- virtiofs mount backed by CephFS
- VM exports the mounted filesystem via Samba/CIFS to Windows clients
- heavy metadata operations
- directory enumeration
- stat-heavy workloads
- retention/purge scans
Changing ostype: l26 to ostype: win11 does enable the inode file handle behaviour, but it is not usable as Proxmox then applies Windows virtiofs restrictions and refuses configurations using ACLs:
Code:
TASK ERROR: Please disable ACLs for virtiofs on Windows VMs, otherwise the virtiofs shared directory cannot be mounted.
For Linux guests using CephFS and sharing via CIFS to windows clients, POSIX ACL support is required.
Therefore:
- ostype=l26 → keeps ACLs but no inode file handles
- ostype=win11 → enables inode file handles but breaks ACL requirements
Proposed change
Add an explicit virtiofs configuration option independent of guest OS detection.
For example:
Code:
virtiofs0: cephfs-storage-backup,inode-file-handles=prefer
or:
Code:
args: --inode-file-handles=prefer
but ideally as a first-class pve-qm-virtiofs property. The resulting logic would become:
prefer inode handles if:
guest is Windows
OR
user explicitly configured inode-file-handles=prefer
Current workaround
Manually modifying: /usr/share/perl5/PVE/QemuServer/Virtiofs.pm to force: my $prefer_inode_fh = 1; but this is not upgrade-safe.
Request
Please expose --inode-file-handles as a configurable virtiofs option instead of tying it exclusively to Windows guest detection. This would support Linux guests providing Windows-compatible file services (Samba/CIFS) without sacrificing POSIX ACL support.