2:52 a.m.
Thank you Didi,
We'll look for an alternative, maybe even migrate to the more recent,
supported version.
That would be the best option IMO.
Best regards,
-rodri
On 9/16/20 9:39 AM, Yedidyah Bar David wrote:
Hi!
On Wed, Sep 16, 2020 at 10:25 AM Rodrigo G. López <r.gonzalez(a)telfy.com> wrote:
> Hello,
>
> Any idea about this problem? I don't know if the email got through to the list.
It did
> Should I join the #vdsm channel and discuss it there? Is there any other place
specific to vdsm where I could report this?
You are welcome to join #ovirt channel, but I think the list is ok as well.
>
>
> Cheers,
>
> -rodri
>
>
> On 9/15/20 9:55 AM, Rodrigo G. López wrote:
>
> Hi there,
>
> We are trying to setup a node in the same machine where we are running the engine,
This is called "all-in-one". It used to be supported until 3.6, and
removed from 4.0 and later.
> and noticed that the vdsmd service fails because the supervdsmd daemon can't
authenticate against libvirtd afaict.
>
> The error is the following on supervdsmd:
>
> daemonAdapter[17803]: libvirt: XML-RPC error : authentication failed:
authentication failed
> ...
>
> and in libvirtd:
>
> Sep 15 03:34:18 ovirt-test libvirtd[17775]: 2020-09-15 07:34:18.410+0000: 17775:
error : virNetSocketReadWire:1806 : End of file while reading data: Input/output error
> Sep 15 03:34:18 ovirt-test libvirtd[17775]: 2020-09-15 07:34:18.612+0000: 17776:
error : virNetSASLSessionListMechanisms:393 : internal error: cannot list SASL mechanisms
-4 (SASL(-4): no mechanism available: Internal Error -4 in server.c near line 1757)
> Sep 15 03:34:18 ovirt-test libvirtd[17775]: 2020-09-15 07:34:18.612+0000: 17776:
error : remoteDispatchAuthSaslInit:3440 : authentication failed: authentication failed
> Sep 15 03:34:18 ovirt-test libvirtd[17775]: 2020-09-15 07:34:18.612+0000: 17775:
error : virNetSocketReadWire:1806 : End of file while reading data: Input/output error
> Sep 15 03:34:18 ovirt-test libvirtd[17775]: 2020-09-15 07:34:18.814+0000: 17778:
error : virNetSASLSessionListMechanisms:393 : internal error: cannot list SASL mechanisms
-4 (SASL(-4): no mechanism available: Internal Error -4 in server.c near line 1757)
> Sep 15 03:34:18 ovirt-test libvirtd[17775]: 2020-09-15 07:34:18.814+0000: 17778:
error : remoteDispatchAuthSaslInit:3440 : authentication failed: authentication failed
> Sep 15 03:34:18 ovirt-test libvirtd[17775]: 2020-09-15 07:34:18.815+0000: 17775:
error : virNetSocketReadWire:1806 : End of file while reading data: Input/output error
> Sep 15 03:34:19 ovirt-test libvirtd[17775]: 2020-09-15 07:34:19.017+0000: 17780:
error : virNetSASLSessionListMechanisms:393 : internal error: cannot list SASL mechanisms
-4 (SASL(-4): no mechanism available: Internal Error -4 in server.c near line 1757)
> Sep 15 03:34:19 ovirt-test libvirtd[17775]: 2020-09-15 07:34:19.017+0000: 17780:
error : remoteDispatchAuthSaslInit:3440 : authentication failed: authentication failed
> Sep 15 03:34:19 ovirt-test libvirtd[17775]: 2020-09-15 07:34:19.020+0000: 17775:
error : virNetSocketReadWire:1806 : End of file while reading data: Input/output error
>
>
> Is there any way to work around that?
>
> We have working infra on top of 4.0 in CentOS 7 systems, and we would like to
replicate the exact same environment for availability purposes, in case anything bad
happened.
4.0 is old and unsupported.
I suggest to try 4.4.
You can try checking your existing setup and try to see if someone
made there specific customizations to make this work. Or perhaps you
have site-wide policy that is changing your configuration a bit (e.g.
around libvirt)?
That said, people do report occasionally that all-in-one still works,
and we even fixed a bug for it in imageio recently. That said, it's
still considered unsupported, and the "official" answer is "Use
hosted-engine (with gluster), aka HCI" (or do not use oVirt at all -
there isn't much advantage in it for a single host, compared e.g. with
virt-manager).
Best regards,