Could you please elaborate?

Which unit got disabled? What was the version you upgraded from? I presume 'libvirt-daemon-driver-qemu-9.3.0-2.el9.x86_64' is the one you upgraded to. Did you have any specific manual setup?

virtproxyd-tls.socket I found disabled after the upgrade.

I can not reproduce this bug due to multiple reasons.  There's still too much info missing even after it was requested.  I still tried reproducing it the best I could, upgrading from 9.2.0-1.el9.x86_64.rpm:

[root@localhost ~]# systemctl enable --now virtproxyd-tls.socket
Created symlink /etc/systemd/system/sockets.target.wants/virtproxyd-tls.socket -> /usr/lib/systemd/system/virtproxyd-tls.socket.
[root@localhost ~]# systemctl status virtproxyd-tls.socket
* virtproxyd-tls.socket - Libvirt proxy TLS IP socket
     Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; enabled; preset: disabled)
     Active: active (listening) since Thu 2023-06-01 09:50:11 EDT; 1min 43s ago
      Until: Thu 2023-06-01 09:50:11 EDT; 1min 43s ago
   Triggers: * virtproxyd.service
     Listen: [::]:16514 (Stream)
      Tasks: 0 (limit: 48952)
     Memory: 8.0K
        CPU: 1ms
     CGroup: /system.slice/virtproxyd-tls.socket

Jun 01 09:50:11 localhost.localdomain systemd[1]: Listening on Libvirt proxy TLS IP socket.
[root@localhost ~]# ps -ef | grep dnf
root        4949    4663 20 09:51 pts/0    00:00:42 /usr/bin/python3 /usr/bin/dnf --enablerepo=* update -y --allowerasing
root       35474    4960  0 09:54 pts/1    00:00:00 grep --color=auto dnf
[root@localhost ~]# while killall -0 dnf; do sleep 1; done; systemctl status virtproxyd-tls.socket
dnf: no process found
* virtproxyd-tls.socket - Libvirt proxy TLS IP socket
     Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; enabled; preset: disabled)
     Active: active (listening) since Thu 2023-06-01 09:50:11 EDT; 6min ago
      Until: Thu 2023-06-01 09:50:11 EDT; 6min ago
   Triggers: * virtproxyd.service
     Listen: [::]:16514 (Stream)
      Tasks: 0 (limit: 48952)
     Memory: 8.0K
        CPU: 1ms
     CGroup: /system.slice/virtproxyd-tls.socket

Jun 01 09:50:11 localhost.localdomain systemd[1]: Listening on Libvirt proxy TLS IP socket.
[root@localhost ~]# rpm -q libvirt
libvirt-9.3.0-2.el9.x86_64

And it did not get disabled.

Not in units, nothing custom. Version(s) I did mentioned.
Please ask specifically what you want me to provide - I'll try my best to help.

Take a look at this, here is a snippet from '--scripts':
specifically for: 
...
postinstall scriptlet (using /bin/sh):
 
if [ $1 -eq 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then 
    # Initial installation 
    /usr/lib/systemd/systemd-update-helper install-system-units virtproxyd.socket virtproxyd-ro.socket virtproxyd-admin.socket virtproxyd-tls.socket virtproxyd-tcp.socket virtproxyd.service || : 
fi
...

Now, trying to reproduce that, manually:

-> $ /usr/lib/systemd/systemd-update-helper remove-system-units virtproxyd.service virtproxyd-ro.socket virtproxyd-admin.socket virtproxyd-tls.socket virtproxyd-tcp.socket virtproxyd.socket
Removed "/etc/systemd/system/sockets.target.wants/virtproxyd.socket".
Removed "/etc/systemd/system/sockets.target.wants/virtproxyd-tls.socket".

-> $ systemctl status -l virtproxyd-tls.socket 
○ virtproxyd-tls.socket - Libvirt proxy TLS IP socket
     Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; enabled; preset: disabled)

now:
-> $ systemctl daemon-reload  # which happens when os reboots, which was how I found it all.

-> $ systemctl status -l virtproxyd-tls.socket 
○ virtproxyd-tls.socket - Libvirt proxy TLS IP socket
     Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; disabled; preset: disabled)

(In reply to Peter Krempa from comment #1)
> Could you please elaborate?
> 
> Which unit got disabled?

this we know, that's virtproxyd-tls.socket

> What was the version you upgraded from?  I presume 'libvirt-daemon-driver-qemu-9.3.0-2.el9.x86_64' is the one you upgraded to.

Still missing the version you updated from.

> Did you have any specific manual setup?

Even properly filling in the bug template would answer this.

(In reply to lejeczek from comment #5)
> Take a look at this, here is a snippet from '--scripts':
> specifically for: 
> ...
> postinstall scriptlet (using /bin/sh):
>  
> if [ $1 -eq 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then 
>     # Initial installation 

This is only when installing previously not installed package.

>     /usr/lib/systemd/systemd-update-helper install-system-units
> virtproxyd.socket virtproxyd-ro.socket virtproxyd-admin.socket
> virtproxyd-tls.socket virtproxyd-tcp.socket virtproxyd.service || : 
> fi
> ...
> 
> Now, trying to reproduce that, manually:
> 
> -> $ /usr/lib/systemd/systemd-update-helper remove-system-units
> virtproxyd.service virtproxyd-ro.socket virtproxyd-admin.socket
> virtproxyd-tls.socket virtproxyd-tcp.socket virtproxyd.socket
> Removed "/etc/systemd/system/sockets.target.wants/virtproxyd.socket".
> Removed "/etc/systemd/system/sockets.target.wants/virtproxyd-tls.socket".
> 

You remove the units, effectively disabling them,

> -> $ systemctl status -l virtproxyd-tls.socket 
> ○ virtproxyd-tls.socket - Libvirt proxy TLS IP socket
>      Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket; enabled;
> preset: disabled)
> 
> now:
> -> $ systemctl daemon-reload  # which happens when os reboots, which was how
> I found it all.
> 

then you reload the daemon,

> -> $ systemctl status -l virtproxyd-tls.socket 
> ○ virtproxyd-tls.socket - Libvirt proxy TLS IP socket
>      Loaded: loaded (/usr/lib/systemd/system/virtproxyd-tls.socket;
> disabled; preset: disabled)

and then the unit is disabled.  I don't see what you want to show here, sorry.

What I showed were obvious snippets & I was saying that that what upgrade did/does.
Part(s) scriptlets probably happened, took place - I most likely was using penultimate release to this latest one - as I think I see 'libvirt-daemon-proxy' being a "brand-new" introduction package in the 9.3.0-2.el9

It reproduces in my lab - when I downgrade, repos supply me with 9.0.0-7.el9 version.
I have:
libvirt-libs-9.0.0-7.el9.x86_64
libvirt-client-9.0.0-7.el9.x86_64
libvirt-daemon-9.0.0-7.el9.x86_64
libvirt-daemon-driver-storage-core-9.0.0-7.el9.x86_64
libvirt-daemon-driver-network-9.0.0-7.el9.x86_64
libvirt-daemon-driver-nwfilter-9.0.0-7.el9.x86_64
libvirt-daemon-config-nwfilter-9.0.0-7.el9.x86_64
libvirt-daemon-config-network-9.0.0-7.el9.x86_64
libvirt-daemon-driver-storage-disk-9.0.0-7.el9.x86_64
libvirt-daemon-driver-storage-iscsi-9.0.0-7.el9.x86_64
libvirt-daemon-driver-storage-logical-9.0.0-7.el9.x86_64
libvirt-daemon-driver-storage-mpath-9.0.0-7.el9.x86_64
libvirt-daemon-driver-storage-rbd-9.0.0-7.el9.x86_64
libvirt-daemon-driver-storage-scsi-9.0.0-7.el9.x86_64
libvirt-daemon-driver-storage-9.0.0-7.el9.x86_64
libvirt-daemon-driver-interface-9.0.0-7.el9.x86_64
libvirt-daemon-driver-nodedev-9.0.0-7.el9.x86_64
libvirt-daemon-driver-qemu-9.0.0-7.el9.x86_64
libvirt-daemon-driver-secret-9.0.0-7.el9.x86_64
libvirt-9.0.0-7.el9.x86_64

I upgrade, having that "older" version up & running, both 'virtproxyd.socket' & 'virtproxyd-tls.socket' enabled & up and immediately - after successful update - I find: virtproxyd-tls.socket - DISABLED.

OK, now we're getting somewhere, thank you.

So virtproxyd was split from libvirt-daemon into libvirt-daemon-proxy since v9.1.0.  When updating libvirt from older version the new package libvirt-daemon-proxy gets installed.  And since from that package's point of view (or more precisely from the scriptlet) it is not visible that this is an update rather than an install.  So the scriptlet runs systemd_post which bubbles down to:

  systemd preset --no-reload preset virtproxyd.socket virtproxyd-ro.socket virtproxyd-admin.socet virtproxyd-tls.socket virtproxyd-tcp.socket virtproxyd.service

which would not happen on further updates.

However the system preset is to disable everything not explicitly listed as enabled (see /usr/lib/systemd/system-preset/99-default-disable.preset) and hence the enabled service gets disabled.

Since this is deciphered we can talk about the possibilities.

One thing would be to not use %systemd_post for this unit and maybe all other -tls.socket units.  That would violate the untold premise of using presets for systemd units.
Another could be to not include the "disable *" in the distro package.  I'm not sure what the reason is behind that and I'm not the right one to say.
The last one would be to "just let it go", but since RHEL 9.2 does not have the new package yet and we have some time until RHEL 9.3 is released, so I think one of the first two is the right way to go.

I'll try to propose the change upstream and will see where does the discussion take us.

Patches posted upstream.

https://listman.redhat.com/archives/libvir-list/2023-July/240723.html

Patches pushed upstream.

  commit a7bc8d16062c786eae298b3db3ee2f0d06b12151
  Author: Andrea Bolognani <abologna>
  Date:   Wed Jul 5 18:48:32 2023 +0200

    rpm: Switch to new macros for handling of systemd units
    
    In most cases the replacement is straightforward, with the
    biggest difference being that we now schedule restarts during
    %pre instead of %post. This also means that we can get rid of
    %post for most packages, reducing the number of scriptlets that
    need to run during install/upgrade.
    
    Notable exceptions are libvirt-guests.service, where we stop
    using the standard systemd macros to adopt our custom ones, as
    well as the virtlogd and virtlockd services, where the reload
    operation is moved from %postun to %posttrans.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=2210058
    
    Signed-off-by: Andrea Bolognani <abologna>
    Reviewed-by: Martin Kletzander <mkletzan>

  commit 3bfc76a953c24793c2193768cca68d428490c01a
  Author: Andrea Bolognani <abologna>
  Date:   Wed Jul 5 18:07:34 2023 +0200

    rpm: Introduce new macros for handling of systemd units
    
    systemd provides a number of standard RPM macros but they don't
    quite satisfy our requirements, as evidenced by the fact that we
    have already built some custom tooling around them.
    
    Scenarios that the standard macros don't cover and that we're
    already addressing with our custom ones:
    
      * for some services (libvirtd, virtnetworkd, virtnwfilterd)
        there are multiple conditions that might lead to a restart,
        and we want to make sure that they're not needlessly
        restarted several times per transaction;
    
      * some services (virtlogd, virtlockd) must not be restarted
        during upgrade, so we have to reload them instead.
    
    Issues that neither the standard macros nor our custom ones
    address:
    
      * presets for units should be applied when the unit is first
        installed, not when the package that contains it is.
    
    The package split that happened in 9.1.0 highlighted why this
    last point is so important: when virtproxyd and its sockets
    were moved from libvirt-daemon to the new libvirt-daemon-proxy
    package, upgrades from 9.0.0 caused presets for them to be
    applied.
    
    On a platform such as Fedora, where modular daemons are the
    default, this has resulted in breaking existing deployments in
    at least two scenarios.
    
    The first one is machines that were configured to use the
    monolithic daemon, either because the local admin had manually
    changed the configuration or because the installation dated
    back to before modular daemons had become the default. In this
    case, virtproxyd.socket being enabled resulted in a silent
    conflict with libvirtd.socket, which by design shares the same
    path, and thus a completely broken setup.
    
    The second one is machines where virtproxy-tls.socket, which is
    disabled by default, had manually been enabled: in this case,
    applying the presets resulted in it being disabled and thus a
    loss of remote availability.
    
    Note that these are just two concrete scenarios, but the problem
    is more generic. For example, if we were to add more units to an
    existing package, per the current approach they wouldn't have
    their presets applied.
    
    The new macros are designed to avoid all of the pitfalls
    mentioned above. As a bonus, they're also simpler to use: where
    the current approach requires restarts and other operations to
    be handled separately, the new one integrates the two so that,
    for each scriptlet, a single macro call is needed.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=2210058
    
    Signed-off-by: Andrea Bolognani <abologna>
    Reviewed-by: Martin Kletzander <mkletzan>

  v9.6.0-rc1-8-ga7bc8d1606

CentOS Stream 9 backport prepared.

  https://gitlab.com/redhat/centos-stream/src/libvirt/-/merge_requests/8

This was reviewed by the RHEL voting members and approved.

Reproduced with libvirt-daemon-9.5.0-5.el9.x86_64.

Steps:
1.Install libvirt 9.0.0-10.3.el9_2.x86_64 pkgs

2.Check the default enabled status of virtproxyd{,-tcp, -tls}.socket:
# for drv in virtproxyd{,-tcp,-tls}; do systemctl is-enabled ${drv}.socket ; done
enabled
disabled
disabled

2.Disable virtproxyd.socket, enable virtproxyd-tcpsocket,virtproxyd-tls.socket:
#systemctl disable virtproxyd.socket
#systemctl enable virtproxyd-tcp.socket
#systemctl enable virtproxyd-tls.socket

3.Check the enabled status of virtproxyd*.socket again:
# for drv in virtproxyd{,-tcp,-tls}; do systemctl is-enabled ${drv}.socket ; done
enabled
disabled
disabled

4.Upgrade to libvirt 9.5.0-5:
# yum -y upgrade libvirt*9.5.0-5*
...
 Running scriptlet: libvirt-daemon-proxy-9.5.0-5.el9.x86_64                                                              7/95 
Removed "/etc/systemd/system/sockets.target.wants/virtproxyd-tcp.socket".
Removed "/etc/systemd/system/sockets.target.wants/virtproxyd-tls.socket".
Created symlink /etc/systemd/system/sockets.target.wants/virtproxyd.socket → /usr/lib/systemd/system/virtproxyd.socket.
...

5.Check the enabled status of virtproxyd*.socket, all the service were preset after step 4:
# for drv in virtproxyd{,-tcp,-tls}; do systemctl is-enabled ${drv}.socket ; done
enabled
disabled
disabled

Pre-verified with libvirt-9.5.0-6.el9.x86_64.

Test steps are the same as comment #22, and the virtproxyd*.socket service are not preset after upgrading to libvirt-9.5.0-6.el9.x86_64.

(In reply to yafu from comment #22)
> 2.Disable virtproxyd.socket, enable virtproxyd-tcpsocket,virtproxyd-tls.socket:
> #systemctl disable virtproxyd.socket
> #systemctl enable virtproxyd-tcp.socket
> #systemctl enable virtproxyd-tls.socket
> 
> 3.Check the enabled status of virtproxyd*.socket again:
> # for drv in virtproxyd{,-tcp,-tls}; do systemctl is-enabled ${drv}.socket ; done
> enabled
> disabled
> disabled

This was a copy-paste error, right? Based on the command you executed
immediately before this one, the output should have been

  disabled
  enabled
  enabled

instead.

(In reply to Andrea Bolognani from comment #24)
> (In reply to yafu from comment #22)
> > 2.Disable virtproxyd.socket, enable virtproxyd-tcpsocket,virtproxyd-tls.socket:
> > #systemctl disable virtproxyd.socket
> > #systemctl enable virtproxyd-tcp.socket
> > #systemctl enable virtproxyd-tls.socket
> > 
> > 3.Check the enabled status of virtproxyd*.socket again:
> > # for drv in virtproxyd{,-tcp,-tls}; do systemctl is-enabled ${drv}.socket ; done
> > enabled
> > disabled
> > disabled
> 
> This was a copy-paste error, right? Based on the command you executed
> immediately before this one, the output should have been
> 
>   disabled
>   enabled
>   enabled
> 
> instead.

Yes, it should be the following output after step3:
disabled 
enabled
enabled 

Thanks for pointing it.

Hi Andrea,

I found the default enabled status of virtqemud.socket is 'disabled' with libvirt-9.5.0-6.el9.x86_64 
while the default enabled status of virtqemud.socke is 'enabled' with libvirt-9.0.0-10.el9_2.x86_64. 
Could you help to check it please. Thanks.

(In reply to yafu from comment #26)
> Hi Andrea,
> 
> I found the default enabled status of virtqemud.socket is 'disabled' with
> libvirt-9.5.0-6.el9.x86_64 
> while the default enabled status of virtqemud.socke is 'enabled' with
> libvirt-9.0.0-10.el9_2.x86_64. 
> Could you help to check it please. Thanks.

Is this from a new installation, or an upgrade? If the latter, what
was the status of the socket before performing the upgrade?

I have just tried installing libvirt 9.7.0 on Fedora 38 (the systemd
unit handling code is exactly the same) and it behaves the way I
expect:

    Running scriptlet: libvirt-daemon-driver-qemu-9.7.0-1.fc38.x86_64
  Created symlink /etc/systemd/system/multi-user.target.wants/virtqemud.service → /usr/lib/systemd/system/virtqemud.service.
  Created symlink /etc/systemd/system/sockets.target.wants/virtlogd.socket → /usr/lib/systemd/system/virtlogd.socket.
  Created symlink /etc/systemd/system/sockets.target.wants/virtlockd.socket → /usr/lib/systemd/system/virtlockd.socket.
  Created symlink /etc/systemd/system/sockets.target.wants/virtqemud.socket → /usr/lib/systemd/system/virtqemud.socket.
  Created symlink /etc/systemd/system/sockets.target.wants/virtqemud-ro.socket → /usr/lib/systemd/system/virtqemud-ro.socket.
  Created symlink /etc/systemd/system/sockets.target.wants/virtqemud-admin.socket → /usr/lib/systemd/system/virtqemud-admin.socket.

After installation, the status for virtqemud and its sockets is the
expected one too:

  $ systemctl list-unit-files | grep virtqemud
  virtqemud.service                          enabled         enabled
  virtqemud-admin.socket                     enabled         disabled
  virtqemud-ro.socket                        enabled         disabled
  virtqemud.socket                           enabled         disabled

(In reply to Andrea Bolognani from comment #27)
> (In reply to yafu from comment #26)
> > Hi Andrea,
> > 
> > I found the default enabled status of virtqemud.socket is 'disabled' with
> > libvirt-9.5.0-6.el9.x86_64 
> > while the default enabled status of virtqemud.socke is 'enabled' with
> > libvirt-9.0.0-10.el9_2.x86_64. 
> > Could you help to check it please. Thanks.
> 
> Is this from a new installation, or an upgrade? If the latter, what
> was the status of the socket before performing the upgrade?
> 
> I have just tried installing libvirt 9.7.0 on Fedora 38 (the systemd
> unit handling code is exactly the same) and it behaves the way I
> expect:
> 
>     Running scriptlet: libvirt-daemon-driver-qemu-9.7.0-1.fc38.x86_64
>   Created symlink
> /etc/systemd/system/multi-user.target.wants/virtqemud.service →
> /usr/lib/systemd/system/virtqemud.service.
>   Created symlink /etc/systemd/system/sockets.target.wants/virtlogd.socket →
> /usr/lib/systemd/system/virtlogd.socket.
>   Created symlink /etc/systemd/system/sockets.target.wants/virtlockd.socket
> → /usr/lib/systemd/system/virtlockd.socket.
>   Created symlink /etc/systemd/system/sockets.target.wants/virtqemud.socket
> → /usr/lib/systemd/system/virtqemud.socket.
>   Created symlink
> /etc/systemd/system/sockets.target.wants/virtqemud-ro.socket →
> /usr/lib/systemd/system/virtqemud-ro.socket.
>   Created symlink
> /etc/systemd/system/sockets.target.wants/virtqemud-admin.socket →
> /usr/lib/systemd/system/virtqemud-admin.socket.
> 
> After installation, the status for virtqemud and its sockets is the
> expected one too:
> 
>   $ systemctl list-unit-files | grep virtqemud
>   virtqemud.service                          enabled         enabled
>   virtqemud-admin.socket                     enabled         disabled
>   virtqemud-ro.socket                        enabled         disabled
>   virtqemud.socket                           enabled         disabled


I checked it again on a new installed env. And the status for virtqemud* 
services are the same as you pasted above.

So I checked the history, I found I executed 'virsh preset virtqemud.socket' manually 
and then I found the default status of virtqemud.socket became to 'disabled' after
upgrading libvirt pkgs. 
# systemctl preset virtqemud.socket
Removed "/etc/systemd/system/sockets.target.wants/virtqemud.socket".

So it's the expected result, right?

(In reply to yafu from comment #28)
> (In reply to Andrea Bolognani from comment #27)
> >   $ systemctl list-unit-files | grep virtqemud
> >   virtqemud.service                          enabled         enabled
> >   virtqemud-admin.socket                     enabled         disabled
> >   virtqemud-ro.socket                        enabled         disabled
> >   virtqemud.socket                           enabled         disabled
> 
> I checked it again on a new installed env. And the status for virtqemud* 
> services are the same as you pasted above.

Okay, that's good :)

> So I checked the history, I found I executed 'virsh preset
> virtqemud.socket' manually and then I found the default status of
> virtqemud.socket became to 'disabled' after upgrading libvirt pkgs. 
>
> # systemctl preset virtqemud.socket
> Removed "/etc/systemd/system/sockets.target.wants/virtqemud.socket".

Yeah, the preset for most sockets is to be disabled, which is
confusing but ultimately not a problem.

In the case of virtqemud, for example, we have

  $ cat /usr/lib/systemd/system/virtqemud.service
  ...
  [Install]
  Also=virtlogd.socket
  Also=virtlockd.socket
  Also=virtqemud.socket
  Also=virtqemud-ro.socket
  Also=virtqemud-admin.socket

All the sockets listed as Also= are automatically enabled when
virtqemud.service is, so it all works fine in the end.

> So it's the expected result, right?

In your case, you applied the preset for virtqemud.socket, which
disabled it. Then ran the upgrade, which didn't touch any of the
settings for existing units. In this scenario, it's expected that
after the upgrade virtqemud.socket would be disabled.

(In reply to Andrea Bolognani from comment #29)
> Yeah, the preset for most sockets is to be disabled, which is
> confusing but ultimately not a problem.
> 
> In the case of virtqemud, for example, we have
> 
>   $ cat /usr/lib/systemd/system/virtqemud.service
>   ...
>   [Install]
>   Also=virtlogd.socket
>   Also=virtlockd.socket
>   Also=virtqemud.socket
>   Also=virtqemud-ro.socket
>   Also=virtqemud-admin.socket
> 
> All the sockets listed as Also= are automatically enabled when
> virtqemud.service is, so it all works fine in the end.

I have now created a pull request against the Fedora package that
ships the systemd presets to try and make things less confusing.

https://src.fedoraproject.org/rpms/fedora-release/pull-request/281

(In reply to Andrea Bolognani from comment #30)
> (In reply to Andrea Bolognani from comment #29)
> > Yeah, the preset for most sockets is to be disabled, which is
> > confusing but ultimately not a problem.
> > 
> > In the case of virtqemud, for example, we have
> > 
> >   $ cat /usr/lib/systemd/system/virtqemud.service
> >   ...
> >   [Install]
> >   Also=virtlogd.socket
> >   Also=virtlockd.socket
> >   Also=virtqemud.socket
> >   Also=virtqemud-ro.socket
> >   Also=virtqemud-admin.socket
> > 
> > All the sockets listed as Also= are automatically enabled when
> > virtqemud.service is, so it all works fine in the end.
> 
> I have now created a pull request against the Fedora package that
> ships the systemd presets to try and make things less confusing.
> 
> https://src.fedoraproject.org/rpms/fedora-release/pull-request/281

Thanks for your quick reply. Do we need to cover this pr in the bug?

(In reply to yafu from comment #31)
> (In reply to Andrea Bolognani from comment #30)
> > I have now created a pull request against the Fedora package that
> > ships the systemd presets to try and make things less confusing.
> > 
> > https://src.fedoraproject.org/rpms/fedora-release/pull-request/281
> 
> Thanks for your quick reply. Do we need to cover this pr in the bug?

No, that won't be necessary. I will make things nicer for libvirt
users who want to change their machine's configuration from the
default, but the RPM macros introduced in the patches fixing this bug
are carefully written so that the correct behavior will occur even
with the current systemd presets.

(In reply to Andrea Bolognani from comment #32)
> (In reply to yafu from comment #31)
> > (In reply to Andrea Bolognani from comment #30)
> > > I have now created a pull request against the Fedora package that
> > > ships the systemd presets to try and make things less confusing.
> > > 
> > > https://src.fedoraproject.org/rpms/fedora-release/pull-request/281
> > 
> > Thanks for your quick reply. Do we need to cover this pr in the bug?
> 
> No, that won't be necessary. I will make things nicer for libvirt
> users who want to change their machine's configuration from the
> default, but the RPM macros introduced in the patches fixing this bug
> are carefully written so that the correct behavior will occur even
> with the current systemd presets.

Got it. Thanks.

(In reply to Andrea Bolognani from comment #30)
> (In reply to Andrea Bolognani from comment #29)
> > Yeah, the preset for most sockets is to be disabled, which is
> > confusing but ultimately not a problem.
> > 
> > In the case of virtqemud, for example, we have
> > 
> >   $ cat /usr/lib/systemd/system/virtqemud.service
> >   ...
> >   [Install]
> >   Also=virtlogd.socket
> >   Also=virtlockd.socket
> >   Also=virtqemud.socket
> >   Also=virtqemud-ro.socket
> >   Also=virtqemud-admin.socket
> > 
> > All the sockets listed as Also= are automatically enabled when
> > virtqemud.service is, so it all works fine in the end.
> 
> I have now created a pull request against the Fedora package that
> ships the systemd presets to try and make things less confusing.
> 
> https://src.fedoraproject.org/rpms/fedora-release/pull-request/281

Filed a bug in JIRA to track this issue:
https://issues.redhat.com/browse/RHEL-3231

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: libvirt security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:6409