On a stock trixie install, immediately after installing
qemu-system-x86/libvirt-daemon-system/virtinst and nothing else unusual
(no custom AppArmor policy, no systemd overrides at the time), starting
libvirtd fails its udev/node-device driver initialization with:

    Unable to find default local file monitor type

This is immediately followed by a cascade of inotify-instance-exhaustion
errors ("Failed to allocate directory watch: Too many open files") as
libvirtd repeatedly retries file-monitor setup and burns through
fs.inotify.max_user_instances.

Root cause: libvirtd's node-device driver uses GLib/GIO's GFileMonitor
abstraction, which autodetects a backend (inotify, kqueue, etc.) based on
environment/build configuration. That autodetection fails specifically
under libvirtd.service's minimal systemd-supplied environment -- confirmed
by running the identical libvirtd binary interactively from a login shell,
where GIO's autodetection succeeds without issue. This is a known class of
GIO/GLib issue; the documented workaround is forcing the backend
explicitly via the GIO_USE_FILE_MONITOR environment variable.

Steps to reproduce:
1. Fresh trixie install, `apt install qemu-system-x86 qemu-utils \
   libvirt-daemon-system libvirt-clients virtinst bridge-utils \
   dnsmasq-base`.
2. `systemctl start libvirtd` (or let it start via socket activation).
3. Observe `journalctl -u libvirtd` / the libvirtd log: "Unable to find
   default local file monitor type", then repeated
   "Failed to allocate directory watch: Too many open files".

Workaround that resolves it completely:

    mkdir -p /etc/systemd/system/libvirtd.service.d
    cat > /etc/systemd/system/libvirtd.service.d/override.conf <<'CONF'
    [Service]
    Environment=GIO_USE_FILE_MONITOR=inotify
    CONF
    systemctl daemon-reload
    systemctl restart libvirtd.service

Requesting this (or an equivalent fix) be incorporated into the shipped
libvirtd.service unit, since the failure reproduces on a stock install
with no unusual configuration, and the symptom (a GIO internals message
followed by an unrelated-looking inotify exhaustion cascade) gives no
direct hint toward this specific, narrow fix.