Hi Andrea,

Please consider shipping the modular per-driver daemons (virtqemud etc.,
plus virtproxyd for socket compatibility) in a new binary package, so
they're available as alternative to the monolithic libvirtd. This is
separate from any decision about the default preset.

Rationale:

- Upstream treats libvirtd as legacy, replaced by the modular virt*d
  daemons, with removal planned. [0][1]
- Fedora (since F35) [2], RHEL 9 [3], and SLES 15 SP6 [4] already ship
  and default to the modular daemons.
- Upstream is adding support to build without libvirtd entirely (Feb
  2026 RFC: -Ddriver_libvirtd=disabled). [5]

Shipping the modular daemons now lets users opt in and keeps Debian
ready for when upstream drops libvirtd. Happy to help test.

Thanks,
Lee

[0] https://libvirt.org/daemons.html
[1] https://www.berrange.com/posts/2020/02/04/libvirt-split-of-the-monolithic-libvirtd-daemon/
[2] https://fedoraproject.org/wiki/Changes/LibvirtModularDaemons
[3] https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/considerations_in_adopting_rhel_9/assembly_virtualization_considerations-in-adopting-rhel-9
[4] https://documentation.suse.com/sles/15-SP6/html/SLES-all/cha-libvirt-overview.html
[5] http://www.mail-archive.com/devel@lists.libvirt.org/msg15383.html