Libvirtd conffiles should be less misleading and document tcp/tls usage

Digging into this a bit more, it looks like the libvirtd.service file needs to be changed to enable the tcp listener instead of using the /etc/default/libvirtd config file. Would be nice if the service had the tcp option (commented out by default)

My changes were to
Remove $libvirtd_opts because any setting here causes the service to fail at startup.
Add
Wants=libvirtd-tcp.socket
and
Also=libvirtd-tcp.socket

[Unit]
Description=Virtualization daemon
Requires=virtlogd.socket
Requires=virtlockd.socket
# Use Wants instead of Requires so that users
# can disable these three .socket units to revert
# to a traditional non-activation deployment setup
Wants=libvirtd.socket
Wants=libvirtd-ro.socket
Wants=libvirtd-tcp.socket
Wants=libvirtd-admin.socket
Wants=systemd-machined.service
Before=libvirt-guests.service
After=network.target
After=dbus.service
After=iscsid.service
After=apparmor.service
After=local-fs.target
After=remote-fs.target
After=systemd-logind.service
After=systemd-machined.service
After=xencommons.service
Conflicts=xendomains.service
Documentation=man:libvirtd(8)
Documentation=https://libvirt.org

[Service]
Type=notify
EnvironmentFile=-/etc/default/libvirtd
ExecStart=/usr/sbin/libvirtd $libvirtd_opts
#ExecStart=/usr/sbin/libvirtd -l -d
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
# At least 1 FD per guest, often 2 (eg qemu monitor + qemu agent).
# eg if we want to support 4096 guests, we'll typically need 8192 FDs
# If changing this, also consider virtlogd.service & virtlockd.service
# limits which are also related to number of guests
LimitNOFILE=8192
# The cgroups pids controller can limit the number of tasks started by
# the daemon, which can limit the number of domains for some hypervisors.
# A conservative default of 8 tasks per guest results in a TasksMax of
# 32k to support 4096 guests.
TasksMax=32768
# With cgroups v2 there is no devices controller anymore, we have to use
# eBPF to control access to devices. In order to do that we create a eBPF
# hash MAP which locks memory. The default map size for 64 devices together
# with program takes 12k per guest. After rounding up we will get 64M to
# support 4096 guests.
LimitMEMLOCK=64M

[Install]
WantedBy=multi-user.target
Also=virtlockd.socket
Also=virtlogd.socket
Also=libvirtd.socket
Also=libvirtd-ro.socket
Also=libvirtd-tcp.socket

Hi,
thank you for your report!

The config in /etc/default/libvirtd is pretty much there for compatibility reasons with older setups and (on Debian) people using still sys-V init.
And even with systemd some other options than "-l" can still be sued that way e.g. "-v" for extra verbosity.

If one sets that option the error message gladly is pretty clear:
libvirtd[2725397]: --listen parameter not permitted with systemd activation sockets, see 'man libvirtd' for further guidance

In that man page it explains (as that isn't a Ubuntu only problem):

```
...
       In socket activation mode, it will rely on systemd to create and listen on the UNIX, and optionally TCP/IP, sockets and pass them as pre-opened file descriptors. In this mode, it
       is not permitted to pass the --listen parameter, and most of the socket related config options in /etc/libvirt/libvirtd.conf will no longer have any effect. To enable TCP or TLS
       sockets use either

          $ systemctl start libvirtd-tls.socket
       Or
          $ systemctl start libvirtd-tcp.socket
...
```

There is no need to change the .service file as you did, and in fact any subsequent update would eliminate that change.

As a TL;DR and I hope IIRC it would be like:
$ sudo systemctl stop libvirtd
$ sudo systemctl start libvirtd-tcp.socket
# in any real setup you'd now setup SASL, but for this to
# be short I set auth_tcp = "none" in /etc/libvirt/libvirtd.conf

With that in place
$ virsh -c qemu+tcp://127.0.0.1/system list

Will start libvirtd and it accepts tcp connections.

In addition there also is TLS which is more complex there is:

#setup CA and issue/config certificates for libvirtd
# see TLS x509 certificate configuration and any entry related to
# *tls* and *certificates* in /etc/libvirt/libvirtd.conf
$ sudo systemctl stop libvirtd
$ sudo systemctl start libvirtd-tls.socket

What to do from here:
- I agree that a hint in /etc/default/libvirtd would be great to have as its current
  form is misleading.
- This bug demonstrates that it is unclear how to be used.
  Therefore a documentation entry in the Ubuntu server guide would be very helpful.
  It should show how this can be done (for TCP) and also include an example of a
  cert setup and end by accessing via TLS

Triaging the bug with that in mind, but please speak up for a discussion on this if you want.

Work in progress.

Still no answer from Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050464

PR sent: https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/207