[ovirt-users] Re: hosted-engine --deploy fails after "Wait for the host to be up" task

2020-02-14 Thread Fredy Sanchez
Banner none
PrintMotd no

# systemctl restart sshd

If gluster installed successfully, you don't have to reinstall it.
Just run the hyperconverged install again from cockpit, and it will detect
the existing gluster install, and ask you if you want to re-use it;
re-using worked for me. Only thing I'd point out here is that gluster
didn't enable in my servers automagically; I had to enable it and start it
by hand before cockpit picked it up.
# systemctl enable glusterd --now
# systemctl status glusterd

Also,
# tail -f /var/log/secure
while the install is going will help you see if there's a problem with ssh,
other than the banners.

--
Fredy

On Fri, Feb 14, 2020 at 9:32 AM Florian Nolden  wrote:

>
> Am Fr., 14. Feb. 2020 um 12:21 Uhr schrieb Fredy Sanchez <
> fredy.sanc...@modmed.com>:
>
>> Hi Florian,
>>
>
>> In my case, Didi's suggestions got me thinking, and I ultimately traced
>> this to the ssh banners; they must be disabled. You can do this in
>> sshd_config. I do think that logging could be better for this issue, and
>> that the host up check should incorporate things other than ssh, even if
>> just a ping. Good luck.
>>
>> Hi Fredy,
>
> thanks for the reply.
>
> I just have to uncomment "Banners none" in the /etc/ssh/sshd_config on all
> 3 nodes, and run redeploy in the cockpit?
> Or have you also reinstalled the nodes and the gluster storage?
>
>> --
>> Fredy
>>
>> On Fri, Feb 14, 2020, 4:55 AM Florian Nolden  wrote:
>>
>>> I'also stuck with that issue.
>>>
>>> I have
>>> 3x  HP ProLiant DL360 G7
>>>
>>> 1x 1gbit => as control network
>>> 3x 1gbit => bond0 as Lan
>>> 2x 10gbit => bond1 as gluster network
>>>
>>> I installed on all 3 servers Ovirt Node 4.3.8
>>> configured the networks using cockpit.
>>> followed this guide for the gluster setup with cockpit:
>>> https://www.ovirt.org/documentation/gluster-hyperconverged/chap-Deploying_Hyperconverged.html
>>>
>>> the installed the hosted engine with cockpit ->:
>>>
>>> [ INFO ] TASK [ovirt.hosted_engine_setup : Wait for the host to be up]
>>> [ ERROR ] fatal: [localhost]: FAILED! => {"ansible_facts": {"ovirt_hosts": 
>>> [{"address": "x-c01-n01.lan.xilloc.com", "affinity_labels": [], 
>>> "auto_numa_status": "unknown", "certificate": {"organization": 
>>> "lan.xilloc.com", "subject": 
>>> "O=lan.xilloc.com,CN=x-c01-n01.lan.xilloc.com"}, "cluster": {"href": 
>>> "/ovirt-engine/api/clusters/3dff6890-4e7b-11ea-90cb-00163e6a7afe", "id": 
>>> "3dff6890-4e7b-11ea-90cb-00163e6a7afe"}, "comment": "", "cpu": {"speed": 
>>> 0.0, "topology": {}}, "device_passthrough": {"enabled": false}, "devices": 
>>> [], "external_network_provider_configurations": [], "external_status": 
>>> "ok", "hardware_information": {"supported_rng_sources": []}, "hooks": [], 
>>> "href": "/ovirt-engine/api/hosts/ded7aa60-4a5e-456e-b899-dd7fc25cc7b3", 
>>> "id": "ded7aa60-4a5e-456e-b899-dd7fc25cc7b3", "katello_errata": [], 
>>> "kdump_status": "unknown", "ksm": {"enabled": false}, 
>>> "max_scheduling_memory": 0, "memory": 0, "name": 
>>> "x-c01-n01.lan.xilloc.com", "network_attachments": [], "nics": [], 
>>> "numa_nodes": [], "numa_supported": false, "os": {"custom_kernel_cmdline": 
>>> ""}, "permissions": [], "port": 54321, "power_management": 
>>> {"automatic_pm_enabled": true, "enabled": false, "kdump_detection": true, 
>>> "pm_proxies": []}, "protocol": "stomp", "se_linux": {}, "spm": {"priority": 
>>> 5, "status": "none"}, "ssh": {"fingerprint": 
>>> "SHA256:lWc/BuE5WukHd95WwfmFW2ee8VPJ2VugvJeI0puMlh4", "port": 22}, 
>>> "statistics": [], "status": "non_responsive", 
>>> "storage_connection_extensions": [], "summary": {"total": 0}, "tags": [], 
>>> "transparent_huge_pages": {"

[ovirt-users] Re: hosted-engine --deploy fails after "Wait for the host to be up" task

2020-02-14 Thread Fredy Sanchez
Hi Florian,

In my case, Didi's suggestions got me thinking, and I ultimately traced
this to the ssh banners; they must be disabled. You can do this in
sshd_config. I do think that logging could be better for this issue, and
that the host up check should incorporate things other than ssh, even if
just a ping. Good luck.

--
Fredy

On Fri, Feb 14, 2020, 4:55 AM Florian Nolden  wrote:

> I'also stuck with that issue.
>
> I have
> 3x  HP ProLiant DL360 G7
>
> 1x 1gbit => as control network
> 3x 1gbit => bond0 as Lan
> 2x 10gbit => bond1 as gluster network
>
> I installed on all 3 servers Ovirt Node 4.3.8
> configured the networks using cockpit.
> followed this guide for the gluster setup with cockpit:
> https://www.ovirt.org/documentation/gluster-hyperconverged/chap-Deploying_Hyperconverged.html
>
> the installed the hosted engine with cockpit ->:
>
> [ INFO ] TASK [ovirt.hosted_engine_setup : Wait for the host to be up]
> [ ERROR ] fatal: [localhost]: FAILED! => {"ansible_facts": {"ovirt_hosts": 
> [{"address": "x-c01-n01.lan.xilloc.com", "affinity_labels": [], 
> "auto_numa_status": "unknown", "certificate": {"organization": 
> "lan.xilloc.com", "subject": "O=lan.xilloc.com,CN=x-c01-n01.lan.xilloc.com"}, 
> "cluster": {"href": 
> "/ovirt-engine/api/clusters/3dff6890-4e7b-11ea-90cb-00163e6a7afe", "id": 
> "3dff6890-4e7b-11ea-90cb-00163e6a7afe"}, "comment": "", "cpu": {"speed": 0.0, 
> "topology": {}}, "device_passthrough": {"enabled": false}, "devices": [], 
> "external_network_provider_configurations": [], "external_status": "ok", 
> "hardware_information": {"supported_rng_sources": []}, "hooks": [], "href": 
> "/ovirt-engine/api/hosts/ded7aa60-4a5e-456e-b899-dd7fc25cc7b3", "id": 
> "ded7aa60-4a5e-456e-b899-dd7fc25cc7b3", "katello_errata": [], "kdump_status": 
> "unknown", "ksm": {"enabled": false}, "max_scheduling_memory": 0, "memory": 
> 0, "name": "x-c01-n01.lan.xilloc.com", "network_attachments": [], "nics": [], 
> "numa_nodes": [], "numa_supported": false, "os": {"custom_kernel_cmdline": 
> ""}, "permissions": [], "port": 54321, "power_management": 
> {"automatic_pm_enabled": true, "enabled": false, "kdump_detection": true, 
> "pm_proxies": []}, "protocol": "stomp", "se_linux": {}, "spm": {"priority": 
> 5, "status": "none"}, "ssh": {"fingerprint": 
> "SHA256:lWc/BuE5WukHd95WwfmFW2ee8VPJ2VugvJeI0puMlh4", "port": 22}, 
> "statistics": [], "status": "non_responsive", 
> "storage_connection_extensions": [], "summary": {"total": 0}, "tags": [], 
> "transparent_huge_pages": {"enabled": false}, "type": "ovirt_node", 
> "unmanaged_networks": [], "update_available": false, "vgpu_placement": 
> "consolidated"}]}, "attempts": 120, "changed": false, "deprecations": 
> [{"msg": "The 'ovirt_host_facts' module has been renamed to 
> 'ovirt_host_info', and the renamed one no longer returns ansible_facts", 
> "version": "2.13"}]}
>
>
>
> What is the best approach now to install a Ovirt Hostedengine?
>
>
> Kind regards,
>
> *Florian Nolden*
>
> *Head of IT at Xilloc Medical B.V.*
>
> www.xilloc.com* “Get aHead with patient specific implants” *
>
> Xilloc Medical B.V., Urmonderbaan 22
> <https://maps.google.com/?q=Xilloc%20Medical+B.V.,+Urmonderbaan+22&entry=gmail&source=g>
>  Gate
> 2, Building 110, 6167 RD Sittard-Geleen
>
> —
>
> Disclaimer: The content of this e-mail, including any attachments, are
> confidential and are intended for the sole use of the individual or entity
> to which it is addressed. If you have received it by mistake please let us
> know by reply and then delete it from your system. Any distribution,
> copying or dissemination of this message is expected to conform to all
> legal stipulations governing the use of information.
>
>
> Am Mo., 27. Jan. 2020 um 07:56 Uhr schrieb Yedidyah B

[ovirt-users] hosted-engine --deploy fails after "Wait for the host to be up" task

2020-01-26 Thread Fredy Sanchez
*Hi all,*

*[root@bric-ovirt-1 ~]# cat /etc/*release**
CentOS Linux release 7.7.1908 (Core)
*[root@bric-ovirt-1 ~]# yum info ovirt-engine-appliance*
Installed Packages
Name: ovirt-engine-appliance
Arch: x86_64
Version : 4.3
Release : 20191121.1.el7
Size: 1.0 G
Repo: installed
>From repo   : ovirt-4.3

*Same situation as https://bugzilla.redhat.com/show_bug.cgi?id=1787267
. The error message
almost everywhere is some red herring message about ansible*
[ INFO  ] TASK [ovirt.hosted_engine_setup : Wait for the host to be up]
[ ERROR ] fatal: [localhost]: FAILED! => {"ansible_facts": {"ovirt_hosts":
[]}, "attempts": 120, "changed": false, "deprecations": [{"msg": "The
'ovirt_host_facts' module has been renamed to 'ovirt_host_info', and the
renamed one no longer returns ansible_facts", "version": "2.13"}]}
[ INFO  ] TASK [ovirt.hosted_engine_setup : Notify the user about a failure]
[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "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"}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing
ansible-playbook
[ INFO  ] Stage: Termination
[ ERROR ] Hosted Engine deployment failed: please check the logs for the
issue, fix accordingly or re-deploy from scratch.
  Log file is located at
/var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20200126170315-req4qb.log

*But the "real" problem seems to be SSH related, as you can see below*
*[root@bric-ovirt-1 ovirt-engine]# pwd*
/var/log/ovirt-hosted-engine-setup/engine-logs-2020-01-26T17:19:28Z/ovirt-engine
*[root@bric-ovirt-1 ovirt-engine]# grep -i error engine.log*
2020-01-26 17:26:50,178Z ERROR
[org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (default task-1)
[2341fd23-f0c7-4f1c-ad48-88af20c2d04b] Failed to establish session with
host 'bric-ovirt-1.corp.modmed.com': SSH session closed during connection '
r...@bric-ovirt-1.corp.modmed.com'
2020-01-26 17:26:50,205Z ERROR
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default
task-1) [] Operation Failed: [Cannot add Host. Connecting to host via SSH
has failed, verify that the host is reachable (IP address, routable address
etc.) You may refer to the engine.log file for further details.]

*The funny thing is that the engine can indeed ssh to bric-ovirt-1
(physical host). See below*

*[root@bric-ovirt-1 ovirt-hosted-engine-setup]# cat /etc/hosts*
192.168.1.52 bric-ovirt-engine.corp.modmed.com # temporary entry added by
hosted-engine-setup for the bootstrap VM
127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
#::1 localhost localhost.localdomain localhost6
localhost6.localdomain6
10.130.0.50 bric-ovirt-engine bric-ovirt-engine.corp.modmed.com
10.130.0.51 bric-ovirt-1 bric-ovirt-1.corp.modmed.com
10.130.0.52 bric-ovirt-2 bric-ovirt-2.corp.modmed.com
10.130.0.53 bric-ovirt-3 bric-ovirt-3.corp.modmed.com
192.168.0.1 bric-ovirt-1gluster bric-ovirt-1gluster.corp.modmed.com
192.168.0.2 bric-ovirt-2gluster bric-ovirt-2gluster.corp.modmed.com
192.168.0.3 bric-ovirt-3gluster bric-ovirt-3gluster.corp.modmed.com
[root@bric-ovirt-1 ovirt-hosted-engine-setup]#

*[root@bric-ovirt-1 ~]# ssh 192.168.1.52*
Last login: Sun Jan 26 17:55:20 2020 from 192.168.1.1
[root@bric-ovirt-engine ~]#
[root@bric-ovirt-engine ~]#
*[root@bric-ovirt-engine ~]# ssh bric-ovirt-1*
Password:
Password:
Last failed login: Sun Jan 26 18:17:16 UTC 2020 from 192.168.1.52 on
ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Sun Jan 26 18:16:46 2020
###
# UNAUTHORIZED ACCESS TO THIS SYSTEM IS PROHIBITED#
# #
# This system is the property of Modernizing Medicine, Inc.   #
# It is for authorized Company business purposes only.#
# All connections are monitored and recorded. #
# Disconnect IMMEDIATELY if you are not an authorized user!   #
###
[root@bric-ovirt-1 ~]#
[root@bric-ovirt-1 ~]#
[root@bric-ovirt-1 ~]# exit
logout
Connection to bric-ovirt-1 closed.
[root@bric-ovirt-engine ~]#
[root@bric-ovirt-engine ~]#
*[root@bric-ovirt-engine ~]# ssh bric-ovirt-1.corp.modmed.com
*
Password:
Last login: Sun Jan 26 18:17:22 2020 from 192.168.1.52
###
# UNAUTHORIZED ACCESS TO THIS SYSTEM IS PROHIBITED#
# #
# This system is the property of Modernizing Medicine, Inc.   #
# It is for authorized Company business purposes only.#
# All connections are monitored and recorded.

[ovirt-users] Is hosted engine supported in hosts with diff CPU types?

2016-08-17 Thread Fredy Sanchez
Hi all,

I am deploying hosted engine in what will hopefully become our 4th oVirt
cluster. The engine is up and running happily in host 1 already, but I am
running into the following when running hosted-engine --deploy in hosts 2
and 3:

The following CPU types are supported by this host:
  - model_Opteron_G3: AMD Opteron G3
  - model_Opteron_G2: AMD Opteron G2
  - model_Opteron_G1: AMD Opteron G1
[ ERROR ] Failed to execute stage 'Environment customization': Invalid CPU
type specified: model_SandyBridge

Host 1 has an Intel chip. Hosts 2 and 3 have an AMD chip. Is this a
supported config? If so, how can I bypass the error? Thank you very much.

Cheers,
Fredy
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] 3.6.1 hosted engine won't start after reboot

2016-01-05 Thread Fredy Sanchez
Thank you Simone, but I can't connect to the VM. It is up only for a few
seconds before rebooting.
On Jan 5, 2016 1:18 PM, "Simone Tiraboschi"  wrote:

>
>
> On Tue, Jan 5, 2016 at 7:06 PM, Fredy Sanchez 
> wrote:
>
>> I am also attaching /etc/ovirt-hosted-engine/hosted-engine.conf and
>> /var/run/ovirt-hosted-engine-ha/vm.conf
>>
>> Thank you again.
>>
>>
> In your case hosted-engine successfully starts the engine VM but than it
> fails checking the health of the ovirt-engine running inside that VM.
> Can you please check the status of ovirt-engine service connecting to your
> VM?
>
>
>> On Tue, Jan 5, 2016 at 12:59 PM, Fredy Sanchez 
>> wrote:
>>
>>> Hi list,
>>>
>>> Fresh install of 3.6.1 on CentOS 7.2 (physical host and engine vm).
>>> After a reboot, the engine vm will not come up. To be precise, the engine
>>> starts up, works for a few seconds, then reboots (see attached logs).
>>> Searching on the Internet seems that my problem is
>>>
>>> “After installation of the hosted-engine using the iso and commands you
>>> specified and rebooting the engine and registering the host in the engine,
>>> the engines network configuration is set to "managed by NetworkManager" but
>>> no NetworkManager is installed on the system. So the reboot will result in
>>> the loss of network connectivity and ha-agent trying to restart the
>>> hosted-engine in a loop.”
>>>
>>> Does anybody know if I can fix this on
>>> /var/run/ovirt-hosted-engine-ha/vm.conf or somewhere else?
>>> /var/log/ovirt-hosted-engine-ha/agent.log and
>>> /var/log/ovirt-hosted-engine-ha/broker.log haven’t been much help, even
>>> when set to debug mode.
>>>
>>> hosted-engine —vm-status says “Engine status : {"reason": "failed
>>> liveness check", "health": "bad", "vm": "up", "detail": "up”}”  Score is
>>> 3400.
>>>
>>> This is what I see in the logs:
>>>
>>> /var/log/ovirt-hosted-engine-ha/agent.log (attached)
>>>
>>> /var/log/ovirt-hosted-engine-ha/broker.log (attached)
>>>
>>> Thank you very much!
>>>
>>> --
>>> Fredy
>>>
>>>
>>
>>
>> --
>> Fredy
>>
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users