one-deploy configures RHEL hosts to use the monolithic legacy libvirtd daemon and masks the virtqemud units.
However, not all socket units are masked, the modular virtproxyd socket units remain enabled.
Relevant file:
roles/kvm/tasks/libvirt.yml
The role currently masks:
- virtqemud.service
- virtqemud.socket
- virtqemud-admin.socket
- virtqemud-ro.socket
It does not handle the conflicting virtproxyd socket units.
Observed behavior
After rebooting host13, libvirtd.service and libvirtd.socket were inactive, despite both being enabled.
Meanwhile, the following units were enabled:
virtproxyd.socket
virtproxyd-ro.socket
virtproxyd-admin.socket
The systemd definitions reveal the conflict:
libvirtd.socket:
ListenStream=/run/libvirt/libvirt-sock
Service=libvirtd.service
virtproxyd.socket:
**Conflicts=libvirtd.socket**
After=libvirtd.socket
[Socket]
ListenStream=/run/libvirt/libvirt-sock
Service=virtproxyd.service
During boot, virtproxyd.socket became active and virtproxyd repeatedly attempted to contact the masked virtqemud daemon:
Failed to connect socket to
'/var/run/libvirt/virtqemud-sock-ro':
No such file or directory
Consequently, virsh could not connect to the hypervisor.
We manually started the monolithic daemon:
systemctl start libvirtd.socket
systemctl start libvirtd.service
This caused systemd to stop the conflicting virtproxyd sockets, and virsh immediately became functional.
We then disabled and masked:
virtproxyd.socket
virtproxyd-ro.socket
virtproxyd-admin.socket
A subsequent full reboot succeeded: libvirtd started automatically and virsh worked without manual intervention.
Expected behavior
When one-deploy selects monolithic libvirt, conflicting modular sockets must not be enabled or started.
Actual behavior
Both socket configurations remain enabled, allowing the modular proxy to prevent the monolithic daemon from becoming active during boot.
Please update the monolithic libvirt configuration in roles/kvm/tasks/libvirt.yml to disable and mask the conflicting virtproxyd sockets.
The implementation should also review the remaining modular libvirt units for consistency with the selected operating mode.
Progress Status
one-deploy configures RHEL hosts to use the monolithic legacy libvirtd daemon and masks the virtqemud units.
However, not all socket units are masked, the modular virtproxyd socket units remain enabled.
Relevant file:
roles/kvm/tasks/libvirt.ymlThe role currently masks:
It does not handle the conflicting virtproxyd socket units.
Observed behavior
After rebooting host13, libvirtd.service and libvirtd.socket were inactive, despite both being enabled.
Meanwhile, the following units were enabled:
The systemd definitions reveal the conflict:
During boot, virtproxyd.socket became active and virtproxyd repeatedly attempted to contact the masked virtqemud daemon:
Consequently, virsh could not connect to the hypervisor.
We manually started the monolithic daemon:
This caused systemd to stop the conflicting virtproxyd sockets, and virsh immediately became functional.
We then disabled and masked:
A subsequent full reboot succeeded: libvirtd started automatically and virsh worked without manual intervention.
Expected behavior
When one-deploy selects monolithic libvirt, conflicting modular sockets must not be enabled or started.
Actual behavior
Both socket configurations remain enabled, allowing the modular proxy to prevent the monolithic daemon from becoming active during boot.
Please update the monolithic libvirt configuration in roles/kvm/tasks/libvirt.yml to disable and mask the conflicting virtproxyd sockets.
The implementation should also review the remaining modular libvirt units for consistency with the selected operating mode.
Progress Status