Thanks. That helped me get past the FQDN issue. However, I'm now running into another problem that I think its related to this non-issue RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1833421 I'm attaching the ansible log to this email. (Is there a better way to provide log files?) The responses to the bugzilla make it sound like a second, unused, disk, is required. Is that the case? Reviewing https://www.ovirt.org/documentation/gluster-hyperconverged/chap-Single_node_..., I don't see any mention about a separate disk device being a requirement. For purposes of my testing, I was simply expecting the installer to create new directories in the root of the existing server. I tried manually creating the paths, but that didn't work either: [root@dev1-centos gluster_bricks]# mkdir -p /gluster_bricks/engine/engine [root@dev1-centos gluster_bricks]# mkdir -p /gluster_bricks/data/data [root@dev1-centos gluster_bricks]# mkdir -p /gluster_bricks/vmstore/vmstore I have two hard drives in this server, but they are currently in a RAID. For testing purposes, do I need to destroy the RAID, install onto 1 drive, and use the 2nd drive for the data? And is this basically what I should expect for a 3-node deployment as well? Make sure I have two different devices, 1 for the host OS and 1 for the data? Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, August 26, 2020 5:41 AM, David White via Users <users@ovirt.org> wrote:

...

I assume you follow: https://www.ovirt.org/documentation/gluster-hyperconverged/chap-Single_node_... It says you must configure passwordless ssh from the host to itself. Did you do this?

You gave me too much credit. My mistake. I did NOT setup passwordless ssh, and I also failed to setup RDNS for the host.

I will try that this evening and report back.

...

Please try to quote errors accurately next time, it makes it much easier to find them in the code.

I'll be sure to do that.

Thank you!

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, August 26, 2020 3:32 AM, Yedidyah Bar David didi@redhat.com wrote:

...

On Wed, Aug 26, 2020 at 2:32 AM David White via Users users@ovirt.org wrote:

...

...

In a recent thread, Roberto mentioned seeing the error message "FQDN Not Reachable" when trying to deploy oVirt Node 4.4.1, but was able to get past that error when using ovirt-node-ng-installer-4.4.2-2020080612.el8.iso. I experienced the same problems on oVirt Node install 4.4.1, so I tried the latest release of 4.4.2. When that failed, I went back and installed from the exact same image as Roberto said worked on the 4.4.2 branch: ovirt-node-ng-installer-4.4.2-2020080612.el8.iso Unfortunately, that's still not working for me - so that tells me I'm probably doing something wrong. Given the following facts: [root@dev1-centos ~]# hostname dev1-centos.office.barredowlweb.com [root@dev1-centos ~]# host dev1-centos.office.barredowlweb.com dev1-centos.office.barredowlweb.com has address 192.168.2.96 I am trying to install oVirt using the Hyperconverged Gluster Wizard for a Single Node.

...

I assume you follow:

...

https://www.ovirt.org/documentation/gluster-hyperconverged/chap-Single_node_...

...

It says you must configure passwordless ssh from the host to itself. Did you do this?

...

...

In the "Host1" box, I enter the full hostname: dev1-centos.office.barredowlweb.com And that's when I get the FQDN error message.

...

I assume you refer to the error "FQDN is not reachable".

...

Please try to quote errors accurately next time, it makes it much easier to find them in the code.

...

AFAICT from reading the code, it emits this error if it fails to ssh to the provided name, among other tests:

...

https://github.com/oVirt/cockpit-ovirt/blob/master/dashboard/src/helpers/Ans...

...

...

Am I missing something here?

...

Please check/share relevant logs from /var/log on the host, if still not solved.

...

Thanks and best regards,

...

...

Sent with ProtonMail Secure Email.

...

...

Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/DERTVLGRNPJ4NK...

...

--

...

Didi

...

Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/J2VSIFHPUMDA4K...

Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/IBHB2K6YQCYDVS...

Just fresh from a single node HCI setup (CentOS 8 + oVirt 4.4.1) I did yesterday on an Intel i7-8559U NUC with a single 1TB NVMe storage stick and 64GB of RAM: The HCI wizard pretty much assumes a "second disk", but a partition will actually do. And it doesn't even have to be in /dev/mapper, even if the wizard seems to have some logic requiring that. But it requires a partition to be present, which you'll need to create (empty) by hand and which in my case was something like /dev/nvme0n1p10 where the wizard puts /dev/sdb. That's because the wizard will then try to put VDO on that storage, which requires a block layer underneath, and then puts thin allocation LVs on to of that for the ultimate flexibility and the ability to worry much more about performance than detail planning of storage allocations. And it needs to be really empty, if there is a file system or left-overs of one, the Wizard will fail with a not very helpful "device xx has been blacklisted" or similar. Of course, without the HCI (first choice you make in the Wizard), you can set up your storage, even with Gluster, in many other ways, but I've found it easier to stick with the HCI route, at least given the equipment I had (no SAN, no NFS filer).