On 6/7/20 8:42 AM, Yedidyah Bar David wrote:
On Sun, Jun 7, 2020 at 4:07 PM Michael Thomas <w...@caltech.edu> wrote:

On 6/7/20 5:01 AM, Yedidyah Bar David wrote:
On Sat, Jun 6, 2020 at 8:42 PM Michael Thomas <w...@caltech.edu> wrote:

After a week of iterations, I finally found the problem.  I was setting 
'PermitRootLogin no' in the global section of the bare metal OS sshd_config, as 
we do on all of our servers.  Instead, PermitRootLogin is set to 
'without-password' in a match block to allow root logins only from a well-known 
set of hosts.

I understand that you meant to say that this is already working for
you, right? That you set it to allow without-password from some
addresses and that that was enough. If so:

Correct. Once I added the engine's IP to the Match block allowing root logins, it worked again.

Thanks for the report!

Can someone explain why setting 'PermitRootLogin no' in the sshd_config on the 
hypervisor OS would affect the hosted engine deployment?

Because the engine (running inside a VM) uses ssh as root to connect
to the host (in which the engine vm is running).

Would it be sufficient to set, on the host, 'PermitRootLogin
without-password' in a Match block that matches the ovirt management

Match Address
      PermitRootLogin without-password


Do you mean here to ask if is enough?

The engine VM's IP address should be enough. What this address is,
after deploy finishes, is of course up to you. During deploy it's by
default in libvirt's default network,, but can be
different if that's already in use by something else (e.g. a physical

BTW, I didn't test this myself. I do see in the code that it's
supposed to work. If you find a bug, please report one. Thanks.

I think the two problems that I ran into were:

* Lack of documentation about the requirement that the engine (whether self-hosted or standalone) be able to ssh into the bare metal hypervisor host over the ovirt management network using ssh keys.

* No clear error message in the logs describing why this was failing. The only errors I got were a timeout waiting for the host to be up, and a generic ""The system may not be provisioned according to the playbook results: please check the logs for the issue, fix accordingly or re-deploy from scratch.\n"

I'll file this as a documentation bug.

Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
List Archives: 

Reply via email to