- Users - oVirt List Archives

cockpit-networkmanager
by Jonathan Baecker 06 Oct '18

06 Oct '18

Hello Everybody, I only wanted to ask you, if the ovirt hosts does need the cockpit-networkmanager? I ask because I can not updates my CentOS hosts, I get always the message: Transaction check error: file /usr/share/cockpit/networkmanager/manifest.json from install of cockpit-system-176-2.el7.centos.noarch conflicts with file from package cockpit-networkmanager-172-1.el7.noarch file /usr/share/cockpit/networkmanager/po.ca.js.gz from install of cockpit-system-176-2.el7.centos.noarch conflicts with file from package cockpit-networkmanager-172-1.el7.noarch file /usr/share/cockpit/networkmanager/po.cs.js.gz from install of cockpit-system-176-2.el7.centos.noarch conflicts with file from package cockpit-networkmanager-172-1.el7.noarch ... When I remove the cockpit-networkmanager the error is gone, but after making a yum update I'm not able to reinstall the cockpit-networkmanager because it is still want to use the old version. Jonathan

1 0

master domain wont activate
by Vincent Royer 06 Oct '18

06 Oct '18

I was attempting to migrate from nfs to iscsi storage domains. I have reached a state where I can no longer activate the old master storage domain, and thus no others will activate either. I'm ready to give up on the installation and just move to an HCI deployment instead. Wipe all the hosts clean and start again. My plan was to create and use an export domain, then wipe the nodes and set them up HCI where I could re-import. But without being able to activate a master domain, I can't create the export domain. I'm not sure why it can't find the master anymore, as nothing has happened to the NFS storage, but the error in vdsm says it just can't find it: StoragePoolMasterNotFound: Cannot find master domain: u'spUUID=5a77bed1-0238-030c-0122-0000000003b3, msdUUID=d3165759-07c2-46ae-b7b8-b6226a929d68' 2018-10-03 22:40:33,751-0700 INFO (jsonrpc/3) [storage.TaskManager.Task] (Task='83f33db5-90f3-4064-87df-0512ab9b6378') aborting: Task is aborted: "Cannot find master domain: u'spUUID=5a77bed1-0238-030c-0122-0000000003b3, msdUUID=d3165759-07c2-46ae-b7b8-b6226a929d68'" - code 304 (task:1181) 2018-10-03 22:40:33,751-0700 ERROR (jsonrpc/3) [storage.Dispatcher] FINISH connectStoragePool error=Cannot find master domain: u'spUUID=5a77bed1-0238-030c-0122-0000000003b3, msdUUID=d3165759-07c2-46ae-b7b8-b6226a929d68' (dispatcher:82) 2018-10-03 22:40:33,751-0700 INFO (jsonrpc/3) [jsonrpc.JsonRpcServer] RPC call StoragePool.connect failed (error 304) in 0.17 seconds (__init__:573) 2018-10-03 22:40:34,200-0700 INFO (jsonrpc/1) [api.host] START getStats() from=::ffff:172.16.100.13,39028 (api:46) When I look in cockpit on the hosts, the storage domain is mounted and seems fine.

3 12

Re: Error when running hosted-engine deploy on system with bond of bonds
by Karli Sjöberg 05 Oct '18

05 Oct '18

2 1

Re: Error when running hosted-engine deploy on system with bond of bonds
by Karli Sjöberg 05 Oct '18

05 Oct '18

2 1

Bad libvirt-spice certificate - regenerate?
by Chris Adams 05 Oct '18

05 Oct '18

I have an oVirt 4.1 cluster that was initially installed with 3.5 in 2014. The SSL certificates on the physical hosts in /etc/pki/vdsm/libvirt-spice have a problem - the "not before" date is invalid (it doesn't include a time zone), and so I can't connect to VM consoles from a client with OpenSSL 1.1.0i (up to date Fedora 27). How can I regenerate these certificates? Also, I noticed they expire next year - is that expiration handled automatically? -- Chris Adams <cma(a)cmadams.net>

3 3

Error when running hosted-engine deploy on system with bond of bonds
by Ben Webber 05 Oct '18

05 Oct '18

Hi, I'm trying to set up ovirt using the hosted-engine --deploy command on CentOS7, but am encountering an error. I am running a slightly unusual network configuration. I have two fairly basic non stacked gigabit switches with port channels connecting the two switches together. I have a lacp bond from the host consisting of 4 ports to each switch (bond1 and bond2). I have then created an active-backup bond (bond0) using the two lacp bonds as slaves in the hope to create ha at the switch layer using my basic switches. There is then a VLAN (101) on bond0. This network configuration runs fine on the host, however, when run, after a short while, the hosted-engine --deploy command outputs the following error: ... [ INFO ] TASK [Force host-deploy in offline mode] [ INFO ] ok: [localhost] [ INFO ] TASK [Add host] [ INFO ] changed: [localhost] [ INFO ] TASK [Wait for the host to be up] [ INFO ] ok: [localhost] [ INFO ] TASK [Check host status] [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The host has been set in non_operational status, please check engine logs, fix accordingly and re-deploy.\n"} ... Looking in /var/log/ovirt-engine/engine.log on the machine created, I can see the following errors logged: ... 2018-10-04 21:51:30,116+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (EE-ManagedThreadFactory-engine-Thread-1) [59fb360a] START, HostSetupNetworksVDSCommand(HostName = ov1.test.local, HostSetupNetworksVdsCommandParameters:{hostId='7440c9b9-e530-4341-a317-d3a9041dc777', vds='Host[ov1.test.local,7440c9b9-e530-4341-a317-d3a9041dc777]', rollbackOnFailure='true', connectivityTimeout='120', networks='[HostNetwork:{defaultRoute='true', bonding='true', networkName='ovirtmgmt', vdsmName='ovirtmgmt', nicName='bond0', vlan='101', vmNetwork='true', stp='false', properties='null', ipv4BootProtocol='STATIC_IP', ipv4Address='192.168.1.11', ipv4Netmask='255.255.255.0', ipv4Gateway='192.168.1.1', ipv6BootProtocol='AUTOCONF', ipv6Address='null', ipv6Prefix='null', ipv6Gateway='null', nameServers='null'}]', removedNetworks='[]', bonds='[]', removedBonds='[]', clusterSwitchType='LEGACY'}), log id: 4f0c7eaa 2018-10-04 21:51:30,121+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (EE-ManagedThreadFactory-engine-Thread-1) [59fb360a] FINISH, HostSetupNetworksVDSCommand, log id: 4f0c7eaa 2018-10-04 21:51:30,645+01 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (EE-ManagedThreadFactory-engine-Thread-1) [59fb360a] Failed in 'HostSetupNetworksVDS' method 2018-10-04 21:51:30,687+01 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-1) [59fb360a] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ov1.test.local command HostSetupNetworksVDS failed: Unknown nics in: ['bond1', 'bond2'] 2018-10-04 21:51:30,688+01 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (EE-ManagedThreadFactory-engine-Thread-1) [59fb360a] Error: VDSGenericException: VDSErrorException: Failed to HostSetupNetworksVDS, error = Unknown nics in: ['bond1', 'bond2'], code = 23 ... It looks like when HostSetupNetworksVDS is run, it is checking that the slave interfaces to the bonds are physical network devices and being as the slaves of bond0 are bond1 and bond2, rather than physical devices, it then throws the error Unknown nics in: ['bond1', 'bond2']. Is there anything I can do or any configuration that I can put anywhere to make it work with this "stacked bond" configuration or does ovirt just not work when bonds are set up like this? Thanks in advance, Ben

3 9

[ANN] oVirt Node 4.2.6 async update is now available
by Sandro Bonazzola 05 Oct '18

05 Oct '18

The oVirt Team has just released a new version of oVirt Node image including latest CentOS updates, fixing a regression introduced in kernel package [1] breaking IP over infiniband. We recommend to users to upgrade to this new release. Errata included: CEEA-2018:2397 CentOS 7 microcode_ctl Enhancement Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023021.ht…> CESA-2018:2748 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023027.ht…> CEBA-2018:2760 CentOS 7 ipa BugFix Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023029.ht…> CESA-2018:2768 Moderate CentOS 7 nss Security Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023030.ht…> CEBA-2018:2753 CentOS 7 systemd BugFix Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023033.ht…> CEBA-2018:2756 CentOS 7 sssd BugFix Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023034.ht…> CEBA-2018:2769 CentOS 7 libvirt BugFix Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023038.ht…> CEBA-2018:2761 CentOS 7 kexec-tools BugFix Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023041.ht…> CEBA-2018:2758 CentOS 7 firewalld BugFix Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023045.ht…> CEBA-2018:2764 CentOS 7 initscripts BugFix Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023046.ht…> CESA-2018:2731 Important CentOS 7 spice Security Update <https://lists.centos.org/pipermail/centos-announce/2018-September/023047.ht…> Ansible 2.6.5: https://github.com/ansible/ansible/blob/v2.6.5/changelogs/CHANGELOG-v2.6.rst Cockpit 176: https://cockpit-project.org/blog/cockpit-176.html Updates included: +ansible-2.6.5-1.el7.noarch +cockpit-176-2.el7.centos.x86_64 +cockpit-bridge-176-2.el7.centos.x86_64 +cockpit-dashboard-176-2.el7.centos.x86_64 +cockpit-machines-ovirt-176-2.el7.centos.noarch +cockpit-storaged-176-2.el7.centos.noarch +cockpit-system-176-2.el7.centos.noarch +cockpit-ws-176-2.el7.centos.x86_64 +firewalld-0.4.4.4-15.el7_5.noarch +firewalld-filesystem-0.4.4.4-15.el7_5.noarch +initscripts-9.49.41-1.el7_5.2.x86_64 +ipa-client-4.5.4-10.el7.centos.4.4.x86_64 +ipa-client-common-4.5.4-10.el7.centos.4.4.noarch +ipa-common-4.5.4-10.el7.centos.4.4.noarch +kernel-3.10.0-862.14.4.el7.x86_64 +kernel-tools-3.10.0-862.14.4.el7.x86_64 +kernel-tools-libs-3.10.0-862.14.4.el7.x86_64 +kexec-tools-2.0.15-13.el7_5.2.x86_64 +libgudev1-219-57.el7_5.3.x86_64 +libipa_hbac-1.16.0-19.el7_5.8.x86_64 +libsss_autofs-1.16.0-19.el7_5.8.x86_64 +libsss_certmap-1.16.0-19.el7_5.8.x86_64 +libsss_idmap-1.16.0-19.el7_5.8.x86_64 +libsss_nss_idmap-1.16.0-19.el7_5.8.x86_64 +libsss_sudo-1.16.0-19.el7_5.8.x86_64 +libvirt-3.9.0-14.el7_5.8.x86_64 +libvirt-client-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-config-network-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-config-nwfilter-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-interface-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-lxc-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-network-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-nodedev-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-nwfilter-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-qemu-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-secret-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-storage-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-storage-core-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-storage-disk-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-storage-gluster-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-storage-iscsi-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-storage-logical-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-storage-mpath-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-storage-rbd-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-driver-storage-scsi-3.9.0-14.el7_5.8.x86_64 +libvirt-daemon-kvm-3.9.0-14.el7_5.8.x86_64 +libvirt-libs-3.9.0-14.el7_5.8.x86_64 +libvirt-lock-sanlock-3.9.0-14.el7_5.8.x86_64 +microcode_ctl-2.1-29.16.el7_5.x86_64 +mokutil-12-2.el7.x86_64 +nss-3.36.0-7.el7_5.x86_64 +nss-sysinit-3.36.0-7.el7_5.x86_64 +nss-tools-3.36.0-7.el7_5.x86_64 +ovirt-node-ng-image-update-placeholder-4.2.6.2-1.el7.noarch +ovirt-node-ng-nodectl-4.2.0-0.20181003.0.el7.noarch +ovirt-release-host-node-4.2.6.2-1.el7.noarch +ovirt-release42-4.2.6.2-1.el7.noarch +python-firewall-0.4.4.4-15.el7_5.noarch +python-libipa_hbac-1.16.0-19.el7_5.8.x86_64 +python-perf-3.10.0-862.14.4.el7.x86_64 +python-sss-murmur-1.16.0-19.el7_5.8.x86_64 +python-sssdconfig-1.16.0-19.el7_5.8.noarch +python2-ipaclient-4.5.4-10.el7.centos.4.4.noarch +python2-ipalib-4.5.4-10.el7.centos.4.4.noarch +shim-x64-12-2.el7.x86_64 +spice-server-0.14.0-2.el7_5.5.x86_64 +sssd-1.16.0-19.el7_5.8.x86_64 +sssd-ad-1.16.0-19.el7_5.8.x86_64 +sssd-client-1.16.0-19.el7_5.8.x86_64 +sssd-common-1.16.0-19.el7_5.8.x86_64 +sssd-common-pac-1.16.0-19.el7_5.8.x86_64 +sssd-ipa-1.16.0-19.el7_5.8.x86_64 +sssd-krb5-1.16.0-19.el7_5.8.x86_64 +sssd-krb5-common-1.16.0-19.el7_5.8.x86_64 +sssd-ldap-1.16.0-19.el7_5.8.x86_64 +sssd-proxy-1.16.0-19.el7_5.8.x86_64 +systemd-219-57.el7_5.3.x86_64 +systemd-libs-219-57.el7_5.3.x86_64 +systemd-python-219-57.el7_5.3.x86_64 +systemd-sysv-219-57.el7_5.3.x86_64 Thanks, [1] https://bugs.centos.org/view.php?id=15193 -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://www.redhat.com/en/events/red-hat-open-source-day-italia?sc_cid=701f…>

5 7

Failed to lock byte 100 - when booting VM with attached CD
by Simon Vincent 05 Oct '18

05 Oct '18

I have found recently I can't boot any VMs which have a CD attached to it. I get the following error. VM Test is down with error. Exit message: internal error: qemu unexpectedly closed the monitor: 2018-10-04T11:53:07.031875Z qemu-kvm: -device ide-cd,bus=ide.1,unit=0,drive=drive-ua-5ccd6310-a1e5-4019-b989-795529c70794,id=ua-5ccd6310-a1e5-4019-b989-795529c70794,bootindex=2: Failed to lock byte 100 2018-10-04T11:53:07.032264Z qemu-kvm: -device ide-cd,bus=ide.1,unit=0,drive=drive-ua-5ccd6310-a1e5-4019-b989-795529c70794,id=ua-5ccd6310-a1e5-4019-b989-795529c70794,bootindex=2: Failed to lock byte 100 2018-10-04T11:53:07.032285Z qemu-kvm: -device ide-cd,bus=ide.1,unit=0,drive=drive-ua-5ccd6310-a1e5-4019-b989-795529c70794,id=ua-5ccd6310-a1e5-4019-b989-795529c70794,bootindex=2: Failed to lock byte 100 Unexpected error in raw_apply_lock_bytes() at block/file-posix.c:642: 2018-10-04T11:53:07.032665Z qemu-kvm: -device ide-cd,bus=ide.1,unit=0,drive=drive-ua-5ccd6310-a1e5-4019-b989-795529c70794,id=ua-5ccd6310-a1e5-4019-b989-795529c70794,bootindex=2: Failed to lock byte 100. I have tried relaxing the permissions on the iSO NFS share and even removed the iSO domain and added a new one, but I still get the problem. Regards Simon

2 1

iso domain don't list available images
by Nathanaël Blanchet 04 Oct '18

04 Oct '18

Hello, I detached an existing iso domain from an other ovirt instance and attached it to on a fresh 4.2 install, but no images are available. Is it a known bug? -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

2 2

Unable to mount CephFS as POSIX Compliant FS
by ryan.terpstra＠gmail.com 04 Oct '18

04 Oct '18

I have a ceph filesystem that I can manually mount on my ovirt host. [root@ovirt121 ~]# mount -t ceph ceph01:/ /mnt -o name=admin,secret=<secret removed for security> [root@ovirt121 ~]# touch /mnt/test works great! Then I umount that filesystem and attempt to add storage domain in ovirt engine. Settings: Storage type: POSIX compliant FS Host to use: ovirt121 name: cephdata Path: ceph01:/ vfs type: ceph mount options: name=admin,secret=<secret removed for security> In the oVirt web UI I get a "General Exception" error. On the host I see this in vdsm.log: 2018-10-03 23:47:58,165+0000 INFO (jsonrpc/6) [vdsm.api] START connectStorageServer(domType=6, spUUID=u'00000000-0000-0000-0000-000000000000', conList=[{u'mnt_options': u'name=admin,secret=AQDJI7RbS4Z2GhAAhlyWUvX7wtPNzO6n5vqjsQ==', u'id': u'00000000-0000-0000-0000-000000000000', u'connection': u'ceph01:/', u'iqn': u'', u'user': u'', u'tpgt': u'1', u'vfs_type': u'ceph', u'password': '********', u'port': u''}], options=None) from=::ffff:10.78.7.221,54910, flow_id=ba106a2d-e204-4da7-acc7-29b70c3ff759, task_id=b5e0c87c-8838-4b49-8590-11382a02d67f (api:46) 2018-10-03 23:47:58,166+0000 INFO (jsonrpc/6) [storage.StorageServer.MountConnection] Creating directory u'/rhev/data-center/mnt/ceph01:_' (storageServer:167) 2018-10-03 23:47:58,166+0000 INFO (jsonrpc/6) [storage.fileUtils] Creating directory: /rhev/data-center/mnt/ceph01:_ mode: None (fileUtils:197) 2018-10-03 23:47:58,166+0000 INFO (jsonrpc/6) [storage.Mount] mounting ceph01:/ at /rhev/data-center/mnt/ceph01:_ (mount:204) 2018-10-03 23:47:58,218+0000 ERROR (jsonrpc/6) [storage.HSM] Could not connect to storageServer (hsm:2415) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 2412, in connectStorageServer conObj.connect() File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py", line 183, in connect self.getMountObj().getRecord().fs_file) File "/usr/lib/python2.7/site-packages/vdsm/storage/mount.py", line 253, in getRecord (self.fs_spec, self.fs_file)) OSError: [Errno 2] Mount of `ceph01:/` at `/rhev/data-center/mnt/ceph01:_` does not exist 2018-10-03 23:47:58,218+0000 INFO (jsonrpc/6) [vdsm.api] FINISH connectStorageServer return={'statuslist': [{'status': 100, 'id': u'00000000-0000-0000-0000-000000000000'}]} from=::ffff:10.78.7.221,54910, flow_id=ba106a2d-e204-4da7-acc7-29b70c3ff759, task_id=b5e0c87c-8838-4b49-8590-11382a02d67f (api:52) However, if i run "monut" or "cat /proc/mounts" I can see the cephfs was properly mounted, I can even touch files. [root@ovirt121 ~]# touch /rhev/data-center/mnt/ceph01\:_/ceph_ovirt_test [root@ovirt121 ~]# [root@ovirt121 ~]# cat /proc/mounts <...bunch of mounts...> 10.78.71.1:/ /rhev/data-center/mnt/ceph01:_ ceph rw,relatime,name=admin,secret=<hidden>,acl,wsize=16777216 0 0 [root@ovirt121 ~]# Any thoughts? oVirt version is 4.2.6.4-1.el7, running on CentOS 7 18.05.

3 3