Hi,

When "nc" points to netcat-traditional on the server running libvirtd,
remote connections do not work:

$ virsh -c qemu+ssh://test list
nc: invalid option -- U
nc -h for help
error: server closed connection
error: failed to connect to the hypervisor

So either a "Conflicts: netcat-traditional" should be added, or libvirt
should call "nc.openbsd" directly instead of just "nc".

Gabor

That's why we do recommend netcat-openbsd but you're right explicitly
calling it makes more sense than failing.
Cheers,
 -- Guido

 -- Guido

Hi,
I ran into this problem today and would like to suggest a partial
resolution.
Upon installation, libvirt-bin should check whether netcat-openbsd is
the currently active alternative for netcat. In case it is not, a
warning should be displayed, informing the system administrator that
they will not be able to use remote SSH connections to the current
system unless they configure the client appropriately or update the
alternatives system accordingly.
Of course, it has the drawback of working only when libvirt-bin is
installed after an offending netcat which might have overridden the
settings, but it will at least catch some of the cases, instead of
looking like a bug in virt-manager or whatever frontend the client uses.
I'm convinced that this is the most sane solution at the moment.
Also, a trigger to notify libvirt-bin of installation of any netcat
could be utilized to warn the admin of a possible problem.

Dear Maintainer,
the problem is still there and debian seems to default to nc6, which
also isn't compatible.
What about changing the netcat path both on server and client side to
something like /usr/lib/libvirt/nc.libvirt and symlinking this to
nc.openbsd, which is a dependency on the daemon package, while the
client doesn't need to care about the server side implementation but can
expect a working binary in /usr/lib/libvirt/nc.libvirt?

with kind regards,
Alexander Schier