[PATCH V4 06/11] spec: Move common files and dependencies to libvirt-daemon-common

Andrea Bolognani abologna at redhat.com
Tue Jan 3 18:58:29 UTC 2023


On Tue, Jan 03, 2023 at 10:07:45AM -0700, Jim Fehlig wrote:
> On 1/2/23 07:53, Andrea Bolognani wrote:
> > Remote clients can connect to modular daemons directly as long as
> > virt-ssh-helper is available on the server side. As a fallback, nc
> > will be used and the connection will go through virtproxyd.
> >
> > So yeah, nc will only be used when virtproxyd is involved, and so it
> > makes sense to move the Recommends to that package instead of
> > libvirt-daemon-common.
> >
> >
> > Based on the above, however, I wonder if we should have at least a
> > weak dependency on libvirt-daemon-proxy for libvirt-daemon-kvm and
> > friends? As things are right now, clients that are more than ~2 years
> > old will not be able to connect to the server unless the admin
> > manually installs libvirt-daemon-proxy. Are we okay with that?
>
> More specifically, clients prior to commit 3e9b561139 right? I.e., clients
> using libvirt 7.4.0 and older. I lean towards the weak dependency but don't
> have a strong opinion :-).

I get a bit confused about the exact timeline :) but I believe that
virt-ssh-helper was always able to connect to modular daemons
directly.

So if a client older than 6.9.0 (when virt-ssh-helper was introduced)
tries to connect, it will spawn netcat and go through virtproxyd;
newer clients will spawn virt-ssh-helper if available, which will
route the connection directly to the appropriate modular daemon.

-- 
Andrea Bolognani / Red Hat / Virtualization



More information about the libvir-list mailing list