- Users - oVirt List Archives

Unable to change cluster and data center compatibility version
by Jonathan Mathews 25 Feb '19

25 Feb '19

Good Day I have been trying to upgrade a clients oVirt from 3.6 to 4.0 but have run into an issue where I am unable to change the cluster and data center compatibility version. I get the following error in the GUI: Ovirt: Some of the hosts still use legacy protocol which is not supported by cluster 3.6 or higher. In order to change it a host needs to be put to maintenance and edited in advanced options section. This error was received with all VM's off and all hosts in maintenance. The environment has the following currently installed: Engine - CentOS 7.4 - Ovirt Engine 3.6.7.5 Host1 - CentOS 6.9 - VDSM 4.16.30 Host2 - CentOS 6.9 - VDSM 4.16.30 Host3 - CentOS 6.9 - VDSM 4.16.30 I also have the following from engine.log [root@ovengine ~]# tail -f /var/log/ovirt-engine/engine.log 2018-09-22 07:11:33,920 INFO [org.ovirt.engine.core.vdsbroker.VmsStatisticsFetcher] (DefaultQuartzScheduler_Worker-93) [7533985f] Fetched 0 VMs from VDS 'd82a026c-31b4-4efc-8567-c4a6bdcaa826' 2018-09-22 07:11:34,685 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStoragePoolVDSCommand] (DefaultQuartzScheduler_Worker-99) [4b7e3710] FINISH, DisconnectStoragePoolVDSCommand, log id: 1ae6f0a9 2018-09-22 07:11:34,687 INFO [org.ovirt.engine.core.bll.storage.DisconnectHostFromStoragePoolServersCommand] (DefaultQuartzScheduler_Worker-99) [2a6aa6f6] Running command: DisconnectHostFromStoragePoolServersCommand internal: true. Entities affected : ID: 5849b030-626e-47cb-ad90-3ce782d831b3 Type: StoragePool 2018-09-22 07:11:34,706 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSCommand] (DefaultQuartzScheduler_Worker-99) [2a6aa6f6] START, DisconnectStorageServerVDSCommand(HostName = ovhost3, StorageServerConnectionManagementVDSParameters:{runAsync='true', hostId='d82a026c-31b4-4efc-8567-c4a6bdcaa826', storagePoolId='5849b030-626e-47cb-ad90-3ce782d831b3', storageType='NFS', connectionList='[StorageServerConnections:{id='3fdffb4c-250b-4a4e-b914-e0da1243550e', connection='172.16.0.10:/raid0/data/_NAS_NFS_Exports_/STORAGE1', iqn='null', vfsType='null', mountOptions='null', nfsVersion='null', nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}, StorageServerConnections:{id='4d95c8ca-435a-4e44-86a5-bc7f3a0cd606', connection='172.16.0.20:/data/ov-export', iqn='null', vfsType='null', mountOptions='null', nfsVersion='null', nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}, StorageServerConnections:{id='82ecbc89-bdf3-4597-9a93-b16f3a6ac117', connection='172.16.0.11:/raid1/data/_NAS_NFS_Exports_/4TB', iqn='null', vfsType='null', mountOptions='null', nfsVersion='null', nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}, StorageServerConnections:{id='29bb3394-fb61-41c0-bb5a-1fa693ec2fe2', connection='172.16.0.11:/raid1/data/_NAS_NFS_Exports_/iso', iqn='null', vfsType='null', mountOptions='null', nfsVersion='V3', nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}]'}), log id: 48c5ffd6 2018-09-22 07:11:34,991 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSCommand] (DefaultQuartzScheduler_Worker-99) [2a6aa6f6] FINISH, DisconnectStorageServerVDSCommand, return: {3fdffb4c-250b-4a4e-b914-e0da1243550e=0, 29bb3394-fb61-41c0-bb5a-1fa693ec2fe2=0, 82ecbc89-bdf3-4597-9a93-b16f3a6ac117=0, 4d95c8ca-435a-4e44-86a5-bc7f3a0cd606=0}, log id: 48c5ffd6 2018-09-22 07:11:56,367 WARN [org.ovirt.engine.core.bll.UpdateVdsGroupCommand] (default task-29) [1a31cc53] CanDoAction of action 'UpdateVdsGroup' failed for user admin@internal. Reasons: VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,ACTION_TYPE_FAILED_WRONG_PROTOCOL_FOR_CLUSTER_VERSION 2018-09-22 07:12:41,017 WARN [org.ovirt.engine.core.bll.storage.UpdateStoragePoolCommand] (default task-29) [efd285b] CanDoAction of action 'UpdateStoragePool' failed for user admin@internal. Reasons: VAR__TYPE__STORAGE__POOL,VAR__ACTION__UPDATE,$ClustersList Default,ERROR_CANNOT_UPDATE_STORAGE_POOL_COMPATIBILITY_VERSION_BIGGER_THAN_CLUSTERS 2018-09-22 07:13:15,717 WARN [org.ovirt.engine.core.bll.UpdateVdsGroupCommand] (default task-6) [4c9f3ee8] CanDoAction of action 'UpdateVdsGroup' failed for user admin@internal. Reasons: VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,ACTION_TYPE_FAILED_WRONG_PROTOCOL_FOR_CLUSTER_VERSION 2018-09-22 07:15:21,460 WARN [org.ovirt.engine.core.bll.UpdateVdsGroupCommand] (default task-28) [649bae65] CanDoAction of action 'UpdateVdsGroup' failed for user admin@internal. Reasons: VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,ACTION_TYPE_FAILED_WRONG_PROTOCOL_FOR_CLUSTER_VERSION 2018-09-22 07:18:44,633 WARN [org.ovirt.engine.core.bll.UpdateVdsGroupCommand] (default task-8) [23167cfd] CanDoAction of action 'UpdateVdsGroup' failed for user admin@internal. Reasons: VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,ACTION_TYPE_FAILED_WRONG_PROTOCOL_FOR_CLUSTER_VERSION 2018-09-22 07:24:20,372 WARN [org.ovirt.engine.core.bll.UpdateVdsGroupCommand] (default task-15) [5d2ce633] CanDoAction of action 'UpdateVdsGroup' failed for user admin@internal. Reasons: VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,ACTION_TYPE_FAILED_WRONG_PROTOCOL_FOR_CLUSTER_VERSION I would appreciate some advice in resolving this. Thanks

3 5

Problem with snapshots in illegal status
by Bruno Rodriguez 25 Feb '19

25 Feb '19

Hello, We are experiencing some problems with some snapshots in illegal status generated with the python API. I think I'm not the only one, and that is not a relief but I hope someone can help about it. I'm a bit scared because, for what I see, the creation date in the engine for every snapshot is way different from the date when it was really created. The name of the snapshot is in the format backup_snapshot_YYYYMMDD-HHMMSS, but as you can see in the following examples, the stored date is totally random... Size Creation Date Snapshot Description Status Disk Snapshot ID 33 GiB Mar 2, 2018, 5:03:57 PM backup_snapshot_20190217-011645 Illegal 5734df23-de67-41a8-88a1-423cecfe7260 33 GiB May 8, 2018, 10:02:56 AM backup_snapshot_20190216-013047 Illegal f649d9c1-563e-49d4-9fad-6bc94abc279b 10 GiB Feb 21, 2018, 11:10:17 AM backup_snapshot_20190217-010004 Illegal 2929df28-eae8-4f27-afee-a984fe0b07e7 43 GiB Feb 2, 2018, 12:55:51 PM backup_snapshot_20190216-015544 Illegal 4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f 11 GiB Feb 13, 2018, 12:51:08 PM backup_snapshot_20190217-010541 Illegal fbaff53b-30ce-4b20-8f10-80e70becb48c 11 GiB Feb 13, 2018, 4:05:39 PM backup_snapshot_20190217-011207 Illegal c628386a-da6c-4a0d-ae7d-3e6ecda27d6d 11 GiB Feb 13, 2018, 4:38:25 PM backup_snapshot_20190216-012058 Illegal e9ddaa5c-007d-49e6-8384-efefebb00aa6 11 GiB Feb 13, 2018, 10:52:09 AM backup_snapshot_20190216-012550 Illegal 5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4 55 GiB Jan 22, 2018, 5:02:29 PM backup_snapshot_20190217-012659 Illegal 7efe2e7e-ca24-4b27-b512-b42795c79ea4 When I'm getting the logs for the first one, to check what happened to it, I get the following 2019-02-17 01:16:45,839+01 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.CreateVolumeVDSCommand] (default task-100) [96944daa-c90a-4ad7-a556-c98e66550f87] START, CreateVolumeVDSCommand( CreateVolumeVDSCommandParameters:{storagePoolId='fa64792e-73b3-4da2-9d0b-f334422aaccf', ignoreFailoverLimit='false', storageDomainId='e655abce-c5e8-44f3-8d50-9fd76edf05cb', imageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f', imageSizeInBytes='32212254720', volumeFormat='COW', newImageId='fa154782-0dbb-45b5-ba62-d6937259f097', imageType='Sparse', newImageDescription='', imageInitialSizeInBytes='0', imageId='5734df23-de67-41a8-88a1-423cecfe7260', sourceImageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f'}), log id: 497c168a 2019-02-17 01:18:26,506+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand] (default task-212) [19f00d3e-5159-48aa-b3a0-615a085b62d9] START, GetVolumeInfoVDSCommand(HostName = hood13.pic.es, GetVolumeInfoVDSCommandParameters:{hostId='0a774472-5737-4ea2-b49a-6f0ea4572199', storagePoolId='fa64792e-73b3-4da2-9d0b-f334422aaccf', storageDomainId='e655abce-c5e8-44f3-8d50-9fd76edf05cb', imageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f', imageId='5734df23-de67-41a8-88a1-423cecfe7260'}), log id: 111a34cf 2019-02-17 01:18:26,764+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (default task-212) [19f00d3e-5159-48aa-b3a0-615a085b62d9] Successfully added Download disk 'vm.example.com_Disk1' (id '5734df23-de67-41a8-88a1-423cecfe7260') for image transfer command '11104d8c-2a9b-4924-96ce-42ef66725616' 2019-02-17 01:18:27,310+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.AddImageTicketVDSCommand] (default task-212) [19f00d3e-5159-48aa-b3a0-615a085b62d9] START, AddImageTicketVDSCommand(HostName = hood11.pic.es, AddImageTicketVDSCommandParameters:{hostId='79cbda85-35f4-44df-b309-01b57bc2477e', ticketId='0d389c3e-5ea5-4886-8ea7-60a1560e3b2d', timeout='300', operations='[read]', size='35433480192', url='file:///rhev/data-center/mnt/blockSD/e655abce-c5e8-44f3-8d50-9fd76edf05cb/images/c5cc464e-eb71-4edf-a780-60180c592a6f/5734df23-de67-41a8-88a1-423cecfe7260', filename='null'}), log id: f5de141 2019-02-17 01:22:28,898+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-100) [19f00d3e-5159-48aa-b3a0-615a085b62d9] Renewing transfer ticket for Download disk 'vm.example.com_Disk1' (id '5734df23-de67-41a8-88a1-423cecfe7260') 2019-02-17 01:26:33,588+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-100) [19f00d3e-5159-48aa-b3a0-615a085b62d9] Renewing transfer ticket for Download disk 'vm.example.com_Disk1' (id '5734df23-de67-41a8-88a1-423cecfe7260') 2019-02-17 01:26:49,319+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-6) [19f00d3e-5159-48aa-b3a0-615a085b62d9] Finalizing successful transfer for Download disk 'vm.example.com_Disk1' (id '5734df23-de67-41a8-88a1-423cecfe7260') 2019-02-17 01:27:17,771+01 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-6) [19f00d3e-5159-48aa-b3a0-615a085b62d9] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM hood11.pic.es command TeardownImageVDS failed: Cannot deactivate Logical Volume: ('General Storage Exception: ("5 [] [\' Logical volume e655abce-c5e8-44f3-8d50-9fd76edf05cb/5734df23-de67-41a8-88a1-423cecfe7260 in use.\', \' Logical volume e655abce-c5e8-44f3-8d50-9fd76edf05cb/fa154782-0dbb-45b5-ba62-d6937259f097 in use.\']\\ne655abce-c5e8-44f3-8d50-9fd76edf05cb/[\'5734df23-de67-41a8-88a1-423cecfe7260\', \'fa154782-0dbb-45b5-ba62-d6937259f097\']",)',) 2019-02-17 01:27:17,772+01 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.TeardownImageVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-6) [19f00d3e-5159-48aa-b3a0-615a085b62d9] Command 'TeardownImageVDSCommand(HostName = hood11.pic.es, ImageActionsVDSCommandParameters:{hostId='79cbda85-35f4-44df-b309-01b57bc2477e'})' execution failed: VDSGenericException: VDSErrorException: Failed in vdscommand to TeardownImageVDS, error = Cannot deactivate Logical Volume: ('General Storage Exception: ("5 [] [\' Logical volume e655abce-c5e8-44f3-8d50-9fd76edf05cb/5734df23-de67-41a8-88a1-423cecfe7260 in use.\', \' Logical volume e655abce-c5e8-44f3-8d50-9fd76edf05cb/fa154782-0dbb-45b5-ba62-d6937259f097 in use.\']\\ne655abce-c5e8-44f3-8d50-9fd76edf05cb/[\'5734df23-de67-41a8-88a1-423cecfe7260\', \'fa154782-0dbb-45b5-ba62-d6937259f097\']",)',) 2019-02-17 01:27:19,204+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MergeVDSCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-6) [e73bfbec-d6bd-40e5-8009-97e6005ad1d4] START, MergeVDSCommand(HostName = hood11.pic.es, MergeVDSCommandParameters:{hostId='79cbda85-35f4-44df-b309-01b57bc2477e', vmId='addd5eba-9078-41aa-9244-fe485aded951', storagePoolId='fa64792e-73b3-4da2-9d0b-f334422aaccf', storageDomainId='e655abce-c5e8-44f3-8d50-9fd76edf05cb', imageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f', imageId='fa154782-0dbb-45b5-ba62-d6937259f097', baseImageId='5734df23-de67-41a8-88a1-423cecfe7260', topImageId='fa154782-0dbb-45b5-ba62-d6937259f097', bandwidth='0'}), log id: 1d956d48 2019-02-17 01:27:29,923+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-49) [19f00d3e-5159-48aa-b3a0-615a085b62d9] Transfer was successful. Download disk 'vm.example.com_Disk1' (id '5734df23-de67-41a8-88a1-423cecfe7260') 2019-02-17 01:27:30,997+01 INFO [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-46) [19f00d3e-5159-48aa-b3a0-615a085b62d9] Successfully transferred disk '5734df23-de67-41a8-88a1-423cecfe7260' (command id '11104d8c-2a9b-4924-96ce-42ef66725616') For what I understand, there was a "Cannot deactivate logical volume" problem that I would thank very much if someone can help me about how to solve Thanks again -- Bruno Rodríguez Rodríguez "Si algo me ha enseñado el tetris, es que los errores se acumulan y los triunfos desaparecen"

2 5

VM creation using python api specifying an appropriate timezone
by ckennedy288＠gmail.com 25 Feb '19

25 Feb '19

Hi, I'm looking for a way to accurately specify the timezone of a VM at VM creation time. At the moment all VMs that get created using a simple in-house python script are set with a GMT timezone e.g.: if ( "windows" in OS ): vm_tz="GMT Standard Time" else: vm_tz="Etc/GMT" Is there a better way to choose a more appropriate timezone based on the VMs global location? is there a way to get a list of ovirt supported time zones for Windows and Linux and compare that with the VMs location and OS type and then choose an appropriate timezone?

1 0

Info about AD integration and Root CA
by Gianluca Cecchi 25 Feb '19

25 Feb '19

Hello, in docs for 4.2 RHV (I think it applies to oVirt 4.2 too) for attaching to AD there is the statement " To set up secure connection between the LDAP server and the Manager, ensure a PEM- encoded CA certificate has been prepared. See Section D.2, “Setting Up Encrypted Communication between the Manager and an LDAP Server” for more information. " and in Appendix " To set up encrypted communication between the Red Hat Virtualization Manager and an LDAP server, obtain the root CA certificate of the LDAP server. . . " and in readme file referred in the Appendix (/usr/share/doc/ovirt-engine-extension-aaa-ldap-1.3.8/README) there is the command: " Active Directory Windows: > certutil -ca.cert myrootca.der Linux: $ openssl -in myrootca.der -inform DER -out myrootca.pem " In my case on Windows DC (that is a Windows 2012 R2 server with "Domain functional level: Windows Server 2003") I get this error: C:\Users\Administrator.MYDOMAIN>certutil -ca.cert mydomain.der CertUtil: The system cannot find the file specified. C:\Users\Administrator.MYDOMAIN> What does it mean exactly? Thanks in advance, Gianluca

2 2

HostedEngine Unreachable
by Sakhi Hadebe 25 Feb '19

25 Feb '19

Hi, Our cluster was running fine, until we moved it to the new network. Looking at the agent.log file, it stills pings the old gateway. Not sure if this is the reason it's failing the liveliness check. Please help. On Thu, Feb 21, 2019 at 4:39 PM Sakhi Hadebe <sakhi(a)sanren.ac.za> wrote: > Hi, > > I need some help. We had a working ovirt cluster in the testing > environment. We have just moved it to the production environment with the > same network settings. The only thing we changed is the public VLAN. In > production we're using a different subnet. > > The problem is we can't get the HostedEngine Up. It does come up but it > fails the LIVELINESS CHECK and its health status is bad. We can't ping even > ping it. It is on the same subnet as host machines: 192.168.x.x/24: > > *HostedEngine VM status:* > > [root@garlic qemu]# hosted-engine --vm-status > > > --== Host 1 status ==-- > > conf_on_shared_storage : True > Status up-to-date : True > Hostname : goku.sanren.ac.za > Host ID : 1 > Engine status : {"reason": "vm not running on this > host", "health": "bad", "vm": "down", "detail": "unknown"} > Score : 3400 > stopped : False > Local maintenance : False > crc32 : 57b2ece9 > local_conf_timestamp : 8463 > Host timestamp : 8463 > Extra metadata (valid at timestamp): > metadata_parse_version=1 > metadata_feature_version=1 > timestamp=8463 (Thu Feb 21 16:32:29 2019) > host-id=1 > score=3400 > vm_conf_refresh_time=8463 (Thu Feb 21 16:32:29 2019) > conf_on_shared_storage=True > maintenance=False > state=EngineDown > stopped=False > > > --== Host 2 status ==-- > > conf_on_shared_storage : True > Status up-to-date : True > Hostname : garlic.sanren.ac.za > Host ID : 2 > Engine status : {"reason": "failed liveliness check", > "health": "bad", "vm": "up", "detail": "Powering down"} > Score : 3400 > stopped : False > Local maintenance : False > crc32 : 71dc3daf > local_conf_timestamp : 8540 > Host timestamp : 8540 > Extra metadata (valid at timestamp): > metadata_parse_version=1 > metadata_feature_version=1 > timestamp=8540 (Thu Feb 21 16:32:31 2019) > host-id=2 > score=3400 > vm_conf_refresh_time=8540 (Thu Feb 21 16:32:31 2019) > conf_on_shared_storage=True > maintenance=False > state=EngineStop > stopped=False > timeout=Thu Jan 1 04:24:29 1970 > > > --== Host 3 status ==-- > > conf_on_shared_storage : True > Status up-to-date : True > Hostname : gohan.sanren.ac.za > Host ID : 3 > Engine status : {"reason": "vm not running on this > host", "health": "bad", "vm": "down", "detail": "unknown"} > Score : 3400 > stopped : False > Local maintenance : False > crc32 : 49645620 > local_conf_timestamp : 5480 > Host timestamp : 5480 > Extra metadata (valid at timestamp): > metadata_parse_version=1 > metadata_feature_version=1 > timestamp=5480 (Thu Feb 21 16:32:22 2019) > host-id=3 > score=3400 > vm_conf_refresh_time=5480 (Thu Feb 21 16:32:22 2019) > conf_on_shared_storage=True > maintenance=False > state=EngineDown > stopped=False > You have new mail in /var/spool/mail/root > > The service are running but with errors: > *vdsmd.service:* > [root@garlic qemu]# systemctl status vdsmd > ● vdsmd.service - Virtual Desktop Server Manager > Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor > preset: enabled) > Active: active (running) since Thu 2019-02-21 16:12:12 SAST; 3min 31s > ago > Process: 40117 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh > --post-stop (code=exited, status=0/SUCCESS) > Process: 40121 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh > --pre-start (code=exited, status=0/SUCCESS) > Main PID: 40224 (vdsmd) > Tasks: 47 > CGroup: /system.slice/vdsmd.service > ├─40224 /usr/bin/python2 /usr/share/vdsm/vdsmd > └─40346 /usr/libexec/ioprocess --read-pipe-fd 65 > --write-pipe-fd 64 --max-threads 10 --max-queued-requests 10 > > Feb 21 16:12:11 garlic.sanren.ac.za vdsmd_init_common.sh[40121]: vdsm: > Running nwfilter > Feb 21 16:12:11 garlic.sanren.ac.za vdsmd_init_common.sh[40121]: libvirt: > Network Filter Driver error : Requested operation is not valid: nwfilter is > in use > Feb 21 16:12:11 garlic.sanren.ac.za vdsmd_init_common.sh[40121]: vdsm: > Running dummybr > Feb 21 16:12:12 garlic.sanren.ac.za vdsmd_init_common.sh[40121]: vdsm: > Running tune_system > Feb 21 16:12:12 garlic.sanren.ac.za vdsmd_init_common.sh[40121]: vdsm: > Running test_space > Feb 21 16:12:12 garlic.sanren.ac.za vdsmd_init_common.sh[40121]: vdsm: > Running test_lo > Feb 21 16:12:12 garlic.sanren.ac.za systemd[1]: Started Virtual Desktop > Server Manager. > Feb 21 16:12:13 garlic.sanren.ac.za vdsm[40224]: WARN MOM not available. > Feb 21 16:12:13 garlic.sanren.ac.za vdsm[40224]: WARN MOM not available, > KSM stats will be missing. > Feb 21 16:12:13 garlic.sanren.ac.za vdsm[40224]: WARN Not ready yet, > ignoring event '|virt|VM_status|e2608f14-39fe-4ab6-b6be-9c60679e8c76' > args={'e2608f14-39fe-4ab6-b6be-9c606..., 'type': ' > Hint: Some lines were ellipsized, use -l to show in full. > > *libvirtd.service:* > [root@garlic qemu]# systemctl status libvirtd > ● libvirtd.service - Virtualization daemon > Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; > vendor preset: enabled) > Drop-In: /etc/systemd/system/libvirtd.service.d > └─unlimited-core.conf > Active: active (running) since Thu 2019-02-21 16:06:50 SAST; 9min ago > Docs: man:libvirtd(8) > https://libvirt.org > Main PID: 38485 (libvirtd) > Tasks: 17 (limit: 32768) > CGroup: /system.slice/libvirtd.service > └─38485 /usr/sbin/libvirtd --listen > > Feb 21 16:06:50 garlic.sanren.ac.za systemd[1]: Starting Virtualization > daemon... > Feb 21 16:06:50 garlic.sanren.ac.za systemd[1]: Started Virtualization > daemon. > Feb 21 16:07:43 garlic.sanren.ac.za libvirtd[38485]: 2019-02-21 > 14:07:43.033+0000: 38485: info : libvirt version: 3.9.0, package: > 14.el7_5.8 (CentOS BuildSystem <http://bugs.c...centos.org) > Feb 21 16:07:43 garlic.sanren.ac.za libvirtd[38485]: 2019-02-21 > 14:07:43.033+0000: 38485: info : hostname: garlic.sanren.ac.za > Feb 21 16:07:43 garlic.sanren.ac.za libvirtd[38485]: 2019-02-21 > 14:07:43.033+0000: 38485: error : virNetSocketReadWire:1808 : End of file > while reading data: Input/output error > Feb 21 16:12:08 garlic.sanren.ac.za libvirtd[38485]: 2019-02-21 > 14:12:08.791+0000: 38485: error : virNetSocketReadWire:1808 : End of file > while reading data: Input/output error > Hint: Some lines were ellipsized, use -l to show in full. > > *ovirt-ha-broker & ovirt-ha-agent services:* > [root@garlic qemu]# systemctl restart ovirt-ha-broker > ^[[A[root@garlic qemu]# systemctl status ovirt-ha-broker > ● ovirt-ha-broker.service - oVirt Hosted Engine High Availability > Communications Broker > Loaded: loaded (/usr/lib/systemd/system/ovirt-ha-broker.service; > enabled; vendor preset: disabled) > Active: active (running) since Thu 2019-02-21 16:18:43 SAST; 30s ago > Main PID: 41493 (ovirt-ha-broker) > Tasks: 13 > CGroup: /system.slice/ovirt-ha-broker.service > ├─41493 /usr/bin/python > /usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker > ├─41688 /bin/sh /usr/sbin/hosted-engine --check-liveliness > └─41689 python -m ovirt_hosted_engine_setup.check_liveliness > > Feb 21 16:18:43 garlic.sanren.ac.za systemd[1]: Started oVirt Hosted > Engine High Availability Communications Broker. > Feb 21 16:18:43 garlic.sanren.ac.za systemd[1]: Starting oVirt Hosted > Engine High Availability Communications Broker... > [root@garlic qemu]# systemctl status ovirt-ha-agent > ● ovirt-ha-agent.service - oVirt Hosted Engine High Availability > Monitoring Agent > Loaded: loaded (/usr/lib/systemd/system/ovirt-ha-agent.service; > enabled; vendor preset: disabled) > Active: active (running) since Thu 2019-02-21 16:18:53 SAST; 25s ago > Main PID: 41581 (ovirt-ha-agent) > Tasks: 2 > CGroup: /system.slice/ovirt-ha-agent.service > └─41581 /usr/bin/python > /usr/share/ovirt-hosted-engine-ha/ovirt-ha-agent > > Feb 21 16:18:53 garlic.sanren.ac.za systemd[1]: Started oVirt Hosted > Engine High Availability Monitoring Agent. > Feb 21 16:18:53 garlic.sanren.ac.za systemd[1]: Starting oVirt Hosted > Engine High Availability Monitoring Agent... > > Attached are logs of files that might contain some useful information to > troubleshoot. > > > Your assistance will be highly appreciated > > -- > 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>

2 3

Move infrastructure ,how to change FQDN
by Fabrice SOLER 25 Feb '19

25 Feb '19

Hello, I need to move all the physical infrastructure oVirt to another site (for student education). The node's FQDN and the hosted engine's FQDN must change. The version is ovirt 4.2.8 for the hosted engine and nodes. Is there sommone who know how to do ? Fabrice SOLER

2 1

Ovirt 4.2.8.. Possible bug?
by matteo fedeli 25 Feb '19

25 Feb '19

Hi considering that the deploy with 4.2.7.8 failed I try to reinstall ovirt to version 4.2.8 and there are appened two strange things. During the volume step if i choose jbod mode in the deploy conf remain raid6 type... Why? To solve I have only tried to editing manually the file at line about volume type and the deploy stuck on creating physical volume... this is my conf file: (I used 3 HDDs 500GB each, node,engine + vmstore and data) #gdeploy configuration generated by cockpit-gluster plugin [hosts] kansas.planet.bn germany.planet.bn singapore.planet.bn [script1:kansas.planet.bn] action=execute ignore_script_errors=no file=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d sdb -h kansas.planet.bn, germany.planet.bn, singapore.planet.bn [script1:germany.planet.bn] action=execute ignore_script_errors=no file=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d sdb -h kansas.planet.bn, germany.planet.bn, singapore.planet.bn [script1:singapore.planet.bn] action=execute ignore_script_errors=no file=/usr/share/gdeploy/scripts/grafton-sanity-check.sh -d sdb -h kansas.planet.bn, germany.planet.bn, singapore.planet.bn [disktype] jbod [diskcount] 12 [stripesize] 256 [service1] action=enable service=chronyd [service2] action=restart service=chronyd [shell2] action=execute command=vdsm-tool configure --force [script3] action=execute file=/usr/share/gdeploy/scripts/blacklist_all_disks.sh ignore_script_errors=no [pv1:kansas.planet.bn] action=create devices=sdb ignore_pv_errors=no [pv1:germany.planet.bn] action=create devices=sdb ignore_pv_errors=no [pv1:singapore.planet.bn] action=create devices=sdb ignore_pv_errors=no [vg1:kansas.planet.bn] action=create vgname=gluster_vg_sdb pvname=sdb ignore_vg_errors=no [vg1:germany.planet.bn] action=create vgname=gluster_vg_sdb pvname=sdb ignore_vg_errors=no [vg1:singapore.planet.bn] action=create vgname=gluster_vg_sdb pvname=sdb ignore_vg_errors=no [lv1:kansas.planet.bn] action=create poolname=gluster_thinpool_sdb ignore_lv_errors=no vgname=gluster_vg_sdb lvtype=thinpool size=1005GB poolmetadatasize=5GB [lv2:germany.planet.bn] action=create poolname=gluster_thinpool_sdb ignore_lv_errors=no vgname=gluster_vg_sdb lvtype=thinpool size=1005GB poolmetadatasize=5GB [lv3:singapore.planet.bn] action=create poolname=gluster_thinpool_sdb ignore_lv_errors=no vgname=gluster_vg_sdb lvtype=thinpool size=1005GB poolmetadatasize=5GB [lv4:kansas.planet.bn] action=create lvname=gluster_lv_engine ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/engine size=100GB lvtype=thick [lv5:kansas.planet.bn] action=create lvname=gluster_lv_data ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/data lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=500GB [lv6:kansas.planet.bn] action=create lvname=gluster_lv_vmstore ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/vmstore lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=500GB [lv7:germany.planet.bn] action=create lvname=gluster_lv_engine ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/engine size=100GB lvtype=thick [lv8:germany.planet.bn] action=create lvname=gluster_lv_data ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/data lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=500GB [lv9:germany.planet.bn] action=create lvname=gluster_lv_vmstore ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/vmstore lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=500GB [lv10:singapore.planet.bn] action=create lvname=gluster_lv_engine ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/engine size=100GB lvtype=thick [lv11:singapore.planet.bn] action=create lvname=gluster_lv_data ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/data lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=500GB [lv12:singapore.planet.bn] action=create lvname=gluster_lv_vmstore ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/vmstore lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=500GB [selinux] yes [service3] action=restart service=glusterd slice_setup=yes [firewalld] action=add ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp,54322/tcp services=glusterfs [script2] action=execute file=/usr/share/gdeploy/scripts/disable-gluster-hooks.sh [shell3] action=execute command=usermod -a -G gluster qemu [volume1] action=create volname=engine transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=kansas.planet.bn:/gluster_bricks/engine/engine,germany.planet.bn:/gluster_bricks/engine/engine,singapore.planet.bn:/gluster_bricks/engine/engine ignore_volume_errors=no [volume2] action=create volname=data transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=kansas.planet.bn:/gluster_bricks/data/data,germany.planet.bn:/gluster_bricks/data/data,singapore.planet.bn:/gluster_bricks/data/data ignore_volume_errors=no [volume3] action=create volname=vmstore transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=kansas.planet.bn:/gluster_bricks/vmstore/vmstore,germany.planet.bn:/gluster_bricks/vmstore/vmstore,singapore.planet.bn:/gluster_bricks/vmstore/vmstore ignore_volume_errors=no

3 4

Re: Ovirt Glusterfs
by Strahil 25 Feb '19

25 Feb '19

I have done some testing and it seems that storhaug + ctdb + nfs-ganesha is showing decent performance in a 3 node hyperconverged setup. Fuse mounts are hitting some kind of limit when mounting gluster -3.12.15 volumes. Best Regards, Strahil Nikolov

3 2

Creating new VM
by Yujin Boby 24 Feb '19

24 Feb '19

I installed oVirt, when i try to create a new VM, it says This host is managed by a virtualization manager, so creation of new VM from this host is not possible. https://imgur.com/a/hpqV6ML Any idea why i am getting this error ? Do i need more than 1 server to create Virtual machines ? Like adding a node ?

2 1

update to 4.2.8 fails
by Vincent Royer 24 Feb '19

24 Feb '19

trying to update from 4.2.6 to 4.2.8 yum update fails with: --> Finished Dependency Resolution Error: Package: vdsm-4.20.46-1.el7.x86_64 (ovirt-4.2) Requires: libvirt-daemon-kvm >= 4.5.0-10.el7_6.3 Installed: libvirt-daemon-kvm-3.9.0-14.el7_5.8.x86_64 (installed) libvirt-daemon-kvm = 3.9.0-14.el7_5.8 Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64 (ovirt-4.2-centos-qemu-ev) Requires: libepoxy.so.0()(64bit) Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64 (ovirt-4.2-centos-qemu-ev) Requires: libibumad.so.3()(64bit) Error: Package: 10:qemu-kvm-ev-2.12.0-18.el7_6.3.1.x86_64 (ovirt-4.2-centos-qemu-ev) Requires: libgbm.so.1()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Uploading Enabled Repositories Report 2019-02-13 16:42:14,190 [INFO] yum:17779:Dummy-18 @connection.py:868 - Connection built: host=subscription.rhsm.redhat.com port=443 handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/ insecure=False Loaded plugins: fastestmirror, product-id, subscription-manager 2019-02-13 16:42:14,199 [WARNING] yum:17779:Dummy-18 @logutil.py:141 - logging already initialized 2019-02-13 16:42:14,200 [ERROR] yum:17779:Dummy-18 @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' 2019-02-13 16:42:14,200 [INFO] yum:17779:Dummy-18 @connection.py:868 - Connection built: host=subscription.rhsm.redhat.com port=443 handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/ insecure=False 2019-02-13 16:42:14,201 [INFO] yum:17779:Dummy-18 @repolib.py:471 - repos updated: Repo updates Total repo updates: 0 Updated <NONE> Added (new) <NONE> Deleted <NONE> This system is not registered with an entitlement server. You can use subscription-manager to register. Cannot upload enabled repos report, is this client registered? [root@brian yum.repos.d]# yum repolist Loaded plugins: enabled_repos_upload, fastestmirror, imgbased-persist, package_upload, product-id, search-disabled-repos, subscription-manager, vdsmupgrade 2019-02-13 16:42:36,489 [ERROR] yum:17809: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' 2019-02-13 16:42:36,490 [INFO] yum:17809:MainThread @connection.py:868 - Connection built: host=subscription.rhsm.redhat.com port=443 handler=/subscription auth=identity_cert ca_dir=/etc/rhsm/ca/ insecure=False 2019-02-13 16:42:36,491 [INFO] yum:17809:MainThread @repolib.py:471 - repos updated: Repo updates Total repo updates: 0 Updated <NONE> Added (new) <NONE> Deleted <NONE> This system is not registered with an entitlement server. You can use subscription-manager to register. Loading mirror speeds from cached hostfile * ovirt-4.2: mirrors.rit.edu * ovirt-4.2-epel: mirror.sjc02.svwh.net repo id repo name status centos-sclo-rh-release/x86_64 CentOS-7 - SCLo rh 8,113 ovirt-4.2/7 Latest oVirt 4.2 Release 2,558 ovirt-4.2-centos-gluster312/x86_64 CentOS-7 - Gluster 3.12 262 ovirt-4.2-centos-opstools/x86_64 CentOS-7 - OpsTools - release 853 ovirt-4.2-centos-ovirt42/x86_64 CentOS-7 - oVirt 4.2 631 ovirt-4.2-centos-qemu-ev/x86_64 CentOS-7 - QEMU EV 71 ovirt-4.2-epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 *Help!*

6 11