- Users - oVirt List Archives

icons for custom defined OS
by Matthias Leopold 12 Sep '18

12 Sep '18

Hi, I defined additional operating systems in my oVirt 4.2.6 installation according to https://www.ovirt.org/develop/release-management/features/virt/os-info/. Now i want to have custom default icons for use in VM portal for these new OS definitions. How can i do this? I only found a way to change the icon as individual VM portal user, this is nice, but not exactly what i want. thx matthias

1 1

Admin Portal
by mattias.kihl＠gmail.com 12 Sep '18

12 Sep '18

The redirection URI for client is not registered How to add a new host where i can use the adminportal. I found this. > Create a new conf file /etc/ovirt-engine/engine.conf.d/99-sso.conf and add: > SSO_CALLBACK_PREFIX_CHECK=false > > then > systemctl restart ovirt-engine > > This will turn off the additional security check for the callback prefix. But i want to keep the security and learn howto do it correct. Thanks

1 0

upload ISO from webui failed,"Paused by System"
by henaumars＠sina.com 12 Sep '18

12 Sep '18

Hi, I can't upload iso image from webui,always got "Paused by System" system info: engine:4.2.6.4-1.el7 vdsm:4.20.35-1.el7 imageio-proxy:1.4.4-0.el7 imageio-daemon:1.4.4-0.el7 operation: 1、download and install ca to the browser 2、select iso file to upload 3、click test ，alert to installl ca 4、install ca again（optional） 5、upload 6、wait and got "Paused by System" log： engine： 2018-09-11 11:13:22,273+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-61) [02c871da-a599-4201-9dd5-92a468dee952] START, HSMClearTaskVDSCommand(HostName = 21, HSMTaskGuidBaseVDSCommandParameters:{hostId='68f27646-da12-480b-9887-42ada2911132', taskId='90541bd1-65e7-4185-a051-3d8d9c1e3a5f'}), log id: 3ff168d7 2018-09-11 11:13:22,278+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-61) [02c871da-a599-4201-9dd5-92a468dee952] FINISH, HSMClearTaskVDSCommand, log id: 3ff168d7 2018-09-11 11:13:22,278+08 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-61) [02c871da-a599-4201-9dd5-92a468dee952] FINISH, SPMClearTaskVDSCommand, log id: 43d30861 2018-09-11 11:13:22,280+08 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedThreadFactory-engine-Thread-61) [02c871da-a599-4201-9dd5-92a468dee952] BaseAsyncTask::removeTaskFromDB: Removed task '90541bd1-65e7-4185-a051-3d8d9c1e3a5f' from DataBase 2018-09-11 11:13:22,280+08 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedThreadFactory-engine-Thread-61) [02c871da-a599-4201-9dd5-92a468dee952] CommandAsyncTask::HandleEndActionResult [within thread]: Removing CommandMultiAsyncTasks object for entity '4ff92f68-8353-40ac-a7c5-f0efbd054841' 2018-09-11 11:13:26,098+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-8) [352651c9-ddde-4e1e-b95c-05ad967ed0b1] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2018-09-11 11:13:28,836+08 INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] Command 'AddDisk' id: '4b72410d-e5a0-4c43-b7db-a5324a32d012' child commands '[4ff92f68-8353-40ac-a7c5-f0efbd054841]' executions were completed, status 'SUCCEEDED' 2018-09-11 11:13:28,836+08 INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] Command 'AddDisk' id: '4b72410d-e5a0-4c43-b7db-a5324a32d012' Updating status to 'SUCCEEDED', The command end method logic will be executed by one of its parent commands. 2018-09-11 11:13:28,862+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] Successfully added Upload disk 'oVirt-toolsSetup-4.2-1.el7.centos.iso' (disk id: '97179509-65eb-4b45-ad8e-ce112cfd016a', image id: '6ca217cc-015e-4d00-872a-faf60a8954ac') for image transfer command '4cdff02c-7fe4-4000-9c92-8ef613597d13' 2018-09-11 11:13:28,892+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.PrepareImageVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] START, PrepareImageVDSCommand(HostName = 21, PrepareImageVDSCommandParameters:{hostId='68f27646-da12-480b-9887-42ada2911132'}), log id: 19407261 2018-09-11 11:13:28,901+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.PrepareImageVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] FINISH, PrepareImageVDSCommand, return: PrepareImageReturn:{status='Status [code=0, message=Done]'}, log id: 19407261 2018-09-11 11:13:28,901+08 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SetVolumeLegalityVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] START, SetVolumeLegalityVDSCommand( SetVolumeLegalityVDSCommandParameters:{storagePoolId='ab65cc43-3c9e-4c02-ba75-ccd9fa8691b1', ignoreFailoverLimit='false', storageDomainId='ffc618b9-fd75-4ca2-ace4-15a1b7b58ecf', imageGroupId='97179509-65eb-4b45-ad8e-ce112cfd016a', imageId='6ca217cc-015e-4d00-872a-faf60a8954ac'}), log id: 5068b962 2018-09-11 11:13:28,914+08 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SetVolumeLegalityVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] FINISH, SetVolumeLegalityVDSCommand, log id: 5068b962 2018-09-11 11:13:28,915+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.AddImageTicketVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] START, AddImageTicketVDSCommand(HostName = 21, AddImageTicketVDSCommandParameters:{hostId='68f27646-da12-480b-9887-42ada2911132', ticketId='3564a630-be37-407f-802d-ce38a01cc104', timeout='300', operations='[write]', size='382971904', url='file:///rhev/data-center/mnt/_data/ffc618b9-fd75-4ca2-ace4-15a1b7b58ecf/images/97179509-65eb-4b45-ad8e-ce112cfd016a/6ca217cc-015e-4d00-872a-faf60a8954ac', filename='null', sparse='true'}), log id: 64950261 2018-09-11 11:13:28,920+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.AddImageTicketVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] FINISH, AddImageTicketVDSCommand, return: StatusOnlyReturn [status=Status [code=0, message=Done]], log id: 64950261 2018-09-11 11:13:28,920+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] Started transfer session with ticket id 3564a630-be37-407f-802d-ce38a01cc104, timeout 300 seconds 2018-09-11 11:13:28,920+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] Adding image ticket to ovirt-imageio-proxy, id 3564a630-be37-407f-802d-ce38a01cc104 2018-09-11 11:13:28,934+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] Updating image transfer 4cdff02c-7fe4-4000-9c92-8ef613597d13 (image 97179509-65eb-4b45-ad8e-ce112cfd016a) phase to Transferring 2018-09-11 11:13:28,935+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-55) [02c871da-a599-4201-9dd5-92a468dee952] Returning from proceedCommandExecution after starting transfer session for image transfer command '4cdff02c-7fe4-4000-9c92-8ef613597d13' 2018-09-11 11:13:29,948+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetImageTicketVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-56) [02c871da-a599-4201-9dd5-92a468dee952] START, GetImageTicketVDSCommand(HostName = 21, GetImageTicketVDSCommandParameters:{hostId='68f27646-da12-480b-9887-42ada2911132', ticketId='3564a630-be37-407f-802d-ce38a01cc104', timeout='null'}), log id: 1b9af167 2018-09-11 11:13:29,952+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetImageTicketVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-56) [02c871da-a599-4201-9dd5-92a468dee952] FINISH, GetImageTicketVDSCommand, return: org.ovirt.engine.core.common.businessentities.storage.ImageTicketInformation@558504b3, log id: 1b9af167 2018-09-11 11:13:30,111+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-6) [c1647c4b-63fe-4ca7-b4a1-adb77c85e076] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2018-09-11 11:13:42,126+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-6) [32ab474a-5bd4-4026-b653-67b2a6d776b9] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2018-09-11 11:13:44,039+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetImageTicketVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-44) [02c871da-a599-4201-9dd5-92a468dee952] START, GetImageTicketVDSCommand(HostName = 21, GetImageTicketVDSCommandParameters:{hostId='68f27646-da12-480b-9887-42ada2911132', ticketId='3564a630-be37-407f-802d-ce38a01cc104', timeout='null'}), log id: 66ab6e50 2018-09-11 11:13:44,044+08 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetImageTicketVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-44) [02c871da-a599-4201-9dd5-92a468dee952] FINISH, GetImageTicketVDSCommand, return: org.ovirt.engine.core.common.businessentities.storage.ImageTicketInformation@558504c1, log id: 66ab6e50 2018-09-11 11:13:46,135+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-6) [1e65c0eb-95b0-4152-9887-5fa9521bb0a9] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2018-09-11 11:13:48,327+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-6) [4ad6f0ea-2ae5-4067-b1c2-c0503b2e3676] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2018-09-11 11:13:48,328+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (default task-6) [4ad6f0ea-2ae5-4067-b1c2-c0503b2e3676] Updating image transfer 4cdff02c-7fe4-4000-9c92-8ef613597d13 (image 97179509-65eb-4b45-ad8e-ce112cfd016a) phase to Paused by System (message: 'Sent 0MB') 2018-09-11 11:13:48,335+08 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-6) [4ad6f0ea-2ae5-4067-b1c2-c0503b2e3676] EVENT_ID: UPLOAD_IMAGE_NETWORK_ERROR(1,062), Unable to upload image to disk 97179509-65eb-4b45-ad8e-ce112cfd016a due to a network error. Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registered as a valid CA in the browser. The certificate can be fetched from https://<engine_url>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA 2018-09-11 11:13:50,220+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-6) [2a9835b2-a08d-4efd-9fa0-208d14dd4bdc] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER 2018-09-11 11:13:54,080+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-60) [02c871da-a599-4201-9dd5-92a468dee952] Transfer was paused by system. Upload disk 'oVirt-toolsSetup-4.2-1.el7.centos.iso' (disk id: '97179509-65eb-4b45-ad8e-ce112cfd016a', image id: '6ca217cc-015e-4d00-872a-faf60a8954ac') 2018-09-11 11:13:54,196+08 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferImageStatusCommand] (default task-6) [3742a3f4-4352-46c4-8480-0035e8d7a5fb] Running command: TransferImageStatusCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_DISK with role type USER imageio-proxy： (Thread-4 ) INFO 2018-09-11 11:12:32,476 auth:201:auth2:(delete_ticket) Deleting ticket u'9a8117e4-2ba0-40c3-ae3d-aadc43b7857d' (Thread-5 ) INFO 2018-09-11 11:13:28,929 auth:187:auth2:(add_signed_ticket) Adding new ticket: <Ticket id=u'3564a630-be37-407f-802d-ce38a01cc104', url=u'https://172.22.224.21:54322' timeout=35999.070008039474 at 0x7fa30cdd6b50> imageio-daemon： 2018-09-11 11:13:28,402 INFO (Thread-12) [tickets] [local] ADD ticket={u'uuid': u'3564a630-be37-407f-802d-ce38a01cc104', u'ops': [u'write'], u'url': u'file:///rhev/data-center/mnt/_data/ffc618b9-fd75-4ca2-ace4-15a1b7b58ecf/images/97179509-65eb-4b45-ad8e-ce112cfd016a/6ca217cc-015e-4d00-872a-faf60a8954ac', u'sparse': True, u'timeout': 300, u'size': 382971904} I‘ve been stucked for days and need to get help！

2 1

Ovirt and gluster deployment - host name
by florentl 11 Sep '18

11 Sep '18

Hello, I want to deploy ovirt (hosted engine) and gluster on three servers. I have thought about a configuration but I'm not sure that it's the most suitable one. All the servers have 2 ten gigabit Ethernet nic. I read that, am besten, I must dedicate one nic for the storage and another one for the system. So I will have two netnork address space : - for the system : 192.168.176.0/24 with a gateway configured - for the storage : 10.255.255.0/24 without a gateway Inside my hosts file on all the server I will have : 192.168.176.1 server1 192.168.176.2 server2 192.168.176.3 server3 10.255.255.1 gluster1 10.255.255.2 gluster2 10.255.255.3 gluster2 When I start the gluster deployment I will use gluster1, gluster2 and gluster3 name. And after the gluster deployment during the hyperconverged setup I will use server1, server2 and server3 name. May I have your opinion about this deployment ? Thanks in advance for the help. Florent LORNE

3 2

Ovirt Single Node Hyperconverged
by Keith Winn 11 Sep '18

11 Sep '18

Hi, I am looking at using Ovirt on a single machine. I used to use the all-in-one setup a while ago. I have only two vms and setting up two servers and a storage is out of my budget right now. The all in one solution sounds good, but I have some questions concerning the gdeploy config file. I am new to gluster and am unsure what I need. The server is ibm system x3550 m3 with two 1TB drives setup as a mirror. For these, what do I put if the disks are already setup as raid through the raid controller? Jbod [disktype] @RAIDTYPE@ #Possible values raid6, raid10, raid5, jbod [diskcount] @NUMBER_OF_DATA_DISKS@ #Ignored in case of jbod [stripesize] @STRIPE_SIZE@ #256 in case of jbod My second question is where do I get the Device name in the following: [script1] action=execute ignore_script_errors=no file=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d @DEVICE@ Is this the dev/sda on the disk or some other name. I was planning on using ovirt node as a staring point as that seems easier. Thanks in advance for the help.

3 3

LDAP authentication does not work after engine upgrade to ovirt 4.6
by Michael Watters 11 Sep '18

11 Sep '18

I've just upgraded our ovirt engine server to ovirt 4.6 and it appears that LDAP logins no longer work. When I attempt to log in using an AD account the following errors are shown in the engine log. 2018-09-11 10:03:44,610-04 ERROR [org.ovirt.engine.core.sso.servlets.InteractiveAuthServlet] (default task-10) [] Internal Server Error: Cannot locate principal 'username(a)example.com' 2018-09-11 10:03:44,610-04 ERROR [org.ovirt.engine.core.sso.utils.SsoUtils] (default task-10) [] Cannot locate principal 'username(a)example.com' 2018-09-11 10:03:44,645-04 ERROR [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-10) [] server_error: Cannot locate principal 'username(a)example.com' I have not changed any LDAP settings and ldapsearch is able to find this object without any issues. Does anybody have any idea what would cause this?

1 1

Managing multiple oVirt installs?
by femi adegoke 11 Sep '18

11 Sep '18

Let's say you have multiple oVirt installs. How can they all be "managed" by using a single engine web UI (so I don't have to login 5 different times)?

8 16

Re: Engine Setup Error
by Sakhi Hadebe 11 Sep '18

11 Sep '18

HI, I re-installed the cluster and got the hosted engine deployed succesfully. Thank you for your assistance On Thu, Sep 6, 2018 at 1:54 PM, Sakhi Hadebe <sakhi(a)sanren.ac.za> wrote: > Hi Simone, > > Yes the ownership of /var/log/ovirt-imageio-daemon is vdsm:kvm, 755. > > Below is the version of the ovirt packages currently installed on my oVirt > Nodes: > > ovirt-vmconsole-1.0.5-4.el7.centos.noarch > ovirt-provider-ovn-driver-1.2.14-1.el7.noarch > ovirt-release-host-node-4.2.6-1.el7.noarch > ovirt-hosted-engine-setup-2.2.26-1.el7.noarch > ovirt-node-ng-nodectl-4.2.0-0.20180903.0.el7.noarch > ovirt-release42-4.2.6-1.el7.noarch > ovirt-imageio-common-1.4.4-0.el7.x86_64 > python-ovirt-engine-sdk4-4.2.8-2.el7.x86_64 > *ovirt-imageio-daemon-1.4.4-0.el7.noarch* > *ovirt-hosted-engine-ha-2.2.16-1.el7.noarch* > ovirt-host-4.2.3-1.el7.x86_64 > ovirt-engine-sdk-python-3.6.9.1-1.el7.noarch > ovirt-host-deploy-1.7.4-1.el7.noarch > cockpit-machines-ovirt-172-2.el7.centos.noarch > ovirt-host-dependencies-4.2.3-1.el7.x86_64 > ovirt-engine-appliance-4.2-20180903.1.el7.noarch > ovirt-setup-lib-1.1.5-1.el7.noarch > cockpit-ovirt-dashboard-0.11.33-1.el7.noarch > ovirt-vmconsole-host-1.0.5-4.el7.centos.noarch > ovirt-node-ng-image-update-placeholder-4.2.6-1.el7.noarch > > I updated ovirt packages. and the ovirt-imageio-daemon is now running. > > ovirt-ha-agent is failing: *Failed to start monitor agents. *The engine > was successfully deployed but can't access it as the ovirt-ha-agent is not > running with the error below and log files attached: > > [root@goku ovirt-hosted-engine-ha]# journalctl -xe -u ovirt-ha-agent > Sep 06 13:50:36 goku systemd[1]: ovirt-ha-agent.service holdoff time over, > scheduling restart. > Sep 06 13:50:36 goku systemd[1]: Started oVirt Hosted Engine High > Availability Monitoring Agent. > -- Subject: Unit ovirt-ha-agent.service has finished start-up > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit ovirt-ha-agent.service has finished starting up. > -- > -- The start-up result is done. > Sep 06 13:50:36 goku systemd[1]: Starting oVirt Hosted Engine High > Availability Monitoring Agent... > -- Subject: Unit ovirt-ha-agent.service has begun start-up > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit ovirt-ha-agent.service has begun starting up. > Sep 06 13:50:37 goku ovirt-ha-agent[50395]: ovirt-ha-agent > ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngi > Sep 06 13:50:37 goku ovirt-ha-agent[50395]: ovirt-ha-agent > ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceb > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agen > return action(he) > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agen > return > he.start_monitoring() > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agen > self._initialize_broker() > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agen > m.get('options', {})) > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/ > .format(type, options, e)) > RequestError: Failed to start > monitor ping, options {'addr': '192.16 > Sep 06 13:50:37 goku ovirt-ha-agent[50395]: ovirt-ha-agent > ovirt_hosted_engine_ha.agent.agent.Agent ERROR Trying > Sep 06 13:50:37 goku systemd[1]: ovirt-ha-agent.service: main process > exited, code=exited, status=157/n/a > Sep 06 13:50:37 goku systemd[1]: Unit ovirt-ha-agent.service entered > failed state. > Sep 06 13:50:37 goku systemd[1]: ovirt-ha-agent.service failed. > lines 3528-3559/3559 (END) > > > > On Wed, Sep 5, 2018 at 1:53 PM, Simone Tiraboschi <stirabos(a)redhat.com> > wrote: > >> Can you please check if on your host you have >> /var/log/ovirt-imageio-daemon and its ownership and permissions (it should >> be vdsm:kvm,700)? >> Can you please report which version of ovirt-imageio-daemon you are >> using? >> We had a bug there but it has been fixed long time ago. >> >> >> On Wed, Sep 5, 2018 at 12:04 PM Sakhi Hadebe <sakhi(a)sanren.ac.za> wrote: >> >>> 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: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >>> -- >>> -- 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: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >>> -- >>> -- 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/1ca368cc-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/201 >>>>>>>>>>>>>>>>>> 6/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/YHKUKW22QLRVS56XZBXEWOGORFWF >>>>>>>>>>>> EGIA/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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> >>> >>> > > > -- > 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>

1 0

add gluster cluster to deployed cluster
by p.staniforth＠leedsbeckett.ac.uk 10 Sep '18

10 Sep '18

Hello People, I have a 3 node cluster this just has virt service deployed, how would I add gluster service to this. We have installed 2 extra disks in each node and they are running oVirt Node 4.2.5.1 After we have a gluster service running how easy would it be to migrate an existing engine to Self Hosted Engine? Thanks, Paul S.

2 2

Clean stuck VM from ovirt dashboard
by Alex K 10 Sep '18

10 Sep '18

Hi all, I have a failed clone of a VM which led to the clone being listed as a VM with state "Image locked", as if the clone is still continuing. No tasks are being shown and for sure the clone is not continuing. Also there are not disk images listed for this VM instance at the disks tab. How can i remove this fake VM from the GUI. There might be some steps I can do in the engine DB to make the engine forget about this VM. I a running ovirt 4.1.9. (I know not the latest, though this will be for some time until we prepare to move to 4.2.X) Thanx, Alex

2 2