- Users - oVirt List Archives

rhv 4.3.11 but not ovirt 4.3.11
by Gianluca Cecchi 12 Nov '20

12 Nov '20

Hello, I see that a 4.3.11 version is available for downstream RHV but not for upstream oVirt. Will it be released for oVirt too? Are there only security fixes inside or also bug fixes (like the few lines one related to export as OVA)? Thanks, Gianluca

3 3

oVrit 4.3.10 on CentOS 7.9
by Christoph Timm 12 Nov '20

12 Nov '20

Hi list, I want to update my oVirt installation to 4.3.10 on the weekend to get ready to move to 4.4 by end of December. Would it be OK to update to oVirt 4.3.10 on CentOS 7.9 which was release today? Best regards Christoph

1 0

Engine update error from 4.4.2 to 4.4.3
by Gianluca Cecchi 12 Nov '20

12 Nov '20

Hello, is this still the correct command during updates through minor releases in 4.4.x? yum update ovirt\*setup\* Because my standalone external engine is now at level ovirt-engine-4.4.2.6-1.el8.noarch with [root@ovmgr1 ~]# yum repolist repo id repo name AppStream CentOS-8 - AppStream BaseOS CentOS-8 - Base PowerTools CentOS-8 - PowerTools extras CentOS-8 - Extras ovirt-4.4 Latest oVirt 4.4 Release ovirt-4.4-advanced-virtualization Advanced Virtualization packages for x86_64 ovirt-4.4-centos-gluster7 CentOS-8 - Gluster 7 ovirt-4.4-centos-opstools CentOS-8 - OpsTools - collectd ovirt-4.4-centos-ovirt44 CentOS-8 - oVirt 4.4 ovirt-4.4-copr:copr.fedorainfracloud.org:mdbarroso:ovsdbapp Copr repo for ovsdbapp owned by mdbarroso ovirt-4.4-copr:copr.fedorainfracloud.org:networkmanager:NetworkManager-1.22 Copr repo for NetworkManager-1.22 owned by networkmanager ovirt-4.4-copr:copr.fedorainfracloud.org:nmstate:nmstate-0.2 Copr repo for nmstate-stable owned by nmstate ovirt-4.4-copr:copr.fedorainfracloud.org:sac:gluster-ansible Copr repo for gluster-ansible owned by sac ovirt-4.4-copr:copr.fedorainfracloud.org:sbonazzo:EL8_collection Copr repo for EL8_collection owned by sbonazzo ovirt-4.4-epel Extra Packages for Enterprise Linux 8 - x86_64 ovirt-4.4-virtio-win-latest virtio-win builds roughly matching what will be shipped in upcoming RHEL [root@ovmgr1 ~]# yum repolist repo id repo name AppStream CentOS-8 - AppStream BaseOS CentOS-8 - Base PowerTools CentOS-8 - PowerTools extras CentOS-8 - Extras ovirt-4.4 Latest oVirt 4.4 Release ovirt-4.4-advanced-virtualization Advanced Virtualization packages for x86_64 ovirt-4.4-centos-gluster7 CentOS-8 - Gluster 7 ovirt-4.4-centos-opstools CentOS-8 - OpsTools - collectd ovirt-4.4-centos-ovirt44 CentOS-8 - oVirt 4.4 ovirt-4.4-copr:copr.fedorainfracloud.org:mdbarroso:ovsdbapp Copr repo for ovsdbapp owned by mdbarroso ovirt-4.4-copr:copr.fedorainfracloud.org:networkmanager:NetworkManager-1.22 Copr repo for NetworkManager-1.22 owned by networkmanager ovirt-4.4-copr:copr.fedorainfracloud.org:nmstate:nmstate-0.2 Copr repo for nmstate-stable owned by nmstate ovirt-4.4-copr:copr.fedorainfracloud.org:sac:gluster-ansible Copr repo for gluster-ansible owned by sac ovirt-4.4-copr:copr.fedorainfracloud.org:sbonazzo:EL8_collection Copr repo for EL8_collection owned by sbonazzo ovirt-4.4-epel Extra Packages for Enterprise Linux 8 - x86_64 ovirt-4.4-virtio-win-latest virtio-win builds roughly matching what will be shipped in upcoming RHEL [root@ovmgr1 ~]# - /etc/yum.repos.d/ovirt-4.4.repo [ovirt-4.4] name=Latest oVirt 4.4 Release #baseurl=https://resources.ovirt.org/pub/ovirt-4.4/rpm/el$releasever/ mirrorlist= https://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-4.4-el$releasever enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-ovirt-4.4 But if I run the command above I get: [root@ovmgr1 ~]# yum update ovirt\*setup\* Last metadata expiration check: 0:39:59 ago on Wed 11 Nov 2020 09:02:05 AM CET. Error: Problem 1: package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.11-1.el8.noarch requires ovirt-engine >= 4.4.0, but none of the providers can be installed - package ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-roles provided by ovirt-ansible-roles-1.2.3-1.el8.noarch - cannot install the best update candidate for package ovirt-engine-setup-plugin-ovirt-engine-4.4.2.6-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-cluster-upgrade-1.2.3-1.el8.noarch - package ovirt-engine-4.4.0.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.2-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.11-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.9-1.el8.noarch is filtered out by exclude filtering Problem 2: package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.11-1.el8.noarch requires ovirt-engine >= 4.4.0, but none of the providers can be installed - package ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-engine-setup-4.4.3.11-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine = 4.4.3.11-1.el8, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-roles provided by ovirt-ansible-roles-1.2.3-1.el8.noarch - cannot install the best update candidate for package ovirt-engine-setup-4.4.2.6-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-disaster-recovery-1.3.0-1.el8.noarch - package ovirt-engine-4.4.0.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.2-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.11-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.9-1.el8.noarch is filtered out by exclude filtering Problem 3: package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.11-1.el8.noarch requires ovirt-engine >= 4.4.0, but none of the providers can be installed - package ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-engine-setup-plugin-cinderlib-4.4.3.11-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine = 4.4.3.11-1.el8, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-roles provided by ovirt-ansible-roles-1.2.3-1.el8.noarch - cannot install the best update candidate for package ovirt-engine-setup-plugin-cinderlib-4.4.2.6-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-engine-setup-1.2.4-1.el8.noarch - package ovirt-engine-4.4.0.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.2-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.11-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.9-1.el8.noarch is filtered out by exclude filtering Problem 4: package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.11-1.el8.noarch requires ovirt-engine >= 4.4.0, but none of the providers can be installed - package ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-engine-setup-plugin-imageio-4.4.3.11-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine = 4.4.3.11-1.el8, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-roles provided by ovirt-ansible-roles-1.2.3-1.el8.noarch - cannot install the best update candidate for package ovirt-engine-setup-plugin-imageio-4.4.2.6-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-hosted-engine-setup-1.1.8-1.el8.noarch - package ovirt-engine-4.4.0.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.2-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.11-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.9-1.el8.noarch is filtered out by exclude filtering Problem 5: package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.11-1.el8.noarch requires ovirt-engine >= 4.4.0, but none of the providers can be installed - package ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-engine-setup-plugin-vmconsole-proxy-helper-4.4.3.11-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine = 4.4.3.11-1.el8, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-roles provided by ovirt-ansible-roles-1.2.3-1.el8.noarch - cannot install the best update candidate for package ovirt-engine-setup-plugin-vmconsole-proxy-helper-4.4.2.6-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-image-template-1.2.2-1.el8.noarch - package ovirt-engine-4.4.0.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.2-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.11-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.9-1.el8.noarch is filtered out by exclude filtering Problem 6: problem with installed package ovirt-engine-4.4.2.6-1.el8.noarch - package ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-roles provided by ovirt-ansible-roles-1.2.3-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-infra-1.2.2-1.el8.noarch Problem 7: problem with installed package ovirt-engine-ui-extensions-1.2.3-1.el8.noarch - package ovirt-engine-ui-extensions-1.2.3-1.el8.noarch requires ovirt-ansible-cluster-upgrade >= 1.1.12, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-cluster-upgrade provided by ovirt-ansible-cluster-upgrade-1.2.3-1.el8.noarch - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-cluster-upgrade provided by ovirt-ansible-cluster-upgrade-1.2.2-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-manageiq-1.2.1-1.el8.noarch Problem 8: problem with installed package ovirt-engine-setup-plugin-ovirt-engine-4.4.2.6-1.el8.noarch - package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.11-1.el8.noarch requires ovirt-engine >= 4.4.0, but none of the providers can be installed - package ovirt-engine-setup-plugin-ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine-common = 4.4.2.6-1.el8, but none of the providers can be installed - package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.10-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine-common = 4.4.3.10-1.el8, but none of the providers can be installed - package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.3-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine-common = 4.4.3.3-1.el8, but none of the providers can be installed - package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.4-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine-common = 4.4.3.4-1.el8, but none of the providers can be installed - package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.5-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine-common = 4.4.3.5-1.el8, but none of the providers can be installed - package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.6-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine-common = 4.4.3.6-1.el8, but none of the providers can be installed - package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.7-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine-common = 4.4.3.7-1.el8, but none of the providers can be installed - package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.8-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine-common = 4.4.3.8-1.el8, but none of the providers can be installed - package ovirt-engine-setup-plugin-ovirt-engine-4.4.3.9-1.el8.noarch requires ovirt-engine-setup-plugin-ovirt-engine-common = 4.4.3.9-1.el8, but none of the providers can be installed - package ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - cannot install both ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.11-1.el8.noarch and ovirt-engine-setup-plugin-ovirt-engine-common-4.4.2.6-1.el8.noarch - cannot install both ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.11-1.el8.noarch and ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.10-1.el8.noarch - cannot install both ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.3-1.el8.noarch and ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.11-1.el8.noarch - cannot install both ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.4-1.el8.noarch and ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.11-1.el8.noarch - cannot install both ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.5-1.el8.noarch and ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.11-1.el8.noarch - cannot install both ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.6-1.el8.noarch and ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.11-1.el8.noarch - cannot install both ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.7-1.el8.noarch and ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.11-1.el8.noarch - cannot install both ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.8-1.el8.noarch and ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.11-1.el8.noarch - cannot install both ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.9-1.el8.noarch and ovirt-engine-setup-plugin-ovirt-engine-common-4.4.3.11-1.el8.noarch - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-roles provided by ovirt-ansible-roles-1.2.3-1.el8.noarch - cannot install the best update candidate for package ovirt-engine-setup-plugin-ovirt-engine-common-4.4.2.6-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-repositories-1.2.5-1.el8.noarch - package ovirt-engine-4.4.0.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.1-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.2-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.1.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.10-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.11-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.3-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.8-1.el8.noarch is filtered out by exclude filtering - package ovirt-engine-4.4.3.9-1.el8.noarch is filtered out by exclude filtering Problem 9: problem with installed package ovirt-engine-webadmin-portal-4.4.2.6-1.el8.noarch - package ovirt-engine-webadmin-portal-4.4.2.6-1.el8.noarch requires ovirt-engine = 4.4.2.6-1.el8, but none of the providers can be installed - package ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-roles provided by ovirt-ansible-roles-1.2.3-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-roles-1.2.3-1.el8.noarch Problem 10: problem with installed package ovirt-engine-tools-4.4.2.6-1.el8.noarch - package ovirt-engine-tools-4.4.2.6-1.el8.noarch requires ovirt-engine = 4.4.2.6-1.el8, but none of the providers can be installed - package ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-roles provided by ovirt-ansible-roles-1.2.3-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-shutdown-env-1.1.0-1.el8.noarch Problem 11: problem with installed package ovirt-engine-restapi-4.4.2.6-1.el8.noarch - package ovirt-engine-restapi-4.4.2.6-1.el8.noarch requires ovirt-engine = 4.4.2.6-1.el8, but none of the providers can be installed - package ovirt-engine-4.4.2.6-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-roles provided by ovirt-ansible-roles-1.2.3-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-vm-infra-1.2.3-1.el8.noarch (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) [root@ovmgr1 ~]# Thanks, Gianluca

4 12

[ANN] oVirt 4.4.4 First Release Candidate is now available for testing
by Lev Veyde 12 Nov '20

12 Nov '20

oVirt 4.4.4 First Release Candidate is now available for testing The oVirt Project is pleased to announce the availability of oVirt 4.4.4 First Release Candidate for testing, as of November 12th, 2020. This update is the fourth in a series of stabilization updates to the 4.4 series. How to prevent hosts entering emergency mode after upgrade from oVirt 4.4.1 Note: Upgrading from 4.4.2 GA or later should not require re-doing these steps, if already performed while upgrading from 4.4.1 to 4.4.2 GA. These are only required to be done once. Due to Bug 1837864 <https://bugzilla.redhat.com/show_bug.cgi?id=1837864> - Host enter emergency mode after upgrading to latest build If you have your root file system on a multipath device on your hosts you should be aware that after upgrading from 4.4.1 to 4.4.4 you may get your host entering emergency mode. In order to prevent this be sure to upgrade oVirt Engine first, then on your hosts: 1. Remove the current lvm filter while still on 4.4.1, or in emergency mode (if rebooted). 2. Reboot. 3. Upgrade to 4.4.4 (redeploy in case of already being on 4.4.4). 4. Run vdsm-tool config-lvm-filter to confirm there is a new filter in place. 5. Only if not using oVirt Node: - run "dracut --force --add multipath” to rebuild initramfs with the correct filter configuration 6. Reboot. Documentation - If you want to try oVirt as quickly as possible, follow the instructions on the Download <https://ovirt.org/download/> page. - For complete installation, administration, and usage instructions, see the oVirt Documentation <https://ovirt.org/documentation/>. - For upgrading from a previous version, see the oVirt Upgrade Guide <https://ovirt.org/documentation/upgrade_guide/>. - For a general overview of oVirt, see About oVirt <https://ovirt.org/community/about.html>. Important notes before you try it Please note this is a pre-release build. The oVirt Project makes no guarantees as to its suitability or usefulness. This pre-release must not be used in production. Installation instructions For installation instructions and additional information please refer to: https://ovirt.org/documentation/ This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 8.2 or newer * CentOS Linux (or similar) 8.2 or newer This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 8.2 or newer * CentOS Linux (or similar) 8.2 or newer * oVirt Node 4.4 based on CentOS Linux 8.2 (available for x86_64 only) See the release notes [1] for installation instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available for CentOS Linux 8 - oVirt Node NG is already available for CentOS Linux 8 Additional Resources: * Read more about the oVirt 4.4.4 release highlights: http://www.ovirt.org/release/4.4.4/ * Get more oVirt project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.4.4/ [2] http://resources.ovirt.org/pub/ovirt-4.4-pre/iso/ -- Lev Veyde Senior Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

Re: sshd_config AuthorizedKeysFile
by Yedidyah Bar David 12 Nov '20

12 Nov '20

On Thu, Nov 12, 2020 at 11:44 AM Angus Clarke <angus(a)charworth.com> wrote: > > Righto > > For sure the ssh-copy-id is not happy either - in 20something years I've never used this before, I've always just manipulated files. > > I did start raising a bug ... missed some field, had to click back and lost all the previously inputted information - I forgot about this ... > > > Overall, tracing the issue is the thing that took too long, there was some message in the hosted-engine-deployment logs (one of the logs from the engine VM itself) which said something like "check you ssh host keys" (sorry, I've lost that information now) - it would have been useful to see it say something about editing the file /root/.ssh/authorized_keys on the KVM host prior to this. > > I didn't spend too long debugging the kvm-add-host-to-cluster issue - I didn't find too much in the way of obvious errors in logs on the 2nd KVM host for that either; rather - having just realised and resolved the hosted-engine deployment issue - I guessed the same response to the add-kvm-host to cluster issue which resolved that too. > > So maybe a bit of extra logging on the matter would be a great way forwards, or with such few use cases (am I really the only one to manipulate AuthorizedKeysFile? - wow!) then no action at all might be appropriate. If you still have the logs, please file a bug and attach them, and perhaps point out what you'd expect there that is missing (or just let us look at them, and if we decide that the information there is enough, we'll ask you, after finding the most relevant line). Generally speaking, and assuming your only problem was in "Add host to engine" flow (specifically also during hosted-engine deploy), you should find these logs in the _engine_ machine, in /var/log/ovirt-engine (and subdirs). The deploy process also tries to copy these logs to the _host_, under /var/log/ovirt-hosted-engine-setup, and this part was enhanced somewhat in 4.4.3 (see https://bugzilla.redhat.com/1844965 ). Best regards, > > Cheers > Angus > > # ls .ssh > ls: cannot access .ssh: No such file or directory > # ssh-copy-id server2 > > /usr/bin/ssh-copy-id: ERROR: failed to open ID file '/root/.pub': No such file or directory > (to install the contents of '/root/.pub' anyway, look at the -f option) > > ________________________________ > From: Martin Perina <mperina(a)redhat.com> > Sent: 12 November 2020 09:43 > To: Angus Clarke <angus(a)charworth.com> > Cc: users(a)ovirt.org <users(a)ovirt.org>; Dana Elfassy <delfassy(a)redhat.com>; Yedidyah Bar David <didi(a)redhat.com> > Subject: Re: [ovirt-users] sshd_config AuthorizedKeysFile > > Hi, > > could you please try if ssh-copy-id works with your non-standard sshd configuration? Because last time I've checked I haven't noticed that behavior and keys were always added to $HOME/.ssh/authorized_keys > > So feel free to create a bug for that, but up until now you are the first user using this non-standard configuration ... > > Regards, > Martin > > On Thu, Nov 12, 2020 at 9:00 AM Angus Clarke <angus(a)charworth.com> wrote: > > Hello > > Sharing for anyone who needs it, this was carried out on OL7, they use ovirt 4.3 > > In short: both the hosted-engine deployment routine and the host add to cluster routine distribute public ssh keys to /root/.ssh/authorized_keys regardless of the AuthorizedKeysFile setting in /etc/ssh/sshd_config. Both routines fail if AuthorizedKeysfile is not default. > > > The hosted-engine setup assumes AuthorizedKeysFile to be default (~/.ssh/authorized_keys) and creates a public key there, instead of following the sshd_config directive. The setup fails on the back of this. > > Once I commented this out of sshd_config file (assumes default) and restarted sshd on the KVM host that was running the hosted-engine deployment, the hosted-engine setup completed successfully. > > > Similarly, I could not deploy a second KVM host to the compute cluster until I had altered this setting on that 2nd KVM host - presumably that process has some similar routine that unwittingly writes keys to ~/.ssh/authorized_keys. > > HTH > Angus > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-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/users@ovirt.org/message/UMJ4Y622RALUU… > > > > -- > Martin Perina > Manager, Software Engineering > Red Hat Czech s.r.o. -- Didi

1 0

Re: sshd_config AuthorizedKeysFile
by Martin Perina 12 Nov '20

12 Nov '20

Hi, could you please try if ssh-copy-id works with your non-standard sshd configuration? Because last time I've checked I haven't noticed that behavior and keys were always added to $HOME/.ssh/authorized_keys So feel free to create a bug for that, but up until now you are the first user using this non-standard configuration ... Regards, Martin On Thu, Nov 12, 2020 at 9:00 AM Angus Clarke <angus(a)charworth.com> wrote: > Hello > > Sharing for anyone who needs it, this was carried out on OL7, they use > ovirt 4.3 > > In short: both the hosted-engine deployment routine and the host add to > cluster routine distribute public ssh keys to /root/.ssh/authorized_keys > regardless of the AuthorizedKeysFile setting in /etc/ssh/sshd_config. Both > routines fail if AuthorizedKeysfile is not default. > > > The hosted-engine setup assumes AuthorizedKeysFile to be default > (~/.ssh/authorized_keys) and creates a public key there, instead of > following the sshd_config directive. The setup fails on the back of this. > > Once I commented this out of sshd_config file (assumes default) and > restarted sshd on the KVM host that was running the hosted-engine > deployment, the hosted-engine setup completed successfully. > > > Similarly, I could not deploy a second KVM host to the compute cluster > until I had altered this setting on that 2nd KVM host - presumably that > process has some similar routine that unwittingly writes keys to > ~/.ssh/authorized_keys. > > HTH > Angus > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-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/users@ovirt.org/message/UMJ4Y622RALUU… > -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

2 1

Re: Cluster compatibility version 4.5 on oVirt 4.4
by Christopher Law 12 Nov '20

12 Nov '20

I should have pointed out that in my case the hosted engine failed to install. After the Local VM came up the host was marked as non-operational because the cluster (which I had given a custom name via ansible input) was set to compatibility 4.5 and was not changeable. No idea why the cluster was created at 4.5 if that is not supposed to be available yet or marked for some sort of future release. This caused the host to be non-operational with a warning that the “host” needed upgrading, so perhaps it’s a slightly different issue to that faced below. If you have faced this issue though I would appreciated some advice on how to resolve it. I noticed the default cluster was marked as 4.4. My plan is therefore to re-install the hosted engine and use the “Default” datacentre and cluster names and changes these later. From: Christopher Law <chris(a)chrislaw.me> Sent: 12 November 2020 09:21 To: Ritesh Chikatwar <rchikatw(a)redhat.com>; shadow emy <shadow.emy1(a)gmail.com> Cc: users <users(a)ovirt.org> Subject: [ovirt-users] Re: Cluster compatibility version 4.5 on oVirt 4.4 I’ve also faced this issue, which is surprising since I used an ovirt node download for 4.4. How did you resolve it? How can you upgrade to CentOS 8.3 or downgrade the cluster? Thanks, Chris. From: Ritesh Chikatwar <rchikatw(a)redhat.com<mailto:rchikatw@redhat.com>> Sent: 12 November 2020 05:10 To: shadow emy <shadow.emy1(a)gmail.com<mailto:shadow.emy1@gmail.com>> Cc: users <users(a)ovirt.org<mailto:users@ovirt.org>> Subject: [ovirt-users] Re: Cluster compatibility version 4.5 on oVirt 4.4 Hello, To upgrade to cluster 4.5 you need a 8.3 host. I guess still CentOS 8.3 is not available. I am not sure on CentOS 8.3 availability. If it's available please make sure your host is upgraded to 8.3 . On Thu, Nov 12, 2020, 5:38 AM shadow emy <shadow.emy1(a)gmail.com<mailto:shadow.emy1@gmail.com>> wrote: Just to confirm i face similar problem. Yes i saw that warning too : "Upgrade Cluster Compatibility Level" to upgrade the Cluster to version 4.5. Though when i try to do that there are a lot of errors. In GUI : Error while executing action: Cannot change Cluster Compatibility Version to higher version when there are active Hosts with lower version. -Please move Host host1, host2, host3 with lower version to maintenance first. In engine.log : WARN [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-163) [2c681b74-8666-4f2f-b2e0-6b20e98f417e] Validation of action 'UpdateCluster' failed for user admin@internal-authz. Reasons: VAR__TYPE__CLUSTER,VAR__ACTION__UPDATE,$host host1, host2, host3,CLUSTER_CANNOT_UPDATE_COMPATIBILITY_VERSION_WITH_LOWER_HOSTS I did not find any documentation for 4.5 cluster compatibility, so i like as well to understand why is that option present there. It will be used when ovirt 4.5.x will be released ? _______________________________________________ Users mailing list -- users(a)ovirt.org<mailto:users@ovirt.org> To unsubscribe send an email to users-leave(a)ovirt.org<mailto:users-leave@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/users@ovirt.org/message/3UGQ6HPT2HTEG…

1 0

Cluster compatibility version 4.5 on oVirt 4.4
by tferic＠swissonline.ch 12 Nov '20

12 Nov '20

Hi Today, I upgraded oVirt from 4.3 to 4.4.3. After the upgrade, I upgraded the compatibility from 4.3 to 4.4. I noticed that the cluster config is offering me another upgrade of the compatibility to version 4.5. Up until now, I was under the impression that the compatibility version must match the oVirt version. I am now reluctant to upgrade the compatibility to 4.5, while my oVirt version is still at 4.4 (there is no oVirt 4.5 at this time). Is it safe to upgrade the compatibility in any case, or are there certain circumstances, where we should refrain from upgrading it? I wasn't able to find anything in the documentation. Kind regards Toni Feric

4 3

Re: sshd_config AuthorizedKeysFile
by Yedidyah Bar David 12 Nov '20

12 Nov '20

On Thu, Nov 12, 2020 at 10:01 AM Angus Clarke <angus(a)charworth.com> wrote: > > Hello > > Sharing for anyone who needs it, this was carried out on OL7, they use ovirt 4.3 > > In short: both the hosted-engine deployment routine and the host add to cluster routine distribute public ssh keys to /root/.ssh/authorized_keys regardless of the AuthorizedKeysFile setting in /etc/ssh/sshd_config. Both routines fail if AuthorizedKeysfile is not default. > > > The hosted-engine setup assumes AuthorizedKeysFile to be default (~/.ssh/authorized_keys) and creates a public key there, instead of following the sshd_config directive. The setup fails on the back of this. > > Once I commented this out of sshd_config file (assumes default) and restarted sshd on the KVM host that was running the hosted-engine deployment, the hosted-engine setup completed successfully. > > > Similarly, I could not deploy a second KVM host to the compute cluster until I had altered this setting on that 2nd KVM host - presumably that process has some similar routine that unwittingly writes keys to ~/.ssh/authorized_keys. Thanks for the report. Would you like to open one or two bugs about this? I think it's just bug, though - from searching relevant source - in the code adding a host to the engine. This code is also used during hosted-engine deploy. We also have code there to add lines to this file on the appliance (engine vm image), but I do not believe users will work so hard as to update the image before deploy. So one bug is probably enough. To make sure, please include there all relevant details about how "they" (your customer?) configure their machines - e.g. is it only during their installation (image/PXE/etc.) or also routinely (puppet etc.) I admit I am not sure what the expected behavior should be, though: An admin can run sshd with a custom file. So should we also check that? Perhaps it's enough if we allow the admin to set a custom location also for oVirt, instead of trying to guess. And make sure that the failure error message is clear and unique enough so that people searching the net for it find your bug, so can find how to configure it :-) Best regards, -- Didi

1 0

sshd_config AuthorizedKeysFile
by Angus Clarke 12 Nov '20

12 Nov '20

Hello Sharing for anyone who needs it, this was carried out on OL7, they use ovirt 4.3 In short: both the hosted-engine deployment routine and the host add to cluster routine distribute public ssh keys to /root/.ssh/authorized_keys regardless of the AuthorizedKeysFile setting in /etc/ssh/sshd_config. Both routines fail if AuthorizedKeysfile is not default. The hosted-engine setup assumes AuthorizedKeysFile to be default (~/.ssh/authorized_keys) and creates a public key there, instead of following the sshd_config directive. The setup fails on the back of this. Once I commented this out of sshd_config file (assumes default) and restarted sshd on the KVM host that was running the hosted-engine deployment, the hosted-engine setup completed successfully. Similarly, I could not deploy a second KVM host to the compute cluster until I had altered this setting on that 2nd KVM host - presumably that process has some similar routine that unwittingly writes keys to ~/.ssh/authorized_keys. HTH Angus

1 0

Upgrade OVIRT from 3.6 to 4.3
by Miguel Angel Costas 12 Nov '20

12 Nov '20

Hi Guys! I need to upgrade from 3.6 to 4.3 and I have a doubt. Do I need to restard VMs for each upgrade (DC Compatibilty 1° 4.0 - 2° 4.1 - 3° 4.2 and 4° 4.3) or can modify the compatibilty from 3.6 to 4.2 and restart the vms in this only step. Best regards

2 1

Adding iscsi issue 4.3
by thilburn＠generalpacific.com 11 Nov '20

11 Nov '20

When connecting an iscsi connection from an array I get the following popup "A database error occurred. Please contact your system administrator." I have checked everything and the only device connected right now is the single host in the datacenter. If I check the box " Approve operation" and click Ok it will error out with "A database error occurred. Please contact your system administrator." This is a new volume and no other machine is connected to this LUN or array. Below is from the vdsm log 2020-11-11 10:42:26,087-0800 INFO (jsonrpc/0) [vdsm.api] START getDeviceList(storageType=3, guids=[u'32021001378a6ddad'], checkStatus=True, options={}) from=::ffff:XXXXXX,46208, flow_id=d09dbfd6-2256-48ad-8597-b6c581def1fd, task_id=67c17255-3ffb-4e8b-b6d3-a4e40836d12c (api:48) 2020-11-11 10:42:26,650-0800 INFO (jsonrpc/0) [storage.LVM] Overriding read_only mode current=True override=False (lvm:398) 2020-11-11 10:42:26,822-0800 INFO (jsonrpc/0) [vdsm.api] FINISH getDeviceList return={'devList': [{'status': 'used', 'vendorID': 'ETIUSA', 'capacity': '3999688294400', 'fwrev': '10E', 'discard_zeroes_data': 0, 'vgUUID': '', 'pvsize': '', 'pathlist': [{'connection': u'10.87.172.100', 'iqn': u'XXXXXX.XXXXXX.XXXXXX:storage3', 'portal': '0', 'port': '3260', 'initiatorname': u'default'}], 'logicalblocksize': '512', 'discard_max_bytes': 0, 'pathstatus': [{'type': 'iSCSI', 'physdev': 'sdc', 'capacity': '3999688294400', 'state': 'active', 'lun': '0'}], 'devtype': 'iSCSI', 'physicalblocksize': '512', 'pvUUID': '', 'serial': 'SETIUSA_UltraStorRS8IP4_2021001378A6DDAD', 'GUID': '32021001378a6ddad', 'productID': 'UltraStorRS8IP4'}]} from=::ffff:XXXXX,46208, flow_id=d09dbfd6-2256-48ad-8597-b6c581def1fd, task_id=67c17255-3ffb-4e8b-b6d3-a4e40836d12c (api:54) 2020-11-11 10:42:26,823-0800 INFO (jsonrpc/0) [jsonrpc.JsonRpcServer] RPC call Host.getDeviceList succeeded in 0.74 seconds (__init__:312) 2020-11-11 10:42:27,158-0800 INFO (jsonrpc/2) [api.host] START getAllVmStats() from=::1,48480 (api:48) 2020-11-11 10:42:27,159-0800 INFO (jsonrpc/2) [api.host] FINISH getAllVmStats return={'status': {'message': 'Done', 'code': 0}, 'statsList': (suppressed)} from=::1,48480 (api:54) 2020-11-11 10:42:27,159-0800 INFO (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC call Host.getAllVmStats succeeded in 0.00 seconds (__init__:312) 2020-11-11 10:42:27,393-0800 INFO (jsonrpc/1) [api.host] START getAllVmStats() from=::ffff:XXXXX,46208 (api:48) 2020-11-11 10:42:27,394-0800 INFO (jsonrpc/1) [api.host] FINISH getAllVmStats return={'status': {'message': 'Done', 'code': 0}, 'statsList': (suppressed)} from=::ffff:XXXXX,46208 (api:54) 2020-11-11 10:42:27,394-0800 INFO (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call Host.getAllVmStats succeeded in 0.00 seconds (__init__:312) 2020-11-11 10:43:12,323-0800 INFO (jsonrpc/6) [vdsm.api] START createVG(vgname=u'35e95355-75db-4640-bf99-e576b9ce39aa', devlist=[u'32021001378a6ddad'], force=True, options=None) from=::ffff:XXXXX,46208, flow_id=2c973734, task_id=91f2ab5b-017a-4c88-aa45-ece3bd920ce0 (api:48) 2020-11-11 10:43:12,348-0800 INFO (jsonrpc/6) [storage.LVM] Overriding read_only mode current=True override=False (lvm:398) 2020-11-11 10:43:12,409-0800 INFO (jsonrpc/4) [api.host] START getAllVmStats() from=::ffff:XXXXXX,46208 (api:48) 2020-11-11 10:43:12,410-0800 INFO (jsonrpc/4) [api.host] FINISH getAllVmStats return={'status': {'message': 'Done', 'code': 0}, 'statsList': (suppressed)} from=::ffff:XXXXXXX,46208 (api:54) 2020-11-11 10:43:12,410-0800 INFO (jsonrpc/4) [jsonrpc.JsonRpcServer] RPC call Host.getAllVmStats succeeded in 0.00 seconds (__init__:312) 2020-11-11 10:43:12,520-0800 ERROR (jsonrpc/6) [storage.LVM] pvcreate failed with rc=5 (lvm:988) 2020-11-11 10:43:12,520-0800 ERROR (jsonrpc/6) [storage.LVM] [], [' Device /dev/mapper/32021001378a6ddad excluded by a filter.'] (lvm:989) 2020-11-11 10:43:12,520-0800 INFO (jsonrpc/6) [vdsm.api] FINISH createVG error=Failed to initialize physical device: ("[u'/dev/mapper/32021001378a6ddad']",) from=::ffff:XXXXXX,46208, flow_id=2c973734, task_id=91f2ab5b-017a-4c88-aa45-ece3bd920ce0 (api:52) 2020-11-11 10:43:12,520-0800 ERROR (jsonrpc/6) [storage.TaskManager.Task] (Task='91f2ab5b-017a-4c88-aa45-ece3bd920ce0') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "<string>", line 2, in createVG File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 2146, in createVG force=force) File "/usr/lib/python2.7/site-packages/vdsm/storage/lvm.py", line 1256, in createVG _initpvs(pvs, metadataSize, force) File "/usr/lib/python2.7/site-packages/vdsm/storage/lvm.py", line 990, in _initpvs raise se.PhysDevInitializationError(str(devices)) PhysDevInitializationError: Failed to initialize physical device: ("[u'/dev/mapper/32021001378a6ddad']",) 2020-11-11 10:43:12,520-0800 INFO (jsonrpc/6) [storage.TaskManager.Task] (Task='91f2ab5b-017a-4c88-aa45-ece3bd920ce0') aborting: Task is aborted: 'Failed to initialize physical device: ("[u\'/dev/mapper/32021001378a6ddad\']",)' - code 601 (task:1181) 2020-11-11 10:43:12,521-0800 ERROR (jsonrpc/6) [storage.Dispatcher] FINISH createVG error=Failed to initialize physical device: ("[u'/dev/mapper/32021001378a6ddad']",) (dispatcher:83) 2020-11-11 10:43:12,521-0800 INFO (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC call LVMVolumeGroup.create failed (error 601) in 0.20 seconds (__init__:312)

1 1

Dependencies failure when upgrading from version 4.4.2 to 4.4.3
by jorgevisentini＠gmail.com 11 Nov '20

11 Nov '20

When I update the Engine and Host, many dependencies are missing, as shown by the host error log: Error: Problem 1: package ovirt-hosted-engine-setup-2.4.6-1.el8.noarch requires ovirt-ansible-engine-setup >= 1.1.9, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-engine-setup provided by ovirt-ansible-engine-setup-1.2.4-1.el8.noarch - cannot install the best update candidate for package ovirt-hosted-engine-setup-2.4.6-1.el8.noarch - cannot install the best update candidate for package ovirt-ansible-engine-setup-1.2.4-1.el8.noarch Problem 2: package ovirt-host-4.4.1-4.el8.x86_64 requires ovirt-hosted-engine-setup, but none of the providers can be installed - package ovirt-hosted-engine-setup-2.4.6-1.el8.noarch requires ovirt-ansible-hosted-engine-setup >= 1.0.34, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-hosted-engine-setup provided by ovirt-ansible-hosted-engine-setup-1.1.8-1.el8.noarch - cannot install the best update candidate for package ovirt-host-4.4.1-4.el8.x86_64 - cannot install the best update candidate for package ovirt-ansible-hosted-engine-setup-1.1.8-1.el8.noarch - package ovirt-ansible-hosted-engine-setup-1.1.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-ansible-hosted-engine-setup-1.1.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-ansible-hosted-engine-setup-1.1.6-1.el8.noarch is filtered out by exclude filtering - package ovirt-ansible-hosted-engine-setup-1.1.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-hosted-engine-setup-2.4.4-1.el8.noarch is filtered out by exclude filtering - package ovirt-hosted-engine-setup-2.4.5-1.el8.noarch is filtered out by exclude filtering - package ovirt-hosted-engine-setup-2.4.7-1.el8.noarch is filtered out by exclude filtering - package ovirt-hosted-engine-setup-2.4.8-1.el8.noarch is filtered out by exclude filtering (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

3 3

Single Node HCI upgrade procedure from CentOS7/oVirt 4.3 to CentOS8/oVirt 4.4?
by thomas＠hoberg.net 11 Nov '20

11 Nov '20

I can hear you saying: "You did understand that single node HCI is just a toy, right?" For me the primary use of a single node HCI is adding some disaster resilience in small server edge type scenarios, where a three node HCI provides the fault tolerance: 3+1 with a bit of distance, warm or even cold stand-by, potentially manual switch and reduced workload in case disaster strikes. Of course, another 3nHCI would be better, but who gets that type of budget, right? What I am trying say: If you want oVirt to gain market share, try to give HCI more love. And while you're at it, try to make expanding from 1nHCI to 3nHCI (and higher counts) a standard operational procedure to allow expanding a disaster stand-by into a production setup, while the original 3nHCI is being rebuilt. For me low-budget HCI is where oVirt has its biggest competitive advantage against vSan and Nutanix, so please don't treat the HCI/gluster variant like an unwanted child any more. In the mean-time OVA imports (from 4.3.10 exports) on my 4.4.2 1nHCI fail again, which I'll report separately.

2 1

Upgrade Problem oVirt engine 4.4.1.8-1.el8 -> 4.4.3
by Andrei Verovski 11 Nov '20

11 Nov '20

Hi ! I’m trying to upgrade oVirt engine 4.4.1.8-1.el8 to the latest 4.4.3, running as KVM appliance (not hosted engine). This sequence of commands yum install https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm engine-upgrade-check yum update ovirt\*setup\* Results in a long list of dependency errors, short excerpt below. Looks like something (e.g. repo) is missing. How to fix this? Thanks in advance. ————— LOG ---------- Problem 1: problem with installed package ovirt-engine-ui-extensions-1.2.2-1.el8.noarch - package ovirt-engine-ui-extensions-1.2.2-1.el8.noarch requires ovirt-ansible-cluster-upgrade >= 1.1.12, but none of the providers can be installed Problem 2: package ovirt-engine-4.4.1.8-1.el8.noarch requires ovirt-engine-ui-extensions >= 1.0.4, but none of the providers can be installed - package ovirt-engine-ui-extensions-1.2.2-1.el8.noarch requires ovirt-ansible-cluster-upgrade >= 1.1.12, but none of the providers can be installed - package ovirt-engine-4.4.1.8-1.el8.noarch requires ovirt-ansible-roles >= 1.2.0, but none of the providers can be installed - package ovirt-ansible-collection-1.2.1-1.el8.noarch obsoletes ovirt-ansible-cluster-upgrade provided by ovirt-ansible-cluster-upgrade-1.2.3-1.el8.noarch

3 3

Cluster with Hosted Engine update BIOS Setting Ovirt 4.4.3
by scrik787＠gmail.com 11 Nov '20

11 Nov '20

I changed the type in the cluster and now my hosted-engine machine won't start!. There are no backups. How can I manually change the parameters of the machine from under the roof so that it starts and I can restore ovirt to work Error in logs: XML error: The device at PCI address 0000:00:02.0 cannot be plugged into the PCI controller with index='0'. It requires a controller that accepts a pcie-root-port VDSM.log https://pastebin.com/vsAKy9rX

2 1

Host NonResponsive after migration to oVirt 4.4
by tferic＠swissonline.ch 11 Nov '20

11 Nov '20

Hi I am looking for help after my oVirt upgrade failed. I have upgraded from ovirt 4.3 to 4.4 following the instructions here: https://www.ovirt.org/documentation/upgrade_guide/#Upgrading_from_4-3 <https://www.ovirt.org/documentation/upgrade_guide/#Upgrading_from_4-3> It's a single-host (standalone engine) test environment. I wiped CentOS 7 and reinstalled a fresh CentOS 8. I installed the oVirt 4.4 repo and all the necessary software packets. I used `engine-backup --mode=restore --file=/tmp/ovirt-engine-pre-upgrade.backup --provision-all-databases` from a backup file I created before I started the upgrade. After the restore, I ran `engine-setup`. I did not get any errors during any of these steps on the console. So the upgrade could be considered successful from that perspective. After the upgrade, I login to the ovirt admin portal, and I try to "Activate" my host (was set to "Maintenance" mode before upgrade). The Activation fails with error "NonResponsive" in the GUI. Under the "bell" icon, I find the Event "Host nuc1.feric.ch is non responsive.” In /var/log/ovirt-engine/engine.log, I find the following error: ``` 2020-11-09 23:12:21,080+01 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-47) [] Command 'GetCapabilitiesAsyncVDSCommand(HostName = nuc1.feric.ch, VdsIdAndVdsVDSCommandParametersBase:{hostId='d7c30cc0-ac59-4cf3-a1e7-b9fae9db83fb', vds=‘Host[nuc1.feric.h,d7c30cc0-ac59-4cf3-a1e7-b9fae9db83fb]'})' execution failed: java.net.ConnectException: Connection refused ``` `systemctl status ovirt-engine` shows that the engine is running. I am able to reboot the host from the oVirt GUI directly. Does anyone have an idea how to proceed? Many thanks Toni

3 7

Clone a VM in the User Portal
by Nicolás 11 Nov '20

11 Nov '20

Hi, We're using oVirt 4.3.8, having an organization that intensively uses the User Portal. After upgrading from 4.2, we've noticed that cloning a VM from within the User Portal is not possible anymore. In our case, this feature was heavily used by hundreds of students deploying their VMs. Is this feature in the roadmap yet? If not, do you consider it useful to open a RFE? Thank you. Regards, Nico

3 6

Cannot restore engine from 4.3.9 to 4.4.3
by tferic＠swissonline.ch 11 Nov '20

11 Nov '20

Hi I just tried to restore my engine backup taken from release 4.3.9.4 to a newer oVirt installation release 4.4.3.11. The restore process fails with a FATAL error. I was under the impression that backups from all 4.3 versions were supposed to be restorable on 4.4. My installation is a single-box all-in-one (Standalone Engine installed together with oVirt node). # engine-backup --mode=restore --file=/exports/data-t2/backups/ovirt-engine-backup-20201018124037_pre-upgrade.backup --provision-all-databases Start of engine-backup with mode 'restore' scope: all archive file: /exports/data-t2/backups/ovirt-engine-backup-20201018124037_pre-upgrade.backup log file: /var/log/ovirt-engine-backup/ovirt-engine-restore-20201111031500.log Preparing to restore: - Unpacking file '/exports/data-t2/backups/ovirt-engine-backup-20201018124037_pre-upgrade.backup' FATAL: Backup was created by version '4.3.9.4' and can not be restored using the installed version 4.4.3.11 Complete content of the restore log file: 2020-11-11 03:15:00 23143: Start of engine-backup mode restore scope all file /exports/data-t2/backups/ovirt-engine-backup-20201018124037_pre-upgrade.backup 2020-11-11 03:15:00 23143: OUTPUT: Start of engine-backup with mode 'restore' 2020-11-11 03:15:00 23143: OUTPUT: scope: all 2020-11-11 03:15:00 23143: OUTPUT: archive file: /exports/data-t2/backups/ovirt-engine-backup-20201018124037_pre-upgrade.backup 2020-11-11 03:15:00 23143: OUTPUT: log file: /var/log/ovirt-engine-backup/ovirt-engine-restore-20201111031500.log 2020-11-11 03:15:00 23143: OUTPUT: Preparing to restore: 2020-11-11 03:15:01 23143: OUTPUT: - Unpacking file '/exports/data-t2/backups/ovirt-engine-backup-20201018124037_pre-upgrade.backup' 2020-11-11 03:15:01 23143: Opening tarball /exports/data-t2/backups/ovirt-engine-backup-20201018124037_pre-upgrade.backup to /tmp/engine-backup.UAcLerghwY 2020-11-11 03:15:01 23143: Verifying hash 2020-11-11 03:15:01 23143: Verifying version 2020-11-11 03:15:01 23143: FATAL: Backup was created by version '4.3.9.4' and can not be restored using the installed version 4.4.3.11 regards, Toni Feric

2 1

Problem with Cluster-wise BIOS Settings in oVirt 4.4
by Rodrigo G. López 11 Nov '20

11 Nov '20

Hi all, We are running an oVirt 4.4 Hosted Engine as a VM, and after changing the Cluster's BIOS type from Q35 with Legacy BIOS (the default one after installation) to Preexistent, the VM fails with the following error: XML error: The device at PCI address 0000:00:02.0 cannot be plugged into the PCI controller with index='0'. It requires a controller that accepts a pcie-root-port. We need it so that we can run imported VMs from a previous version of oVirt, namely 4.0. Applying the BIOS settings individually works but as an attempt to generalize the settings we decided to apply it to the full cluster. Tell me if you need more data. Cheers, -rodri

4 6

oVirt 4.4.2 MS Windows 10 sysprep floppy
by ozmen62＠hotmail.com 11 Nov '20

11 Nov '20

Hi, I've cretated a template which has sysprep. Every document about sysprep says use "Attach Floppy" , but we know this function has been disabled/deprecated So, when i use Run One, attach windows cdrom and put in it definitions (domain name, user credentials etc) , nothing happens. I also have correct properties and sysprep files in engine Just windows boot like it is new machine and ask lots of questions for prepare itself. Would someone please explain this? How can i run sysprep correctly?

4 11

setting routing rules for guests?
by yam yam 11 Nov '20

11 Nov '20

Hello everyone! I'm wondering there is any feature like applying routing rules for VM to reach the external network (and vice versa). and I guess it's different according to using external provider(OVN). if not, how to users usually assign floating IP to VM?? Thanks Sincerely,

3 7

Re: Clone a VM in the User Portal
by Arik Hadas 10 Nov '20

10 Nov '20

On Tue, Nov 10, 2020 at 10:10 PM tferic(a)swissonline.ch < tferic(a)swissonline.ch> wrote: > Cloning VM's is a core feature of virtualization. > > I remember having cloned VM's back in the 90's with the free VMware > version 0.9. > > My main use case ever since is cloning fully configured production servers > into a testservers, for isolated testing. > > Why would a hypervisor not offer cloning, when it is possible and useful? > > regards, Toni > (Added users(a)ovirt.org back) Sure, it can be handy in some cases - that's why we've implemented it in oVirt and enhance it in 4.4.3 (for running VMs). But I wouldn't expect it to be commonly used via the user portal, that's why I am interested in the use-case. > > On 10.11.20 16:22, Arik Hadas wrote: > > > > On Tue, Nov 10, 2020 at 4:37 PM Nicolás <nicolas(a)devels.es> wrote: > >> Hi Arik, >> >> El 10/11/20 a las 13:21, Arik Hadas escribió: >> >> >> >> On Tue, Nov 10, 2020 at 3:08 PM Nicolás <nicolas(a)devels.es> wrote: >> >>> Hi Sharon, >>> >>> Thanks for the reply! I've opened [1], so hopefully someone will be able >>> to implement it. >>> >>> Regards, >>> >>> Nico >>> >>> [1]: https://github.com/oVirt/ovirt-site/issues/2389 >>> >>> El 10/11/20 a las 11:38, Sharon Gratch escribió: >>> >>> Hi, >>> >>> This feature of cloning a VM was indeed part of the old User Portal and >>> you are right that it's not supported by the newer VM Portal (since oVirt >>> 4.3). >>> It seemed that this wasn't required by VM Portal users (no user >>> complained up till now) and that's why we omitted it and it's not part of >>> our current roadmap to implement it as well. >>> >>> Nevertheless, there is no real reason not to include that ability as >>> part of VM Portal, so you are most welcome to open an issue on >>> https://github.com/oVirt/ovirt-web-ui/issues >>> <https://github.com/oVirt/ovirt-site/issues> >>> and you can push a fix yourself if you have time (or someone else from >>> the community) :-) >>> >>> Thanks! >>> Sharon >>> >>> On Fri, Nov 6, 2020 at 11:06 AM Nicolás <nicolas(a)devels.es> wrote: >>> >>>> Hi, >>>> >>>> We're using oVirt 4.3.8, having an organization that intensively uses >>>> the User Portal. After upgrading from 4.2, we've noticed that cloning a >>>> VM from within the User Portal is not possible anymore. In our case, >>>> this feature was heavily used by hundreds of students deploying their >>>> VMs. >>>> >>> >> Out of curiosity, why cloning a VM and not provisioning the VMs from >> template(s)? >> >> >> >> Most of our students are IT-related, and their professors want to teach >> them the procedure to deploy a VM from scratch. Some other courses surely >> deploy their VMs from a template as they are not that IT oriented and they >> just want to have a working VM instead of building it from scratch. We have >> a lot of casuistry, but in our case about 400~500 students would very >> welcome having back the clone option. >> > > Thanks Nicolás. > I'd say that even for the IT-related students it may make more sense to > provision VMs from templates instead of cloning VMs - > so you want them to deploy VMs from scratch, which means starting with a > VM that is based on the blank template, add disk(s) and other devices, > install and configure the guest and such; and then the students would use > clone-VM to duplicate the VM they just prepared, right? > Why would you want them to clone the VM rather than creating a template > out of this VM and provision further VMs from that template with > thin-provisioned disks? > > >> >> Regards, >> >> Nico >> >> >>>> Is this feature in the roadmap yet? If not, do you consider it useful >>>> to >>>> open a RFE? >>>> >>>> Thank you. >>>> >>>> Regards, >>>> >>>> Nico >>>> _______________________________________________ >>>> Users mailing list -- users(a)ovirt.org >>>> To unsubscribe send an email to users-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/users@ovirt.org/message/HFMFJRV3AC3GV… >>>> >>> >>> _______________________________________________ >>> Users mailing list -- users(a)ovirt.org >>> To unsubscribe send an email to users-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/users@ovirt.org/message/RUEW52WZUD27I… >>> >> >> > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-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/users@ovirt.org/message/QXPS6FCRT66HF… > >

1 0

[ANN] oVirt 4.4.3 is now generally available
by Sandro Bonazzola 10 Nov '20

10 Nov '20

oVirt 4.4.3 is now generally available The oVirt project is excited to announce the general availability of oVirt 4.4.3 , as of November 10th, 2020. This release unleashes an altogether more powerful and flexible open source virtualization solution that encompasses hundreds of individual changes and a wide range of enhancements across the engine, storage, network, user interface, and analytics, as compared to oVirt 4.3. Important notes before you install / upgrade Please note that oVirt 4.4 only supports clusters and data centers with compatibility version 4.2 and above. If clusters or data centers are running with an older compatibility version, you need to upgrade them to at least 4.2 (4.3 is recommended). Please note that in RHEL 8 / CentOS 8 several devices that worked on EL7 are no longer supported. For example, the megaraid_sas driver is removed. If you use Enterprise Linux 8 hosts you can try to provide the necessary drivers for the deprecated hardware using the DUD method (See the users’ mailing list thread on this at https://lists.ovirt.org/archives/list/users@ovirt.org/thread/NDSVUZSESOXEFJ… ) Documentation - If you want to try oVirt as quickly as possible, follow the instructions on the Download <https://ovirt.org/download/> page. - For complete installation, administration, and usage instructions, see the oVirt Documentation <https://ovirt.org/documentation/>. - For upgrading from a previous version, see the oVirt Upgrade Guide <https://ovirt.org/documentation/upgrade_guide/>. - For a general overview of oVirt, see About oVirt <https://ovirt.org/community/about.html>. What’s new in oVirt 4.4.3 Release? This update is the third in a series of stabilization updates to the 4.4 series. This release is available now on x86_64 architecture for: - Red Hat Enterprise Linux 8.2 / 8.3 - CentOS Linux (or similar) 8.2 - CentOS Stream (tech preview) This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: - Red Hat Enterprise Linux 8.2 / 8.3 - CentOS Linux (or similar) 8.2 - CentOS Stream (tech preview) Please note that this release introduces cluster compatibility level 4.5 which is supported only with Red Hat Enterprise Linux 8.3 or equivalent. oVirt Node and Appliance have been updated, including: - oVirt 4.4.3: https://www.ovirt.org/release/4.4.3/ - Ansible 2.9.15: https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.… - Glusterfs 7.8: https://docs.gluster.org/en/latest/release-notes/7.8/ See the release notes [1] for installation instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available for CentOS Linux 8 - oVirt Node NG will be available soon for CentOS Linux 8 Additional resources: - Read more about the oVirt 4.4.3 release highlights: https://www.ovirt.org/release/4.4.3/ - Get more oVirt project updates on Twitter: https://twitter.com/ovirt - Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/release/4.4.3/ <https://www.ovirt.org/release/4.4.3/> [2] https://resources.ovirt.org/pub/ovirt-4.4/iso/ -- 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.*

1 0

VM's gone to unknown state
by hjadavalluva＠ukaachen.de 10 Nov '20

10 Nov '20

Hello, I have an issue with ovirt 4.3 console. The exact issue is, except hosted engine, all other VM's gone to unknown state. I wonder what's the problem is? And how bring back the VM's to normal state. I can see that nothing is enable (for instance, acktivate option, maintaiance option, etc). Can anyone guide me please in this? Thanks in advance! Best Regards, Hariharan

3 9