Sorry, I mistakenly send the email:
Below is the output of:
[root@glustermount ~]# systemctl status ovirt-imageio-daemon.service -l
● ovirt-imageio-daemon.service - oVirt ImageIO Daemon
Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-daemon.service;
disabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Tue 2018-09-04 16:55:16 SAST;
19h ago
Condition: start condition failed at Wed 2018-09-05 11:56:46 SAST; 2min 9s
ago
ConditionPathExists=/etc/pki/vdsm/certs/vdsmcert.pem was not met
Process: 11345 ExecStart=/usr/bin/ovirt-imageio-daemon (code=exited,
status=1/FAILURE)
Main PID: 11345 (code=exited, status=1/FAILURE)
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
holdoff time over, scheduling restart.
Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated too
quickly for ovirt-imageio-daemon.service
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
[root@glustermount ~]# journalctl -xe -u ovirt-imageio-daemon.service
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
"/usr/lib64/python2.7/logging/handlers.py",
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]:
BaseRotatingHandler.__init__(self, filename, mode
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
"/usr/lib64/python2.7/logging/handlers.py",
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]:
logging.FileHandler.__init__(self, filename, mode
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
"/usr/lib64/python2.7/logging/__init__.py",
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]:
StreamHandler.__init__(self, self._open())
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
"/usr/lib64/python2.7/logging/__init__.py",
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: stream =
open(self.baseFilename, self.mode)
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: IOError:
[Errno 2] No such file or directory: '/v
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service:
main process exited, code=exited, st
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
-- Subject: Unit ovirt-imageio-daemon.service has failed
-- Defined-By: systemd
-- Support:
--
-- Unit ovirt-imageio-daemon.service has failed.
--
-- The result is failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
holdoff time over, scheduling restart
Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated too
quickly for ovirt-imageio-daemon.servic
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
-- Subject: Unit ovirt-imageio-daemon.service has failed
-- Defined-By: systemd
-- Support:
--
-- Unit ovirt-imageio-daemon.service has failed.
--
-- The result is failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
On Wed, Sep 5, 2018 at 12:01 PM, Sakhi Hadebe <sakhi(a)sanren.ac.za> wrote:
# systemctl status ovirt-imageio-daemon.service
● ovirt-imageio-daemon.service - oVirt ImageIO Daemon
Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-daemon.service;
disabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Tue 2018-09-04 16:55:16
SAST; 19h ago
Condition: start condition failed at Wed 2018-09-05 11:56:46 SAST; 1min
58s ago
ConditionPathExists=/etc/pki/vdsm/certs/vdsmcert.pem was not
met
Process: 11345 ExecStart=/usr/bin/ovirt-imageio-daemon (code=exited,
status=1/FAILURE)
Main PID: 11345 (code=exited, status=1/FAILURE)
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt
ImageIO Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
holdoff time over, scheduling ...art.
Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated too
quickly for ovirt-imageio-daemon...vice
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt
ImageIO Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Hint: Some lines were ellipsized, use -l to show in full.
[root@glustermount ~]# systemctl status ovirt-imageio-daemon.service -l
● ovirt-imageio-daemon.service - oVirt ImageIO Daemon
Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-daemon.service;
disabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Tue 2018-09-04 16:55:16
SAST; 19h ago
Condition: start condition failed at Wed 2018-09-05 11:56:46 SAST; 2min 9s
ago
ConditionPathExists=/etc/pki/vdsm/certs/vdsmcert.pem was not
met
Process: 11345 ExecStart=/usr/bin/ovirt-imageio-daemon (code=exited,
status=1/FAILURE)
Main PID: 11345 (code=exited, status=1/FAILURE)
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt
ImageIO Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
holdoff time over, scheduling restart.
Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated too
quickly for ovirt-imageio-daemon.service
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt
ImageIO Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Output of:
On Wed, Sep 5, 2018 at 11:35 AM, Simone Tiraboschi <stirabos(a)redhat.com>
wrote:
>
>
> On Wed, Sep 5, 2018 at 11:10 AM Sakhi Hadebe <sakhi(a)sanren.ac.za> wrote:
>
>> Hi All,
>>
>> The host deploy logs are showing the below errors:
>>
>> [root@garlic engine-logs-2018-09-05T08:48:22Z]# cat
>> /var/log/ovirt-hosted-engine-setup/engine-logs-2018-09-05T08
>> \:34\:55Z/ovirt-engine/host-deploy/ovirt-host-deploy-20180
>> 905103605-garlic.sanren.ac.za-543b536b.log | grep -i error
>> 2018-09-05 10:35:46,909+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
>> 2018-09-05 10:35:47,116 [ERROR] __main__.py:8011:MainThread
>> @identity.py:145 - Reload of consumer identity cert
>> /etc/pki/consumer/cert.pem raised an exception with msg: [Errno 2] No such
>> file or directory: '/etc/pki/consumer/key.pem'
>> 2018-09-05 10:35:47,383+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
>> 2018-09-05 10:35:47,593 [ERROR] __main__.py:8011:MainThread
>> @identity.py:145 - Reload of consumer identity cert
>> /etc/pki/consumer/cert.pem raised an exception with msg: [Errno 2] No such
>> file or directory: '/etc/pki/consumer/key.pem'
>> 2018-09-05 10:35:48,245+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
>> Job for ovirt-imageio-daemon.service failed because the control process
>> exited with error code. See "systemctl status
ovirt-imageio-daemon.service"
>> and "journalctl -xe" for details.
>> RuntimeError: Failed to start service 'ovirt-imageio-daemon'
>> 2018-09-05 10:36:05,098+0200 ERROR otopi.context
>> context._executeMethod:152 Failed to execute stage 'Closing up': Failed
to
>> start service 'ovirt-imageio-daemon'
>> 2018-09-05 10:36:05,099+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'True'
>> 2018-09-05 10:36:05,099+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/exceptionInfo=list:'[(<type
>> 'exceptions.RuntimeError'>, RuntimeError("Failed to start
service
>> 'ovirt-imageio-daemon'",), <traceback object at
0x7f4de25ff320>)]'
>> 2018-09-05 10:36:05,106+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'True'
>> 2018-09-05 10:36:05,106+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/exceptionInfo=list:'[(<type
>> 'exceptions.RuntimeError'>, RuntimeError("Failed to start
service
>> 'ovirt-imageio-daemon'",), <traceback object at
0x7f4de25ff320>)]'
>>
>> I coudn't find anything helpful from the internet.
>>
>
> something relevant int he output of
> systemctl status ovirt-imageio-daemon.service
> and
> journalctl -xe -u ovirt-imageio-daemon.service
> ?
>
>
>
>>
>> On Tue, Sep 4, 2018 at 6:46 PM, Simone Tiraboschi <stirabos(a)redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 4, 2018 at 6:07 PM Sakhi Hadebe <sakhi(a)sanren.ac.za>
wrote:
>>>
>>>> Hi Sahina,
>>>>
>>>> I am sorry I can't reproduce the error nor access the logs since I
did
>>>> a fresh installed pn nodes. However now I can't even react that far
because
>>>> the engine deployment fails to start the host up:
>>>>
>>>>
>>>> [ INFO ] TASK [Wait for the host to be up]
>>>> [ ERROR ] fatal: [localhost]: FAILED! => {"ansible_facts":
>>>> {"ovirt_hosts": [{"address":
"goku.sanren.ac.za", "affinity_labels":
>>>> [], "auto_numa_status": "unknown",
"certificate": {"organization": "
>>>> sanren.ac.za", "subject":
"O=sanren.ac.za,CN=goku.sanren.ac.za"},
>>>> "cluster": {"href":
"/ovirt-engine/api/clusters/1c
>>>> a368cc-b052-11e8-b7de-00163e008187", "id":
"1ca368cc-b052-11e8-b7de-
>>>> 00163e008187"}, "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/1c575995-70b1-43f7-b348-4a9788e070cd",
>>>> "id": "1c575995-70b1-43f7-b348-4a9788e070cd",
"katello_errata": [],
>>>> "kdump_status": "unknown", "ksm":
{"enabled": false},
>>>> "max_scheduling_memory": 0, "memory": 0,
"name": "goku.sanren.ac.za",
>>>> "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:B3/PDH551EFid93fm6PoRryi6/cXuVE8yNgiiiROh84",
>>>> "port": 22}, "statistics": [], "status":
"install_failed",
>>>> "storage_connection_extensions": [], "summary":
{"total": 0}, "tags":
>>>> [], "transparent_huge_pages": {"enabled": false},
"type": "ovirt_node",
>>>> "unmanaged_networks": [], "update_available":
false}]}, "attempts": 120,
>>>> "changed": false}
>>>>
>>>> "status": "install_failed"
>>>
>>> You have to check host-deploy logs to get a details error message.
>>>
>>>
>>>>
>>>> Please help.
>>>>
>>>> On Mon, Sep 3, 2018 at 1:34 PM, Sahina Bose <sabose(a)redhat.com>
wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 29, 2018 at 8:39 PM, Sakhi Hadebe
<sakhi(a)sanren.ac.za>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am sorry to bother you again.
>>>>>>
>>>>>> I am trying to deploy an oVirt engine for oVirtNode-4.2.5.1. I
get
>>>>>> the same error I encountered before:
>>>>>>
>>>>>> [ INFO ] TASK [Add glusterfs storage domain]
>>>>>> [ ERROR ] Error: Fault reason is "Operation Failed".
Fault detail is
>>>>>> "[Problem while trying to mount target]". HTTP response
code is 400.
>>>>>> [ ERROR ] fatal: [localhost]: FAILED! => {"changed":
false, "msg":
>>>>>> "Fault reason is \"Operation Failed\". Fault
detail is \"[Problem
>>>>>> while trying to mount target]\". HTTP response code is
400."}
>>>>>> Please specify the storage you would like to use
>>>>>> (glusterfs, iscsi, fc, nfs)[nfs]:
>>>>>>
>>>>>> The glusterd daemon is running.
>>>>>>
>>>>>
>>>>> mounting 172.16.4.18:/engine at /rhev/data-center/mnt/glusterS
>>>>> D/172.16.4.18:_engine (mount:204)
>>>>> 2018-08-29 16:47:28,846+0200 ERROR (jsonrpc/3) [storage.HSM] Could
>>>>> not connect to storageServer (hsm:2398)
>>>>>
>>>>> Can you try to see if you are able to mount 172.16.4.18:/engine on
>>>>> the server you're deploying Hosted Engine using "mount -t
glusterfs
>>>>> 172.16.4.18:/engine /mnt/test"
>>>>>
>>>>>
>>>>>> During the deployment of the engine it sets the engine entry in
the
>>>>>> /etc/hosts file with the IP Address of 192.168.124.* which it
gets form the
>>>>>> virbr0 bridge interface. I stopped the bridge and deleted it, but
still
>>>>>> giving the same error. Not sure what causes it to use that
interface.
>>>>>> Please help!
>>>>>>
>>>>>> But I give the engine an IP of 192.168.1.10 same subnet as my
>>>>>> gateway and my ovirtmgmt bridge. Attached is the ifconfig output
of my
>>>>>> Node, engine.log and vdsm.log.
>>>>>>
>>>>>> Your assistance is always appreciated
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 11, 2018 at 11:47 AM, Sahina Bose
<sabose(a)redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Is glusterd running on the server: goku.sanren.**
>>>>>>> There's an error
>>>>>>> Failed to get volume info: Command execution failed
>>>>>>> error: Connection failed. Please check if gluster daemon is
>>>>>>> operational
>>>>>>>
>>>>>>> Please check the volume status using "gluster volume
status engine"
>>>>>>>
>>>>>>> and if all looks ok, attach the mount logs from
/var/log/glusterfs
>>>>>>>
>>>>>>> On Wed, Jul 11, 2018 at 1:57 PM, Sakhi Hadebe
<sakhi(a)sanren.ac.za>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have managed to fix the error by enabling the DMA
Virtualisation
>>>>>>>> in BIOS. I am now hit with a new error: It's failing
to add a glusterfs
>>>>>>>> storage domain:
>>>>>>>>
>>>>>>>> [ INFO ] TASK [Add glusterfs storage domain]
>>>>>>>> [ ERROR ] Error: Fault reason is "Operation
Failed". Fault detail
>>>>>>>> is "[Problem while trying to mount target]".
HTTP response code is 400.
>>>>>>>> [ ERROR ] fatal: [localhost]: FAILED! =>
{"changed": false, "msg":
>>>>>>>> "Fault reason is \"Operation Failed\".
Fault detail is \"[Problem while
>>>>>>>> trying to mount target]\". HTTP response code is
400."}
>>>>>>>> Please specify the storage you would like to
use
>>>>>>>> (glusterfs, iscsi, fc, nfs)[nfs]:
>>>>>>>>
>>>>>>>> Attached are vdsm and engine log files.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jul 11, 2018 at 9:57 AM, Sakhi Hadebe
<sakhi(a)sanren.ac.za>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jul 11, 2018 at 9:33 AM, Sakhi Hadebe
<sakhi(a)sanren.ac.za
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Below are the versions of packages installed.
Please find the
>>>>>>>>>> logs attached.
>>>>>>>>>> Qemu:
>>>>>>>>>>
ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch
>>>>>>>>>>
libvirt-daemon-driver-qemu-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>> qemu-img-ev-2.10.0-21.el7_5.4.1.x86_64
>>>>>>>>>> qemu-kvm-ev-2.10.0-21.el7_5.4.1.x86_64
>>>>>>>>>> qemu-kvm-common-ev-2.10.0-21.el7_5.4.1.x86_64
>>>>>>>>>>
>>>>>>>>>> Libvirt installed packages:
>>>>>>>>>>
libvirt-daemon-driver-storage-disk-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-config-nwfilter-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-storage-iscsi-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-network-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>> libvirt-libs-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-secret-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-storage-core-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-storage-gluster-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-storage-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-qemu-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>> libvirt-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>> libvirt-python-3.9.0-1.el7.x86_64
>>>>>>>>>>
libvirt-daemon-driver-nodedev-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-storage-rbd-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-storage-scsi-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-config-network-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>> libvirt-client-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>> libvirt-daemon-kvm-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-storage-logical-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>> libvirt-daemon-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-interface-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>> libvirt-lock-sanlock-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-storage-mpath-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-lxc-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
libvirt-daemon-driver-nwfilter-3.9.0-14.el7_5.6.x86_64
>>>>>>>>>>
>>>>>>>>>> Virt-manager:
>>>>>>>>>> virt-manager-common-1.4.3-3.el7.noarch
>>>>>>>>>>
>>>>>>>>>> oVirt:
>>>>>>>>>> [root@localhost network-scripts]# rpm -qa | grep
ovirt
>>>>>>>>>> ovirt-setup-lib-1.1.4-1.el7.centos.noarch
>>>>>>>>>> cockpit-ovirt-dashboard-0.11.28-1.el7.noarch
>>>>>>>>>> ovirt-imageio-common-1.3.1.2-0.el7.centos.noarch
>>>>>>>>>> ovirt-vmconsole-host-1.0.5-4.el7.centos.noarch
>>>>>>>>>> ovirt-host-dependencies-4.2.3-1.el7.x86_64
>>>>>>>>>> ovirt-engine-sdk-python-3.6.9.1-1.el7.noarch
>>>>>>>>>> ovirt-imageio-daemon-1.3.1.2-0.el7.centos.noarch
>>>>>>>>>> ovirt-host-4.2.3-1.el7.x86_64
>>>>>>>>>> python-ovirt-engine-sdk4-4.2.7-2.el7.x86_64
>>>>>>>>>> ovirt-host-deploy-1.7.4-1.el7.noarch
>>>>>>>>>> cockpit-machines-ovirt-169-1.el7.noarch
>>>>>>>>>> ovirt-hosted-engine-ha-2.2.14-1.el7.noarch
>>>>>>>>>> ovirt-vmconsole-1.0.5-4.el7.centos.noarch
>>>>>>>>>> ovirt-provider-ovn-driver-1.2.11-1.el7.noarch
>>>>>>>>>> ovirt-engine-appliance-4.2-20180626.1.el7.noarch
>>>>>>>>>> ovirt-release42-4.2.4-1.el7.noarch
>>>>>>>>>> ovirt-hosted-engine-setup-2.2.22.1-1.el7.noarch
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 11, 2018 at 6:48 AM, Yedidyah Bar
David <
>>>>>>>>>> didi(a)redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Tue, Jul 10, 2018 at 11:32 PM, Sakhi
Hadebe <
>>>>>>>>>>> sakhi(a)sanren.ac.za> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I did not select any CPU architecture. It
doenst gove me the
>>>>>>>>>>>> option to select one. It only states the
number of virtual CPUs and the
>>>>>>>>>>>> memory for the engine VM.
>>>>>>>>>>>>
>>>>>>>>>>>> Looking at the documentation of
installing
>>>>>>>>>>>> ovirt-release36.rpm....it does allow you
to select te CPU, but not when
>>>>>>>>>>>> installing ovirt-release42.rpm
>>>>>>>>>>>>
>>>>>>>>>>>> On Tuesday, July 10, 2018, Alastair Neil
<
>>>>>>>>>>>> ajneil.tech(a)gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> what did you select as your CPU
architecture when you created
>>>>>>>>>>>>> the cluster? It looks like the VM is
trying to use a CPU type of "Custom",
>>>>>>>>>>>>> how many nodes in your cluster? I
suggest you specify the lowest common
>>>>>>>>>>>>> denominator of CPU architecture (e.g.
Sandybridge) of the nodes as the CPU
>>>>>>>>>>>>> architecture of the cluster..
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, 10 Jul 2018 at 12:01, Sakhi
Hadebe <
>>>>>>>>>>>>> sakhi(a)sanren.ac.za> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have just re-installed centOS 7
in 3 servers and have
>>>>>>>>>>>>>> configured gluster volumes
following this documentation:
>>>>>>>>>>>>>>
https://www.ovirt.org/blog/2016/03/up-and-running-with-ovirt
>>>>>>>>>>>>>> -3-6/, But I have installed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
http://resources.ovirt.org/pub/yum-repo/ovirt-release42.rpm
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> package.
>>>>>>>>>>>>>> Hosted-engine --deploy is failing
with this error:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "rhel7",
"--virt-type", "kvm", "--memory", "16384",
>>>>>>>>>>>>>> "--vcpus",
"4", "--network",
"network=default,mac=00:16:3e:09:5e:5d,model=virtio",
>>>>>>>>>>>>>> "--disk",
"/var/tmp/localvm0nnJH9/images
>>>>>>>>>>>>>>
/eacac30d-0304-4c77-8753-6965e4b8c2e7/d494577e-027a-4209-895b-6132e6fc6b9a",
>>>>>>>>>>>>>> "--import",
"--disk", "path=/var/tmp/localvm0nnJH9/seed.iso,device=cdrom",
>>>>>>>>>>>>>> "--noautoconsole",
"--rng", "/dev/random", "--graphics", "vnc",
"--video",
>>>>>>>>>>>>>> "vga",
"--sound", "none", "--controller",
"usb,model=none", "--memballoon",
>>>>>>>>>>>>>> "none",
"--boot", "hd,menu=off", "--clock",
"kvmclock_present=yes"],
>>>>>>>>>>>>>> "delta":
"0:00:00.979003", "end": "2018-07-10 17:55:11.308555",
"msg":
>>>>>>>>>>>>>> "non-zero return code",
"rc": 1, "start": "2018-07-10 17:55:10.329552",
>>>>>>>>>>>>>> "stderr": "ERROR
unsupported configuration: CPU mode 'custom' for x86_64
>>>>>>>>>>>>>> kvm domain on x86_64 host is not
supported by hypervisor\nDomain
>>>>>>>>>>>>>> installation does not appear to
have been successful.\nIf it was, you can
>>>>>>>>>>>>>> restart your domain by running:\n
virsh --connect qemu:///system start
>>>>>>>>>>>>>> HostedEngineLocal\notherwise,
please restart your installation.",
>>>>>>>>>>>>>> "stderr_lines":
["ERROR unsupported configuration: CPU mode 'custom' for
>>>>>>>>>>>>>> x86_64 kvm domain on x86_64 host
is not supported by hypervisor", "Domain
>>>>>>>>>>>>>> installation does not appear to
have been successful.", "If it was, you can
>>>>>>>>>>>>>> restart your domain by
running:", " virsh --connect qemu:///system start
>>>>>>>>>>>>>> HostedEngineLocal",
"otherwise, please restart your installation."],
>>>>>>>>>>>>>> "stdout":
"\nStarting install...", "stdout_lines": ["",
"Starting
>>>>>>>>>>>>>> install..."]}
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> This seems to be in the phase where we create
a local vm for
>>>>>>>>>>> the engine. We do this with plain
virt-install, nothing fancy. Searching
>>>>>>>>>>> the net for "unsupported configuration:
CPU mode 'custom'" finds other
>>>>>>>>>>> relevant reports, you might want to check
them. You can see the command in
>>>>>>>>>>> bootstrap_local_vm.yml .
>>>>>>>>>>>
>>>>>>>>>>> Please check/share versions of relevant
packages (libvirt*,
>>>>>>>>>>> qemu*, etc) and relevant logs (libvirt).
>>>>>>>>>>>
>>>>>>>>>>> Also updating the subject line and adding
Simone.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> --
>>>>>>>>>>> Didi
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Regards,
>>>>>>>>>> Sakhi Hadebe
>>>>>>>>>>
>>>>>>>>>> Engineer: South African National Research Network
(SANReN)Competency Area, Meraka, CSIR
>>>>>>>>>>
>>>>>>>>>> Tel: +27 12 841 2308 <+27128414213>
>>>>>>>>>> Fax: +27 12 841 4223 <+27128414223>
>>>>>>>>>> Cell: +27 71 331 9622 <+27823034657>
>>>>>>>>>> Email: sakhi(a)sanren.ac.za
<shadebe(a)csir.co.za>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Regards,
>>>>>>>>> Sakhi Hadebe
>>>>>>>>>
>>>>>>>>> Engineer: South African National Research Network
(SANReN)Competency Area, Meraka, CSIR
>>>>>>>>>
>>>>>>>>> Tel: +27 12 841 2308 <+27128414213>
>>>>>>>>> Fax: +27 12 841 4223 <+27128414223>
>>>>>>>>> Cell: +27 71 331 9622 <+27823034657>
>>>>>>>>> Email: sakhi(a)sanren.ac.za <shadebe(a)csir.co.za>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Sakhi Hadebe
>>>>>>>>
>>>>>>>> Engineer: South African National Research Network
(SANReN)Competency Area, Meraka, CSIR
>>>>>>>>
>>>>>>>> Tel: +27 12 841 2308 <+27128414213>
>>>>>>>> Fax: +27 12 841 4223 <+27128414223>
>>>>>>>> Cell: +27 71 331 9622 <+27823034657>
>>>>>>>> Email: sakhi(a)sanren.ac.za <shadebe(a)csir.co.za>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list -- users(a)ovirt.org
>>>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>>>>> Privacy Statement:
https://www.ovirt.org/site/privacy-policy/
>>>>>>>> oVirt Code of Conduct:
https://www.ovirt.org/communit
>>>>>>>> y/about/community-guidelines/
>>>>>>>> List Archives:
https://lists.ovirt.org/archiv
>>>>>>>>
es/list/users(a)ovirt.org/message/YHKUKW22QLRVS56XZBXEWOGORFWFEGIA/
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Sakhi Hadebe
>>>>>>
>>>>>> Engineer: South African National Research Network
(SANReN)Competency Area, Meraka, CSIR
>>>>>>
>>>>>> Tel: +27 12 841 2308 <+27128414213>
>>>>>> Fax: +27 12 841 4223 <+27128414223>
>>>>>> Cell: +27 71 331 9622 <+27823034657>
>>>>>> Email: sakhi(a)sanren.ac.za <shadebe(a)csir.co.za>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Sakhi Hadebe
>>>>
>>>> Engineer: South African National Research Network (SANReN)Competency
Area, Meraka, CSIR
>>>>
>>>> Tel: +27 12 841 2308 <+27128414213>
>>>> Fax: +27 12 841 4223 <+27128414223>
>>>> Cell: +27 71 331 9622 <+27823034657>
>>>> Email: sakhi(a)sanren.ac.za <shadebe(a)csir.co.za>
>>>>
>>>> _______________________________________________
>>>> Users mailing list -- users(a)ovirt.org
>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>> Privacy Statement:
https://www.ovirt.org/site/privacy-policy/
>>>> oVirt Code of Conduct:
https://www.ovirt.org/communit
>>>> y/about/community-guidelines/
>>>> List Archives:
https://lists.ovirt.org/archiv
>>>> es/list/users(a)ovirt.org/message/DS7O33ZSGV5ZAHXKA3KT2ABYW3VJJWXQ/
>>>>
>>>
>>
>>
>> --
>> Regards,
>> Sakhi Hadebe
>>
>> Engineer: South African National Research Network (SANReN)Competency Area,
Meraka, CSIR
>>
>> Tel: +27 12 841 2308 <+27128414213>
>> Fax: +27 12 841 4223 <+27128414223>
>> Cell: +27 71 331 9622 <+27823034657>
>> Email: sakhi(a)sanren.ac.za <shadebe(a)csir.co.za>
>>
>>
--
Regards,
Sakhi Hadebe
Engineer: South African National Research Network (SANReN)Competency Area, Meraka, CSIR
Tel: +27 12 841 2308 <+27128414213>
Fax: +27 12 841 4223 <+27128414223>
Cell: +27 71 331 9622 <+27823034657>
Email: sakhi(a)sanren.ac.za <shadebe(a)csir.co.za>
--
Regards,
Sakhi Hadebe
Engineer: South African National Research Network (SANReN)Competency
Area, Meraka, CSIR
Tel: +27 12 841 2308 <+27128414213>
Fax: +27 12 841 4223 <+27128414223>
Cell: +27 71 331 9622 <+27823034657>
Email: sakhi(a)sanren.ac.za <shadebe(a)csir.co.za>