Upgrade from oVirt 4.5.4 to oVirt 4.5.5 - nothing provides selinux-policy >= 38.1.27-1.el9
by Devin A. Bougie
Hi, All. We're having trouble updating our 4.5.4 cluster to 4.5.5. We're running a self-hosted engine on fully updated AlmaLinux 9 hosts, and get the following errors when trying to upgrade to 4.5.5.
Any suggestions would be greatly appreciated.
Many thanks,
Devin
------
[root@lnxvirt01 ~]# dnf clean all
157 files removed
[root@lnxvirt01 ~]# dnf update
CLASSE Packages - x86_64 36 MB/s | 569 kB 00:00
CentOS-9-stream - Ceph Pacific 839 kB/s | 557 kB 00:00
CentOS-9-stream - Gluster 10 240 kB/s | 56 kB 00:00
CentOS-9 - RabbitMQ 38 354 kB/s | 104 kB 00:00
CentOS Stream 9 - NFV OpenvSwitch 923 kB/s | 154 kB 00:00
CentOS-9 - OpenStack yoga 5.7 MB/s | 3.0 MB 00:00
CentOS Stream 9 - OpsTools - collectd 228 kB/s | 51 kB 00:00
CentOS Stream 9 - oVirt 4.5 6.2 MB/s | 1.0 MB 00:00
oVirt upstream for CentOS Stream 9 - oVirt 4.5 1.0 kB/s | 7.5 kB 00:07
AlmaLinux 9 - AppStream 87 MB/s | 7.7 MB 00:00
AlmaLinux 9 - BaseOS 72 MB/s | 2.4 MB 00:00
AlmaLinux 9 - BaseOS - Debug 9.9 MB/s | 1.9 MB 00:00
AlmaLinux 9 - CRB 67 MB/s | 2.3 MB 00:00
AlmaLinux 9 - Extras 1.5 MB/s | 17 kB 00:00
AlmaLinux 9 - HighAvailability 29 MB/s | 434 kB 00:00
AlmaLinux 9 - NFV 56 MB/s | 1.0 MB 00:00
AlmaLinux 9 - Plus 2.5 MB/s | 22 kB 00:00
AlmaLinux 9 - ResilientStorage 30 MB/s | 446 kB 00:00
AlmaLinux 9 - RT 53 MB/s | 1.0 MB 00:00
AlmaLinux 9 - SAP 874 kB/s | 9.7 kB 00:00
AlmaLinux 9 - SAPHANA 1.3 MB/s | 13 kB 00:00
Error:
Problem 1: cannot install the best update candidate for package ovirt-vmconsole-1.0.9-1.el9.noarch
- nothing provides selinux-policy >= 38.1.27-1.el9 needed by ovirt-vmconsole-1.0.9-3.el9.noarch from centos-ovirt45
- nothing provides selinux-policy-base >= 38.1.27-1.el9 needed by ovirt-vmconsole-1.0.9-3.el9.noarch from centos-ovirt45
Problem 2: package ovirt-vmconsole-host-1.0.9-3.el9.noarch from centos-ovirt45 requires ovirt-vmconsole = 1.0.9-3.el9, but none of the providers can be installed
- cannot install the best update candidate for package ovirt-vmconsole-host-1.0.9-1.el9.noarch
- nothing provides selinux-policy >= 38.1.27-1.el9 needed by ovirt-vmconsole-1.0.9-3.el9.noarch from centos-ovirt45
- nothing provides selinux-policy-base >= 38.1.27-1.el9 needed by ovirt-vmconsole-1.0.9-3.el9.noarch from centos-ovirt45
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
------
1 year, 2 months
Major screwup and now I can't bring anything up
by John Florian
I have a small home oVirt 4.5 deployment that was struggling a bit and I think I've only made things worse. I was seeing some SSL errors in various places but couldn't find any evidence of an expired cert though maybe I overlooked something. At present, it looks like the most immediate problem is that the engine.log is showing SyncNetworkProviderCommand fails saying EngineException: (Failed with error Unsupported or unrecognized SSL message and code 5050). For now, I'm only concerning myself to one Host that had been running VMs until I tried restarting everything from a power off. I take it that the sync failure prevents this Host from becoming active.
I had successfully been using this setup for many years. I do have my own web cert on the engine signed by my CA. While I was getting this same "code 5050" error before with things like ovirt-imageio (what prompted my initial digging), now I'm afraid I've only made things more complex. See, I was running FreeIPA on a pair of VMs. In the past, this pair of VMs would auto-start once the oVirt Engine and Hosts were going and I had no issue. But now I wonder to what extent OSCP being unreachable might affect the SSL errors.
What's the best/easiest/safest way out of this mess? Should I just wipe ovirt-engine of all the non-rpm provided files in /etc/pki/ovirt-engine/ and redo the engine-setup? I'm afraid of making things worse before I begin attempting that.
1 year, 2 months
Re: [ovirt-devel] Foreman needs a release of ovirt-engine-sdk-ruby
by Guillaume Pavese
We were just starting to depend on this workflow...
On Fri, Jan 26, 2024 at 2:02 PM Ewoud Kohl van Wijngaarden <
ewoud+ovirt(a)kohlvanwijngaarden.nl> wrote:
> Hello everyone,
>
> Foreman is a bit late in updating Ruby to a newer version. Looking ahead
> we're aiming at Ruby 3.1+ but ovirt-engine-sdk-ruby doesn't compile on
> it.
>
> https://github.com/oVirt/ovirt-engine-sdk-ruby/pull/3 was merged in
> September 2022 and a request to release it was opened a year ago:
> https://github.com/oVirt/ovirt-engine-sdk-ruby/issues/4
>
> The Foreman community is currently discussing dropping oVirt support:
> https://community.theforeman.org/t/proposal-to-drop-support-for-ovirt/36324
>
> Is there anyone who can still perform this release, or should we proceed
> with removal?
>
> Regards,
> Ewoud Kohl van Wijngaarden
> _______________________________________________
> Devel mailing list -- devel(a)ovirt.org
> To unsubscribe send an email to devel-leave(a)ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/ESA4LFSQ5JP...
>
--
Ce message et toutes les pièces jointes (ci-après le “message”) sont
établis à l’intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur, merci de le détruire et d’en avertir
immédiatement l’expéditeur. Toute utilisation de ce message non conforme a
sa destination, toute diffusion ou toute publication, totale ou partielle,
est interdite, sauf autorisation expresse. L’internet ne permettant pas
d’assurer l’intégrité de ce message . Interactiv-group (et ses filiales)
décline(nt) toute responsabilité au titre de ce message, dans l’hypothèse
ou il aurait été modifié. IT, ES, UK.
<https://interactiv-group.com/disclaimer.html>
1 year, 2 months
Cannot remove Snapshot. The VM is during a backup operation.
by and＠missme.ro
Hello!
Running ovirt Version 4.5.5-1.el8
I had an issue with the iscsi server during the backup and I have two VMs that cannot be backed up anymore by Veeam.
In the ovirt event log i have the following errors:
Snapshot 'Auto-generated for Backup VM' creation for VM 'dns-a' has been completed.
VDSM ovirt1-02 command StartNbdServerVDS failed: Bitmap does not exist: "{'reason': 'Bitmap does not exist in /rhev/data-center/mnt/blockSD/b2fa3469-a380-4180-a89a-43d65085d1b9/images/6a4de98a-b544-4df8-beb1-e560fd61c0e6/cdb26b8b-c447-48de-affa-d7f778aebac7', 'bitmap': '12d2fb20-74da-4e63-b240-f1a42210760c'}"
Transfer was stopped by system. Reason: failed to create a signed image ticket.
Image Download with disk dns-a_Disk1 was initiated by veeam@internal-authz
Image Download with disk dns-a_Disk1 was cancelled.
The error on the Veeam backup proxy:
dns-a: Unable to create image transfer: Reason: 'Operation Failed', Detail: '[]'
When trying to delete the snapshot from the administration interface I receive the following error in the web interface (and nothing gets logged in the event log)
Cannot remove Snapshot. The VM is during a backup operation.
How should I go about fixing this issue?
1 year, 2 months
HE Storage Domain Path Config Setting - Where?
by Matthew J Black
Hey Guys,
Quick Q: In which file (on a Hosted-Engine or Hosted-Engine Host) is the configuration for the path to a Storage Domain kept - in particular, the "hosted-engine" Storage Domain?
I've got something "funny" going on: the logs (as far as I can see) are reporting that 2 of my 3 HE-Hosts can't connect to the HE Storage Domain (but don't explain why), and the OVE GUI is reporting an "odd" (ie incorrect; non-existent) path to the HE Storage Domain.
Via CLI I have confirmed that all three HE Hosts *can* reach (ie have the correct "findmnt" mappings) to the HE Storage Domain's actual file location, and I can't locate the "ghost" HE Storage Domain path or its config setting anywhere - so I don't even know if that's the issue, but I'd like to eliminate it from my trouble-shooting process.
Anyway, if someone could get back to me, please, I'd really appreciate it.
Cheers
Dulux-Oz
1 year, 2 months
Geo-replication configuration problem
by Ismet Sonmez
Hello,
Newly installed node version 4.5.5
2 clusters and three nodes each
every time I try to replicate the geo in cluster 1 it gives an error
3 errors like this:
VDSM node4 command UpdateGlusterGeoRepKeysVDS failed: Internal JSON-RPC error:
{'cause': 'Attempting to call function: GlusterVolume.geoRepKeysUpdate bound method of object <vdsm.gluster.apiwrapper.GlusterVolume at address 0x7f1524534f28>> with arguments: (\'root\',
\'command="/usr/libexec/glusterfs/gsyncd" ssh-rsa AAAAB3N****
\'command="tar ${SSH_ORIGINAL_COMMAND#* }" ssh-rsa AAAA****
\'command="/usr/libexec/glusterfs/gsyncd" ssh-rsa AAAAB3****
\'command="tar ${SSH_ORIGINAL_COMMAND#* }" ssh-rsa AAAA***
\'command="/usr/libexec/glusterfs/gsyncd" ssh-rsa AAAA*******
\'command="tar ${SSH_ORIGINAL_COMMAND#* }" ssh-rsa AAAA****
]) error: bytes-like object required, not \'str\' }
I understand that when creating the rsa key, or sending it to the node.
How can I solve it?
1 year, 2 months
Forbid hosts/nodes from assembling a soft-raid that was created inside a VM
by Vladislav Solovei
When I create a soft-raid (md-raid) inside a virtual machine (yes, sometimes it's necessary to do this to get a disk inside the VM with a capacity of more than 8TB), the host/node detects this array and assembles it automatically. I tried adding the parameter 'raid=noautodetect' to the kernel boot parameters, but it doesn't help. Is it possible to prevent hosts from doing this? :)
1 year, 2 months
Low confirmed free space on gluster volume
by Jonas
Hello list
I am regularly getting the following error on a Gluster volume hosted on
a three node hyperconverged oVirt-Cluster:
Warning! Low confirmed free space on gluster volume tier1-owncloud-users-01
This volume is configured with 3TiB (2.5TIB used) and is used as the
name implies to store data of an ownCloud instance. It is not used as a
storage domain in oVirt. I don't really want to resize the volume just
to make the warning go away. While clicking through the oVirt web
interface i found the configuration "Warning Low Confirmed Space
Indicator" in the advanced parameters of the storage domains but did not
find any similar setting in the configuration of the gluster volumes. Do
you know of way to configure this setting for a gluster volume which is
not used as a storage domain?
Thank you
Jonas
1 year, 2 months
