Hello, Any idea about this problem? I don't know if the email got through to the list.

Should I join the #vdsm channel and discuss it there? Is there any other place specific to vdsm where I could report this?

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,

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.

Hi! On Wed, Sep 16, 2020 at 10:25 AM Rodrigo G. López <r.gonzalez(a)telfy.com&gt; 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,