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@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,