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. 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. 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. 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. 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? 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. > 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]. 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. [1] https://libvirt.org/daemons.html#switching-to-modular-daemons [2] https://src.fedoraproject.org/rpms/fedora-release/blob/rawhide/f/90-default.preset -- Andrea Bolognani / Red Hat / Virtualization
