Libvirtd TCP port 16514 queries

I have a server that is running libvirtd. I just checked libvirtd ports and see below output. I wondered Why port 16514 PID is always 1 and why tcp6 is handling ipv4 with multi connections.

Can anyone please let me know.

root@prd-140:~# netstat -anpt |grep 16514
tcp6       0      0 :::16514                :::*                    LISTEN      1/systemd
tcp6       0      0 10.1.6.140:16514       10.2.127.52:60556     ESTABLISHED 12289/libvirtd
tcp6       0      0 10.1.6.140:16514       10.2.127.52:29463     ESTABLISHED 12289/libvirtd

root@prd-140:~# lsof -i :16514
COMMAND    PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
systemd      1 root   59u  IPv6  9761899      0t0  TCP *:16514 (LISTEN)
libvirtd 12289 root    5u  IPv6  9761899      0t0  TCP *:16514 (LISTEN)
libvirtd 12289 root   30u  IPv6 20539283      0t0  TCP prd-140:16514->10.2.127.52:60556 (ESTABLISHED)
libvirtd 12289 root   35u  IPv6 20549679      0t0  TCP prd-140:16514->10.2.127.52:29463 (ESTABLISHED)

• The first part is about systemd's socket-based activation.
• The second part is about IPv4/IPv6 dual stack handling

systemd's socket-based activation

systemd.socket:

A unit configuration file whose name ends in ".socket" encodes information about an IPC or network socket or a file system FIFO controlled and supervised by systemd, for socket-based activation.

For each socket unit, a matching service unit must exist [...]

Note that the daemon software configured for socket activation with socket units needs to be able to accept sockets from systemd, either via systemd's native socket passing interface (see sd_listen_fds(3) for details about the precise protocol used and the order in which the file descriptors are passed) or via traditional inetd(8)-style socket passing (i.e. sockets passed in via standard input and output, using StandardInput=socket in the service file).

This feature is an improvement over what the inetd ("internet super-server") could provide, but can require additional support from the application (for systemd's native socket passing interface).

libvirtd does offer such support:

Monolithic Systemd Integration

When the libvirtd daemon is managed by systemd a number of desirable features are available, most notably socket activation.

• libvirtd.service - the main unit file for launching the libvirtd daemon in system mode.

• libvirtd.socket - the unit file corresponding to the main read-write UNIX socket /var/run/libvirt/libvirt-sock.

Here it apppears OP's settings aren't just using the default unix socket but enabled TLS remote connections.

The goal is to let systemd manage the socket without having to run libvirtd until a request on this socket is received. systemd will then start the libvirtd service which inherits the socket.

IPv6 uses IPv4/IPv6 dual stack mode

The 2nd feature is just how dual IPv4/IPv6 stack works: use the IPv6 API, get IPv4 for free. This can be disabled with the IPV6_ONLY socket option, but the default is to be dual stack, as encouraged in RFC 3493: Basic Socket Interface Extensions for IPv6:

5.3 IPV6_V6ONLY option for AF_INET6 Sockets

This socket option restricts AF_INET6 sockets to IPv6 communications only. As stated in section <3.7 Compatibility with IPv4 Nodes>, AF_INET6 sockets may be used for both IPv4 and IPv6 communications.

By default this option is turned off.

meaning that by default IPv6 can handle IPv4 on a system following RFCs and with an application not actively disabling this feature.

netstat chooses to display a plain IPv4, but for example the local address seen on the established sockets is actually an IPv4-mapped IPv6 address: ::ffff:10.1.6.140 (or ::ffff:0a01:068c) as would ss -anpt display instead on Linux. The address on the wire stays of course a normal IPv4 address.