[ANN] oVirt 4.4.8 Async update #1
by Sandro Bonazzola
oVirt 4.4.8 Async update #1
On August 26th 2021 the oVirt project released an async update to the
following packages:
-
ovirt-ansible-collection 1.6.2
-
ovirt-engine 4.4.8.5
-
ovirt-release44 4.4.8.1
-
oVirt Node 4.4.8.1
-
oVirt Appliance 4.4-20210826
Fixing the following bugs:
-
Bug 1947709 <https://bugzilla.redhat.com/show_bug.cgi?id=1947709> -
[IPv6] HostedEngineLocal is an isolated libvirt network, breaking upgrades
from 4.3
-
Bug 1966873 <https://bugzilla.redhat.com/show_bug.cgi?id=1966873> -
[RFE] Create Ansible role for remove stale LUNs example
remove_mpath_device.yml
-
Bug 1997663 <https://bugzilla.redhat.com/show_bug.cgi?id=1997663> - Keep
cinbderlib dependencies optional for 4.4.8
-
Bug 1996816 <https://bugzilla.redhat.com/show_bug.cgi?id=1996816> -
Cluster upgrade fails with: 'OAuthException invalid_grant: The provided
authorization grant for the auth code has expired.
oVirt Node Changes:
- Consume above oVirt updates
- GlusterFS 8.6: https://docs.gluster.org/en/latest/release-notes/8.6/
- Fixes for:
-
CVE-2021-22923 <https://access.redhat.com/security/cve/CVE-2021-22923>
curl: Metalink download sends credentials
-
CVE-2021-22922 <https://access.redhat.com/security/cve/CVE-2021-22922>
curl: Content not matching hash in Metalink is not being discarded
Full diff list:
--- ovirt-node-ng-image-4.4.8.manifest-rpm 2021-08-19 07:57:44.081590739
+0200
+++ ovirt-node-ng-image-4.4.8.1.manifest-rpm 2021-08-27 08:11:54.863736688
+0200
@@ -2,7 +2,7 @@
-ModemManager-glib-1.10.8-3.el8.x86_64
-NetworkManager-1.32.6-1.el8.x86_64
-NetworkManager-config-server-1.32.6-1.el8.noarch
-NetworkManager-libnm-1.32.6-1.el8.x86_64
-NetworkManager-ovs-1.32.6-1.el8.x86_64
-NetworkManager-team-1.32.6-1.el8.x86_64
-NetworkManager-tui-1.32.6-1.el8.x86_64
+ModemManager-glib-1.10.8-4.el8.x86_64
+NetworkManager-1.32.8-1.el8.x86_64
+NetworkManager-config-server-1.32.8-1.el8.noarch
+NetworkManager-libnm-1.32.8-1.el8.x86_64
+NetworkManager-ovs-1.32.8-1.el8.x86_64
+NetworkManager-team-1.32.8-1.el8.x86_64
+NetworkManager-tui-1.32.8-1.el8.x86_64
@@ -94 +94 @@
-curl-7.61.1-18.el8.x86_64
+curl-7.61.1-18.el8_4.1.x86_64
@@ -106,4 +106,4 @@
-device-mapper-1.02.177-5.el8.x86_64
-device-mapper-event-1.02.177-5.el8.x86_64
-device-mapper-event-libs-1.02.177-5.el8.x86_64
-device-mapper-libs-1.02.177-5.el8.x86_64
+device-mapper-1.02.177-6.el8.x86_64
+device-mapper-event-1.02.177-6.el8.x86_64
+device-mapper-event-libs-1.02.177-6.el8.x86_64
+device-mapper-libs-1.02.177-6.el8.x86_64
@@ -140,36 +140,36 @@
-fence-agents-all-4.2.1-74.el8.x86_64
-fence-agents-amt-ws-4.2.1-74.el8.noarch
-fence-agents-apc-4.2.1-74.el8.noarch
-fence-agents-apc-snmp-4.2.1-74.el8.noarch
-fence-agents-bladecenter-4.2.1-74.el8.noarch
-fence-agents-brocade-4.2.1-74.el8.noarch
-fence-agents-cisco-mds-4.2.1-74.el8.noarch
-fence-agents-cisco-ucs-4.2.1-74.el8.noarch
-fence-agents-common-4.2.1-74.el8.noarch
-fence-agents-compute-4.2.1-74.el8.noarch
-fence-agents-drac5-4.2.1-74.el8.noarch
-fence-agents-eaton-snmp-4.2.1-74.el8.noarch
-fence-agents-emerson-4.2.1-74.el8.noarch
-fence-agents-eps-4.2.1-74.el8.noarch
-fence-agents-heuristics-ping-4.2.1-74.el8.noarch
-fence-agents-hpblade-4.2.1-74.el8.noarch
-fence-agents-ibmblade-4.2.1-74.el8.noarch
-fence-agents-ifmib-4.2.1-74.el8.noarch
-fence-agents-ilo-moonshot-4.2.1-74.el8.noarch
-fence-agents-ilo-mp-4.2.1-74.el8.noarch
-fence-agents-ilo-ssh-4.2.1-74.el8.noarch
-fence-agents-ilo2-4.2.1-74.el8.noarch
-fence-agents-intelmodular-4.2.1-74.el8.noarch
-fence-agents-ipdu-4.2.1-74.el8.noarch
-fence-agents-ipmilan-4.2.1-74.el8.noarch
-fence-agents-kdump-4.2.1-74.el8.x86_64
-fence-agents-mpath-4.2.1-74.el8.noarch
-fence-agents-redfish-4.2.1-74.el8.x86_64
-fence-agents-rhevm-4.2.1-74.el8.noarch
-fence-agents-rsa-4.2.1-74.el8.noarch
-fence-agents-rsb-4.2.1-74.el8.noarch
-fence-agents-sbd-4.2.1-74.el8.noarch
-fence-agents-scsi-4.2.1-74.el8.noarch
-fence-agents-vmware-rest-4.2.1-74.el8.noarch
-fence-agents-vmware-soap-4.2.1-74.el8.noarch
-fence-agents-wti-4.2.1-74.el8.noarch
+fence-agents-all-4.2.1-75.el8.x86_64
+fence-agents-amt-ws-4.2.1-75.el8.noarch
+fence-agents-apc-4.2.1-75.el8.noarch
+fence-agents-apc-snmp-4.2.1-75.el8.noarch
+fence-agents-bladecenter-4.2.1-75.el8.noarch
+fence-agents-brocade-4.2.1-75.el8.noarch
+fence-agents-cisco-mds-4.2.1-75.el8.noarch
+fence-agents-cisco-ucs-4.2.1-75.el8.noarch
+fence-agents-common-4.2.1-75.el8.noarch
+fence-agents-compute-4.2.1-75.el8.noarch
+fence-agents-drac5-4.2.1-75.el8.noarch
+fence-agents-eaton-snmp-4.2.1-75.el8.noarch
+fence-agents-emerson-4.2.1-75.el8.noarch
+fence-agents-eps-4.2.1-75.el8.noarch
+fence-agents-heuristics-ping-4.2.1-75.el8.noarch
+fence-agents-hpblade-4.2.1-75.el8.noarch
+fence-agents-ibmblade-4.2.1-75.el8.noarch
+fence-agents-ifmib-4.2.1-75.el8.noarch
+fence-agents-ilo-moonshot-4.2.1-75.el8.noarch
+fence-agents-ilo-mp-4.2.1-75.el8.noarch
+fence-agents-ilo-ssh-4.2.1-75.el8.noarch
+fence-agents-ilo2-4.2.1-75.el8.noarch
+fence-agents-intelmodular-4.2.1-75.el8.noarch
+fence-agents-ipdu-4.2.1-75.el8.noarch
+fence-agents-ipmilan-4.2.1-75.el8.noarch
+fence-agents-kdump-4.2.1-75.el8.x86_64
+fence-agents-mpath-4.2.1-75.el8.noarch
+fence-agents-redfish-4.2.1-75.el8.x86_64
+fence-agents-rhevm-4.2.1-75.el8.noarch
+fence-agents-rsa-4.2.1-75.el8.noarch
+fence-agents-rsb-4.2.1-75.el8.noarch
+fence-agents-sbd-4.2.1-75.el8.noarch
+fence-agents-scsi-4.2.1-75.el8.noarch
+fence-agents-vmware-rest-4.2.1-75.el8.noarch
+fence-agents-vmware-soap-4.2.1-75.el8.noarch
+fence-agents-wti-4.2.1-75.el8.noarch
@@ -215,7 +215,7 @@
-glusterfs-8.5-2.el8.x86_64
-glusterfs-cli-8.5-2.el8.x86_64
-glusterfs-client-xlators-8.5-2.el8.x86_64
-glusterfs-events-8.5-2.el8.x86_64
-glusterfs-fuse-8.5-2.el8.x86_64
-glusterfs-geo-replication-8.5-2.el8.x86_64
-glusterfs-server-8.5-2.el8.x86_64
+glusterfs-8.6-1.el8.x86_64
+glusterfs-cli-8.6-1.el8.x86_64
+glusterfs-client-xlators-8.6-1.el8.x86_64
+glusterfs-events-8.6-1.el8.x86_64
+glusterfs-fuse-8.6-1.el8.x86_64
+glusterfs-geo-replication-8.6-1.el8.x86_64
+glusterfs-server-8.6-1.el8.x86_64
@@ -301,5 +301,5 @@
-kernel-4.18.0-326.el8.x86_64
-kernel-core-4.18.0-326.el8.x86_64
-kernel-modules-4.18.0-326.el8.x86_64
-kernel-tools-4.18.0-326.el8.x86_64
-kernel-tools-libs-4.18.0-326.el8.x86_64
+kernel-4.18.0-331.el8.x86_64
+kernel-core-4.18.0-331.el8.x86_64
+kernel-modules-4.18.0-331.el8.x86_64
+kernel-tools-4.18.0-331.el8.x86_64
+kernel-tools-libs-4.18.0-331.el8.x86_64
@@ -310 +310 @@
-kmod-kvdo-6.2.5.65-79.el8.x86_64
+kmod-kvdo-6.2.5.72-79.el8.x86_64
@@ -363 +363 @@
-libcurl-7.61.1-18.el8.x86_64
+libcurl-7.61.1-18.el8_4.1.x86_64
@@ -381,6 +381,6 @@
-libgfapi0-8.5-2.el8.x86_64
-libgfchangelog0-8.5-2.el8.x86_64
-libgfrpc0-8.5-2.el8.x86_64
-libgfxdr0-8.5-2.el8.x86_64
-libglusterd0-8.5-2.el8.x86_64
-libglusterfs0-8.5-2.el8.x86_64
+libgfapi0-8.6-1.el8.x86_64
+libgfchangelog0-8.6-1.el8.x86_64
+libgfrpc0-8.6-1.el8.x86_64
+libgfxdr0-8.6-1.el8.x86_64
+libglusterd0-8.6-1.el8.x86_64
+libglusterfs0-8.6-1.el8.x86_64
@@ -416 +415,0 @@
-libmetalink-0.1.3-7.el8.x86_64
@@ -558,2 +557,2 @@
-lvm2-2.03.12-5.el8.x86_64
-lvm2-libs-2.03.12-5.el8.x86_64
+lvm2-2.03.12-6.el8.x86_64
+lvm2-libs-2.03.12-6.el8.x86_64
@@ -641 +640 @@
-ovirt-ansible-collection-1.6.0-1.el8.noarch
+ovirt-ansible-collection-1.6.2-1.el8.noarch
@@ -649 +648 @@
-ovirt-node-ng-image-update-placeholder-4.4.8-1.el8.noarch
+ovirt-node-ng-image-update-placeholder-4.4.8.1-1.el8.noarch
@@ -657,2 +656,2 @@
-ovirt-release-host-node-4.4.8-1.el8.noarch
-ovirt-release44-4.4.8-1.el8.noarch
+ovirt-release-host-node-4.4.8.1-1.el8.noarch
+ovirt-release44-4.4.8.1-1.el8.noarch
@@ -665,3 +664,3 @@
-pacemaker-cluster-libs-2.1.0-5.el8.x86_64
-pacemaker-libs-2.1.0-5.el8.x86_64
-pacemaker-schemas-2.1.0-5.el8.noarch
+pacemaker-cluster-libs-2.1.0-6.el8.x86_64
+pacemaker-libs-2.1.0-6.el8.x86_64
+pacemaker-schemas-2.1.0-6.el8.noarch
@@ -773 +772 @@
-python3-gluster-8.5-2.el8.x86_64
+python3-gluster-8.6-1.el8.x86_64
@@ -835 +834 @@
-python3-perf-4.18.0-326.el8.x86_64
+python3-perf-4.18.0-331.el8.x86_64
@@ -935,2 +934,2 @@
-selinux-policy-3.14.3-75.el8.noarch
-selinux-policy-targeted-3.14.3-75.el8.noarch
+selinux-policy-3.14.3-76.el8.noarch
+selinux-policy-targeted-3.14.3-76.el8.noarch
@@ -941 +940 @@
-shadow-utils-4.6-13.el8.x86_64
+shadow-utils-4.6-14.el8.x86_64
@@ -948 +947 @@
-sos-4.1-4.el8.noarch
+sos-4.1-5.el8.noarch
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://www.redhat.com/>
*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.*
3 years, 3 months
Frequent events seen like VM "vmname" is not responding
by manoj.sharma99765＠gmail.com
I am using oVirt Open Virtualization Manager Software Version:4.4.6.8-1.el8 and we have single node running on oVirt Node 4.4.6.
We are facing slowness while using VM and also we face connection reset issue between VM and Target servers ( Nexus )
We are getting below logs in ovirt manager events
VM "vmname" is not responding
Getting this for all the running VMs .
We checked resources and utilization of the node everything seems very normal. Could you please guide on how can we solve/debug further on this ?
3 years, 3 months
Cannot activate a Storage Domain after an oVirt crash
by nicolas＠devels.es
Hi,
We're running oVirt 4.3.8 and we recently had a oVirt crash after moving
too much disks between storage domains.
Concretely, one of the Storage Domains reports status "Unknown",
"Total/Free/Guaranteed free spaces" are "[N/A]".
After trying to activate it in the Domain Center we see messages like
these from all of the hosts:
VDSM hostX command GetVGInfoVDS failed: Volume Group does not exist:
(u'vg_uuid: Usi3y8-S4eq-EXtl-FA58-MA3K-b4vE-4d9SCp',)
I tried putting the Storage Domain in maintenance and it fails with
messages like:
Storage Domain iaasb13 (Data Center KVMRojo) was deactivated by
system because it's not visible by any of the hosts.
Failed to update OVF disks 8661acd1-d1c4-44a0-a4d4-ddee834844e9, OVF
data isn't updated on those OVF stores (Data Center KVMRojo, Storage
Domain iaasb13).
Failed to update VMs/Templates OVF data for Storage Domain iaasb13
in Data Center KVMRojo.
I'm sure the storage domain backend is up and running, and the LUN being
exported.
Any hints how can I debug this problem and restore the Storage Domain?
Thanks.
3 years, 3 months
Re: Failed to activate Storage Domain --- ovirt 4.2
by fabian.rapetti＠gmail.com
Hi all.
I'm using Ovrit 4.3.10 two nodes cluster and facing the same error (second metadata area corruption).
Does anybody know if there is a solution for that?
Our software include:
lvm2-2.02.186-7.el7_8.2.x86_64
Virt Node 4.3.10
kernel 3.10.0-1127.8.2.el7.x86_64
device-mapper-multipath-libs-0.4.9-131.el7.x86_64
libvirt-4.5.0-33.el7_8.1.x86_64
Thanks in advance
3 years, 3 months
Getting issue in finalize section after disk successfully uploaded
by avishek.sarkar＠broadcom.com
I have used upload-disk.py to upload qcow2 image to data center...however getting below errror
./upload-disk.py --engine-url 'https://xyz.net' --username='xyz(a)abc.net' --password-file=password --sd-name='SEC-ABC' --cafile='/home/jenkins/crt/ca.crt' --disk-format="qcow2" --disk-sparse image-XYZ
Checking image...
Image format: qcow2
Disk format: cow
Disk content type: data
Disk provisioned size: 10737418240
Disk initial size: 5526847488
Disk name: image-avishek.qcow2
Connecting...
Creating disk...
Creating transfer session...
Uploading image...
[ 100.00% ] 10.00 GiB, 11.34 seconds, 903.09 MiB/s
Finalizing transfer session...
Traceback (most recent call last):
File "./upload-disk.py", line 300, in <module>
transfer_service.finalize()
File "/usr/lib64/python3.6/site-packages/ovirtsdk4/services.py", line 13971, in finalize
return self._internal_action(action, 'finalize', None, headers, query, wait)
File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 299, in _internal_action
return future.wait() if wait else future
File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 55, in wait
return self._code(response)
File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 296, in callback
self._check_fault(response)
File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 132, in _check_fault
self._raise_error(response, body)
File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 118, in _raise_error
raise error
ovirtsdk4.AuthError: Fault reason is "Operation Failed". Fault detail is "[User is not authorized to perform this action.]". HTTP response code is 403.
3 years, 3 months
I'm in trouble....
by Wesley Stewart
Luckily this is for a home lab and nothing critical is lost. However I was
trying to change the subnet my host was on. And I found out that you
cant do that. So I reverted back but my hosted engine wasnt happy about my
NFS mounts.
so I did a engine-cleanup and an engine-setup. Went through the prompts
and thought nothing of it. I logged back into ovirt, and everything looks
like it was a brand new install. No VMs or anything. I believe I have a
fairly recent backup somewhere... trying to track that down, but it's not
looking good.
Currently running 4.3.10. I have been planning out my 4.4 upgrade
anyways. I would prefer to not start from scratch... but if I do it is not
the end of the world, will just take a lot more time.
Looking for some guidance! Thank you.
3 years, 3 months
Re: [External] : about the password of the engine host and worker KVM hosts
by Tommy Sway
Thank you!
From: users-bounces(a)ovirt.org <users-bounces(a)ovirt.org> On Behalf Of Marcos
Sungaila
Sent: Friday, September 17, 2021 11:51 PM
To: Tommy Sway <sz_cuitao(a)163.com>; users(a)ovirt.org
Subject: [ovirt-users] Re: [External] : about the password of the engine
host and worker KVM hosts
Hi Tommy,
Yes, you can change root password on all hosts with no problem.
Your cluster will keep working fine.
Regards
Marcos
From: Tommy Sway <sz_cuitao(a)163.com <mailto:sz_cuitao@163.com> >
Sent: sexta-feira, 17 de setembro de 2021 06:12
To: users(a)ovirt.org <mailto:users@ovirt.org>
Subject: [External] : [ovirt-users] about the password of the engine host
and worker KVM hosts
I have successfully installed and deployed OLVM, where the Engine uses a
separate physical server and the virtual machines work on other worker
servers.
Due to the company's internal security policy, I now need to change the root
user password for all servers. Is that ok?
Will cluster running be affected?
Thanks!
3 years, 3 months
Re: about the password of the engine host and worker KVM hosts
by Tommy Sway
Thank you!
From: users-bounces(a)ovirt.org <users-bounces(a)ovirt.org> On Behalf Of
Matthew.Stier(a)fujitsu.com
Sent: Friday, September 17, 2021 11:45 PM
To: Tommy Sway <sz_cuitao(a)163.com>; users(a)ovirt.org
Subject: [ovirt-users] Re: about the password of the engine host and worker
KVM hosts
My understanding, is that OLVM/oVirt use the root password to push it's SSH
credentials at first login. Once that is done, all other SSH access is
though those credentials.
You should be able to change the root password without issue.
From: Tommy Sway <sz_cuitao(a)163.com <mailto:sz_cuitao@163.com> >
Sent: Friday, September 17, 2021 4:12 AM
To: users(a)ovirt.org <mailto:users@ovirt.org>
Subject: [ovirt-users] about the password of the engine host and worker KVM
hosts
I have successfully installed and deployed OLVM, where the Engine uses a
separate physical server and the virtual machines work on other worker
servers.
Due to the company's internal security policy, I now need to change the root
user password for all servers. Is that ok?
Will cluster running be affected?
Thanks!
3 years, 3 months
REST API import VM from Export Domain
by christian.peater＠gmx.de
i'm using OLVM 4.3.10 oVirt and i'm trying to import a VM from the Export Storage Domain with the REST API.
curl command is:
curl \
-X POST \
--header "Version:4" \
--header "Accept:application/xml" \
--header "Content-type:application/xml" \
--user $_OLVM_USERNAME:$_OLVM_PASSWORD \
--data '
<action>
<storage_domain>
<name>'$DST_SD'</name>
</storage_domain>
<cluster>
<name>'$CLUSTER'</name>
</cluster>
<clone>true</clone>
<vm>
<name>'$VM_NAME'</name>
</vm>
</action>
'
https://$_OLVM_HOSTNAME/ovirt-engine/api/storagedomains/$SRC_SD_ID/vms/$SD_VM_ID/import
Response is:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
When i use the same syntax to just get a list of importable VMs there is no error and the Response is a xml entity.
Any idea?
3 years, 3 months
