On 6/26/23 10:06, Andrea Bolognani wrote:
On Fri, Jun 16, 2023 at 03:57:37PM -0600, Jim Fehlig wrote:
On 6/16/23 02:12, Martin Kletzander wrote:
On Wed, Jun 14, 2023 at 04:45:06PM -0600, Jim Fehlig wrote:
On 6/9/23 03:05, Andrea Bolognani wrote:
Can we somehow enforce that libvirt-daemon is fully configured before
libvirt-daemon-proxy? If so, we could create a witness file based on
the information we need in libvirt-daemon's %post, look at it in
libvirt-daemon-proxy's %post and base our decision on that.
What would the witness file indicate? As I understand, it would essentially have
to indicate whether libvirtd sockets/service are enabled. If so, couldn't that
be done directly in virtproxy post script? Something like the below hack?
The current logic in all packages' %post scriptlet basically
translates to: if installing the package from scratch, apply the
systemd presets; if upgrading, leave things well alone.
What I would want the witness file to indicate would be:
libvirt-daemon is being upgraded, so when running the %post for
libvirt-daemon-proxy behave as in the upgrade scenario as opposed to
the install-from-scratch scenario.
Is it enough to know that libvirt-daemon is being upgraded? Do we also need to
know if libvirtd.service and any of the sockets are enabled? I think Martin
already suggested a solution along these lines
https://listman.redhat.com/archives/libvir-list/2023-June/240312.html
Detecting whether the monolithic libvirtd and its sockets are enabled
could also work, but feels more fragile. Specifically, it would not
cover the scenario described by Martin, where the deployment is a
split daemon one but with some units that are disabled by default
based on presets have been manually enabled by the admin.
Nod. I even apologized to Martin in another response for getting bogged down on
your issue :-).
The problem is that I'm not sure we can create and process such a
witness file reliably. Figuring that out requires research and
real-life testing :)
In an attempt to reproduce Andrea's report, I added the following presets to
/usr/lib/systemd/system-preset/90-default-openSUSE.preset
enable virtqemud.socket
enable virtlogd.socket
enable virtnetworkd.socket
enable virtnodedevd.socket
enable virtstoraged.socket
enable virtsecretd.socket
enable virtproxyd.socket
As before, installed packages without commit b1da03b5b3. I then disabled all
the virt* presets (with exception of virtlogd) and enabled libvirtd.socket.
I'm not sure this is entirely relevant, but just for completeness'
sake: in a monolithic daemon deployment, you want libvirtd.service in
addition to its sockets to be enabled. This is needed to make sure
domain autostart works as intended.
Thanks for the reminder! BTW, does the same apply for virtnetworkd and
virtstoraged, which also have resources that can be autostarted?
Basically, starting from a split daemon deployment, you want to
follow the steps outlined here[1] but in reverse.
After updating to packages containing commit b1da03b5b3, virtproxyd.socket
was still disabled and libvirt.socket was enabled. No problem connecting to
libvirtd, even after the service timeout.
I'll try to reproduce this myself later this week, but what you're
describing doesn't match my expectations: virtproxyd.socket should
have been enabled during installation.
I would have thought so too and was surprised by the results. That test was done
in a VM. I just did the same test on the host (freshly updated Tumbleweed) with
the same results.
Are the packages you're using for testing a direct rebuild of the
spec file shipped upstream? Or have you integrated the changes into
the openSUSE spec file somehow?
I've made the changes to the openSUSE Factory spec file, which closely tracks
the upstream one.
Note that the scriptlets in the upstream spec file call out to some
standard macros, and it's also possible that the implementation of
said macros is not the same across Fedora and openSUSE.
The openSUSE scriptlets use the 'service_add_pre' macro from the
systemd-rpm-macros package
https://build.opensuse.org/package/view_file/Base:System/systemd-rpm-macros/macros.systemd?expand=1
In the end, something like 'systemctl --no-reload preset $unit' is called.
Any tips on reproducing the issue? I must be missing something. What are the
libvirt-related presets in Fedora? I couldn't easily find them. FYI, the
Tumbleweed ones are here
https://build.opensuse.org/package/show/Base:System/systemd-presets-common-SUSE
https://build.opensuse.org/package/show/Base:System/systemd-presets-branding-openSUSE
They're part of the fedora-release package[2].
Thanks for the pointer and info!
Specifically, we have
# Virtualization driver specific daemons. Start by default at boot for VM
# autostart, but shutdown after 2 mins and socket activated thereafter
enable virtqemud.service
enable virtxend.service
enable virtlxcd.service
# Compatibility with libvirtd sockets for old clients and expose TCP sockets
enable virtproxyd.socket
# Secondary drivers providing supporting functionality to main virtualization
# drivers, socket activated only when required
enable virtinterfaced.socket
enable virtnetworkd.socket
enable virtnodedevd.socket
enable virtnwfilterd.socket
enable virtsecretd.socket
enable virtstoraged.socket
In the past I've never added libvirt services/sockets to the openSUSE
presets since users could easily enable libvirtd and virtlogd and be done
with it. (Note the SLES presets do enable libvirtd and virtlogd.) But it
becomes more burdensome with modular daemons, so I plan to add the above
presets (excluding virtproxyd) to the openSUSE defaults.
Are you okay with old(ish) clients not being able to connect to the
host? Because that's why the virtproxyd.socket is enabled by default
in Fedora: if the client predates the introduction of split daemons
it will try to connect to the old libvirtd socket, and in a split
daemons deployment they only way to make that work is by having
virtproxyd listening on it.
Understood, and I'm fine with that on Tumbleweed for the time being. It would be
interesting to hear complaints so I know there's demand for the use-case.
Regards,
Jim
