10:44 a.m.
Hi..
I'm looking to migrate soon from CentOS 7.9 with oVirt 4.3.10 to Rocky
Linux 8.4 with oVirt 4.4.6. I'm working on my kickstart of my
standalone engine in a VM at the moment.
So far, with minimal experience with Rocky Linux, after my kickstart, I
was able to run "engine-setup", follow all the defaults and then access
my "new" engine via web. I have to explore the actual procedure for
installing on my current engine host, and restoring my data.
When oVirt team releases new releases, I'm just wondering if you test
going from the last previous release (4.3.10 in this case) to each
latest release? I know that the documentation says we always need to
make sure we update to each individaul major release, but I'm just
wondering if this is something that oVirt team tests with each release?
I'm very concerned for potential of failed upgrade, and the potential
headaches that it could cause.
I see the 4.4.6 was released in time with RHEL 8.3. I'd like to use
Rocky Linux 8.4 because I believe RHEL has re-enabled mptsas (though I
know still unsupported) from 8.4+ which will make things easier.
Any additional suggestions or caveats of the upgrade?
Thanks for any feedback,
Jason.
8:06 a.m.
On Wed, Jun 30, 2021 at 5:45 PM Jason Keltz <jas(a)yorku.ca> wrote:
Hi..
I'm looking to migrate soon from CentOS 7.9 with oVirt 4.3.10 to Rocky
Linux 8.4 with oVirt 4.4.6. I'm working on my kickstart of my
standalone engine in a VM at the moment.
So far, with minimal experience with Rocky Linux, after my kickstart, I
was able to run "engine-setup", follow all the defaults and then access
my "new" engine via web. I have to explore the actual procedure for
installing on my current engine host, and restoring my data.
When oVirt team releases new releases, I'm just wondering if you test
going from the last previous release (4.3.10 in this case) to each
latest release?
Migration flows are tested for RHV, so it should work for oVirt if you wait
until the RHV version was released, and you have same RHEL-like version
as was tested with RHV.
I know that the documentation says we always need to
make sure we update to each individaul major release, but I'm just
wondering if this is something that oVirt team tests with each release?
I'm very concerned for potential of failed upgrade, and the potential
headaches that it could cause.
I see the 4.4.6 was released in time with RHEL 8.3. I'd like to use
Rocky Linux 8.4 because I believe RHEL has re-enabled mptsas (though I
know still unsupported) from 8.4+ which will make things easier.
RHV 4.4.6 was released with RHEL 8.4, and is oVit 4.4.6 compatible with
RHEL 8.4, so it should work with any REHEL 8.4-like distro.
But note that oVirt uses the advanced virtualization stream, providing
libvirt 7.0.0 and qemu-kvm 5.2.0:
http://mirror.centos.org/centos/8/virt/x86_64/advanced-virtualization/Pac...
Looking in Rocky packages, this is not available yet:
https://download.rockylinux.org/pub/rocky/8/AppStream/x86_64/os/Packages/
To replace Centos as the production OS for oVirt, the community must also
rebuild advanced virtualization.
You can try to use Rocky and pull in the advanced-virtualization repo from
Centos as a temporary solution.
Nir
11:23 a.m.
On 7/1/2021 8:06 AM, Nir Soffer wrote:
But note that oVirt uses the advanced virtualization stream,
providing
libvirt 7.0.0 and qemu-kvm 5.2.0:
http://mirror.centos.org/centos/8/virt/x86_64/advanced-virtualization/Pac...
Looking in Rocky packages, this is not available yet:
https://download.rockylinux.org/pub/rocky/8/AppStream/x86_64/os/Packages/
To replace Centos as the production OS for oVirt, the community must also
rebuild advanced virtualization.
You can try to use Rocky and pull in the advanced-virtualization repo from
Centos as a temporary solution.
Ugh. Thanks for letting me know. That's a *BIG* fly in the ointment
right there. I noticed that Alma doesn't do it either. In fact, I don't
even see it in the Oracle Linux repository even though it must be there
somewhere because I know they have their own 'RHEV' clone.
I would prefer to stay away from CentOS Stream for the virtualization
platform. The RHEL product itself would be a perfect solution, but
it's rather costly if just using it for a virtualization host OS, and
there are surprisingly no education discounts. I have to see if Rocky
will eventually provide it, or see if I can get internal funding for RHEL.
Jason.
3:26 a.m.
I would prefer to stay away from CentOS Stream for the virtualization
platform. The RHEL product itself would be a perfect solution, but
it's rather costly if just using it for a virtualization host OS, and
there are surprisingly no education discounts.
I don't know all the details, but it would worth to check the possibility to
get RHEL for free for your organization, see
https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux...
There is also some program for universities, but no idea, how much you can
safe with it or if it worth in your case
https://www.redhat.com/en/resources/rhel-site-subscription-academics-broc...
11:54 a.m.
Hi Nir
Thank you for your explanation.
Can I ask you if you can explain this a bit further? I performed and experiment and
installed ovirt + a hypervisor on 2 VMs (on the hypervisor VM I enabled nested
virtualization) - both based on Rocky Linux following the official oVirt instructions for
4.4.7. No problems there - I also created a vm and successfully ran it. Based on this,
Rocky - at the moment - replaces CentOS8 just nicely. And while libvirt installed is
libvirt-7.0.0-14.1.el8.x86_64 and comes from CentOS8 advanced virt repo, qemu on the
hypervisor machine is qemu-kvm-4.2.0-48.module+el8.4.0+534+4680a14e.x86_64 not 5.2.0 and
comes from Rocky's repos. Does it mean that, once CentOS8 reaches EOL at the end of
this year, we should only hope that Rocky releases libvirt-7.0.0 in their advanced-virt
repo?
A snippet from oVirt GUI - hypervisor properties:
OS Version: RHEL - 8.4 - 30.el8
OS Description: Rocky Linux 8.4 (Green Obsidian)
Kernel Version: 4.18.0 - 305.7.1.el8_4.x86_64
KVM Version: 4.2.0 - 48.module+el8.4.0+534+4680a14e
LIBVIRT Version: libvirt-7.0.0-14.1.el8
and confirmation:
# rpm -q qemu-kvm
qemu-kvm-4.2.0-48.module+el8.4.0+534+4680a14e.x86_64
Thank you in advance!
Kind regards,
Branimir
6:39 p.m.
On Sat, Jul 10, 2021 at 6:55 PM <branimirp(a)gmail.com> wrote:
Hi Nir
Thank you for your explanation.
Can I ask you if you can explain this a bit further? I performed and experiment and
installed ovirt + a hypervisor on 2 VMs (on the hypervisor VM I enabled nested
virtualization) - both based on Rocky Linux following the official oVirt instructions for
4.4.7. No problems there - I also created a vm and successfully ran it.
How did you install ovirt 4.4.7, when we require qemu-kvm >= 5.2.0?
I see this in vdsm.spec:
%if 0%{?rhel} >= 8
%if 0%{?centos}
# 4.4 Advanced virt stream on CentOS 8
Requires: qemu-kvm >= 15:5.2.0
%else
# 4.4, AV 8.4 - https://bugzilla.redhat.com/1948532
Requires: qemu-kvm >= 15:5.2.0-15.module+el8.4.0+10650+50781ca0
%endif #centos
%endif #rhel
Maybe you install an old rc version, before we updated the requirement?
Based on this, Rocky - at the moment - replaces CentOS8 just nicely.
And while libvirt installed is libvirt-7.0.0-14.1.el8.x86_64 and comes from CentOS8
advanced virt repo, qemu on the hypervisor machine is
qemu-kvm-4.2.0-48.module+el8.4.0+534+4680a14e.x86_64 not 5.2.0 and comes from Rocky's
repos. Does it mean that, once CentOS8 reaches EOL at the end of this year, we should only
hope that Rocky releases libvirt-7.0.0 in their advanced-virt repo?
A snippet from oVirt GUI - hypervisor properties:
OS Version: RHEL - 8.4 - 30.el8
OS Description: Rocky Linux 8.4 (Green Obsidian)
Kernel Version: 4.18.0 - 305.7.1.el8_4.x86_64
KVM Version: 4.2.0 - 48.module+el8.4.0+534+4680a14e
LIBVIRT Version: libvirt-7.0.0-14.1.el8
This version is good enough for ovirt 4.4.7.
and confirmation:
# rpm -q qemu-kvm
qemu-kvm-4.2.0-48.module+el8.4.0+534+4680a14e.x86_64
This version does not support features expected by vdsm. I wonder how you have
new libvirt with old qemu.
- qemu-img convert does not support the --bitmaps option, used to copy bitmaps
created during incremental backup when moving disks.
- qemu-img bitmap sub command is not available. use to add, remove and merge
bitmaps in various flows
- qemu-nbd does not support --allocation-depth option. Use to report holes in
qcow2 images.
- there may be other missing features that libvirt 7.0.0 depends on
You may have luck with flows that do not use the missing features.
Nir
6:49 p.m.
Hi Nir
It was a fresh install of 2 VMs on top of VirtualBox with Rocky fully updated on both
prior to oVirt installation. I installed it yesterday and followed the usual way of
installing it: https://www.ovirt.org/download/alternate_downloads.html.
Here are the oVirt packages that are installed on the hypervisor:
ovirt-vmconsole-1.0.9-1.el8.noarch
ovirt-ansible-collection-1.5.3-1.el8.noarch
ovirt-openvswitch-ovn-2.11-1.el8.noarch
ovirt-host-dependencies-4.4.7-1.el8.x86_64
ovirt-vmconsole-host-1.0.9-1.el8.noarch
ovirt-openvswitch-ovn-host-2.11-1.el8.noarch
ovirt-openvswitch-2.11-1.el8.noarch
ovirt-provider-ovn-driver-1.2.33-1.el8.noarch
ovirt-host-4.4.7-1.el8.x86_64
ovirt-imageio-client-2.2.0-1.el8.x86_64
python3-ovirt-setup-lib-1.3.2-1.el8.noarch
python3-ovirt-engine-sdk4-4.4.13-1.el8.x86_64
ovirt-release44-4.4.7-1.el8.noarch
ovirt-hosted-engine-ha-2.4.7-1.el8.noarch
ovirt-hosted-engine-setup-2.5.2-1.el8.noarch
ovirt-imageio-daemon-2.2.0-1.el8.x86_64
ovirt-python-openvswitch-2.11-1.el8.noarch
ovirt-openvswitch-ovn-common-2.11-1.el8.noarch
cockpit-ovirt-dashboard-0.15.0-1.el8.noarch
ovirt-imageio-common-2.2.0-1.el8.x86_64
and repos:
appstream Rocky Linux 8 -
AppStream
baseos Rocky Linux 8 - BaseOS
extras Rocky Linux 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-ceph-pacific Ceph packages for x86_64
ovirt-4.4-centos-gluster8 CentOS-8 - Gluster 8
ovirt-4.4-centos-nfv-openvswitch CentOS-8 - NFV
OpenvSwitch
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: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-openstack-train OpenStack Train
Repository
ovirt-4.4-virtio-win-latest virtio-win builds roughly
matching what will be shipped in
# yum list installed qemu-kvm
Installed Packages
qemu-kvm.x86_64 15:4.2.0-48.module+el8.4.0+534+4680a14e
@AppStream
# yum list installed libvirt
Installed Packages
libvirt.x86_64 7.0.0-14.1.el8
@ovirt-4.4-advanced-virtualization
I didn't do anything out of ordinary - as a matter of fact i wanted to make an
experiment to see if I can move from CentOS8 to Rocky by doing clean installation before
doing it for "real" on bare metal nodes.
Thank you.
Kind regards,
Branimir
8:11 p.m.
On Mon, Jul 12, 2021 at 1:50 AM Branimir Pejakovic <branimirp(a)gmail.com> wrote:
It was a fresh install of 2 VMs on top of VirtualBox with Rocky fully
updated on both prior to oVirt installation. I installed it yesterday and followed the
usual way of installing it: https://www.ovirt.org/download/alternate_downloads.html.
Here are the oVirt packages that are installed on the hypervisor:
Unfortunately vdsm (the core package for ovirt host) does not
have ovirt-prefix. Which version do you have?
...
ovirt-imageio-client-2.2.0-1.el8.x86_64
This package requires qemu-img >= 5.2.0
Maybe the requirement is broken (missing epoch).
What does "qemu-img --version" tell?
Nir
7:56 a.m.
Hi Nir
On Mon, Jul 12, 2021 at 1:50 AM Branimir Pejakovic
<branimirp(a)gmail.com> wrote:
Unfortunately vdsm (the core package for ovirt host) does not
have ovirt-prefix. Which version do you have?
...
Just in case:
# rpm -qa | grep vdsm
vdsm-jsonrpc-4.40.60.7-1.el8.noarch
vdsm-yajsonrpc-4.40.60.7-1.el8.noarch
vdsm-common-4.40.60.7-1.el8.noarch
vdsm-client-4.40.60.7-1.el8.noarch
vdsm-hook-vmfex-dev-4.40.60.7-1.el8.noarch
vdsm-api-4.40.60.7-1.el8.noarch
vdsm-python-4.40.60.7-1.el8.noarch
vdsm-network-4.40.60.7-1.el8.x86_64
vdsm-http-4.40.60.7-1.el8.noarch
vdsm-4.40.60.7-1.el8.x86_64
This package requires qemu-img >= 5.2.0
Maybe the requirement is broken (missing epoch).
What does "qemu-img --version" tell?
# qemu-img --version
qemu-img version 4.2.0 (qemu-kvm-4.2.0-48.module+el8.4.0+534+4680a14e)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
During the installation itself, there were no errors/surprises. Everything went smoothly.
Thank you.
Kind regards,
Branimir
2:01 p.m.
On Tue, Jul 13, 2021 at 2:57 PM Branimir Pejakovic <branimirp(a)gmail.com> wrote:
...
> On Mon, Jul 12, 2021 at 1:50 AM Branimir Pejakovic
<branimirp(a)gmail.com> wrote:
>
> Unfortunately vdsm (the core package for ovirt host) does not
> have ovirt-prefix. Which version do you have?
> ...
Just in case:
# rpm -qa | grep vdsm
vdsm-jsonrpc-4.40.60.7-1.el8.noarch
vdsm-yajsonrpc-4.40.60.7-1.el8.noarch
vdsm-common-4.40.60.7-1.el8.noarch
vdsm-client-4.40.60.7-1.el8.noarch
vdsm-hook-vmfex-dev-4.40.60.7-1.el8.noarch
vdsm-api-4.40.60.7-1.el8.noarch
vdsm-python-4.40.60.7-1.el8.noarch
vdsm-network-4.40.60.7-1.el8.x86_64
vdsm-http-4.40.60.7-1.el8.noarch
vdsm-4.40.60.7-1.el8.x86_64
> This package requires qemu-img >= 5.2.0
> Maybe the requirement is broken (missing epoch).
>
> What does "qemu-img --version" tell?
# qemu-img --version
qemu-img version 4.2.0 (qemu-kvm-4.2.0-48.module+el8.4.0+534+4680a14e)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
During the installation itself, there were no errors/surprises. Everything went smoothly.
So vdsm spec is broken on Rocky, letting you install vdsm when the required
qemu-kvm version is not available.
Can you file an ovirt/vdsm bug for this?
https://bugzilla.redhat.com/enter_bug.cgi?product=vdsm
I tried to add a Rocky host to my setup and I can confirm that it works.
I create a new vm from:
https://download.rockylinux.org/pub/rocky/8/isos/x86_64/Rocky-8.4-x86_64-...
Install ovirt-release44.rpm from:
https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm
And added the host to my engine (4.4.8 master). The host was installed
and activated, and can runs.
I found that migrating vms from other hosts (qemu-6.0, libvirt 7.4)
does not work. I think this issue was already reported here and fix is
expected from libvirt soon.
However I do get the the *right* version of qemu-kvm, provided by:
[root@rocky1 ~]# dnf info qemu-kvm
Last metadata expiration check: 18:02:00 ago on Tue 13 Jul 2021 02:37:31 AM IDT.
Installed Packages
Name : qemu-kvm
Epoch : 15
Version : 5.2.0
Release : 16.el8
Architecture : x86_64
Size : 0.0
Source : qemu-kvm-5.2.0-16.el8.src.rpm
Repository : @System
From repo : ovirt-4.4-advanced-virtualization
[root@rocky1 ~]# grep -A2 ovirt-4.4-advanced-virtualization
/etc/yum.repos.d/ovirt-4.4-dependencies.repo
[ovirt-4.4-advanced-virtualization]
name=Advanced Virtualization packages for $basearch
mirrorlist=http://mirrorlist.centos.org/?arch=$basearch&release=8&...
So oVirt is ready to rock on Rocky with little help from Centos :-)
I'm not sure about the future of the ovirt-4.4-advanced-virtualization
repository after Centos 8 will be discontinued, so this does not look
like production ready yet.
The advanced virtualization packages are likely needed by other virtualization
systems (openstack, proxmox, ...) or anyone that wants to consume the latest
features from libvirt and qemu, so packing it in oVirt is not the
right solution.
Nir
4:26 p.m.
On Tue, 2021-07-13 at 21:01 +0300, Nir Soffer wrote:
On Tue, Jul 13, 2021 at 2:57 PM Branimir Pejakovic <
branimirp(a)gmail.com> wrote:
...
> > On Mon, Jul 12, 2021 at 1:50 AM Branimir Pejakovic
> > <branimirp(a)gmail.com> wrote:
> >
> > Unfortunately vdsm (the core package for ovirt host) does not
> > have ovirt-prefix. Which version do you have?
> > ...
>
> Just in case:
>
> # rpm -qa | grep vdsm
> vdsm-jsonrpc-4.40.60.7-1.el8.noarch
> vdsm-yajsonrpc-4.40.60.7-1.el8.noarch
> vdsm-common-4.40.60.7-1.el8.noarch
> vdsm-client-4.40.60.7-1.el8.noarch
> vdsm-hook-vmfex-dev-4.40.60.7-1.el8.noarch
> vdsm-api-4.40.60.7-1.el8.noarch
> vdsm-python-4.40.60.7-1.el8.noarch
> vdsm-network-4.40.60.7-1.el8.x86_64
> vdsm-http-4.40.60.7-1.el8.noarch
> vdsm-4.40.60.7-1.el8.x86_64
>
> > This package requires qemu-img >= 5.2.0
> > Maybe the requirement is broken (missing epoch).
> >
> > What does "qemu-img --version" tell?
>
> # qemu-img --version
> qemu-img version 4.2.0 (qemu-kvm-4.2.0-
> 48.module+el8.4.0+534+4680a14e)
> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project
> developers
>
> During the installation itself, there were no errors/surprises.
> Everything went smoothly.
So vdsm spec is broken on Rocky, letting you install vdsm when the
required
qemu-kvm version is not available.
Can you file an ovirt/vdsm bug for this?
https://bugzilla.redhat.com/enter_bug.cgi?product=vdsm
I tried to add a Rocky host to my setup and I can confirm that it
works.
I create a new vm from:
https://download.rockylinux.org/pub/rocky/8/isos/x86_64/Rocky-8.4-x86_64-...
Install ovirt-release44.rpm from:
https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm
And added the host to my engine (4.4.8 master). The host was
installed
and activated, and can runs.
I found that migrating vms from other hosts (qemu-6.0, libvirt 7.4)
does not work. I think this issue was already reported here and fix
is
expected from libvirt soon.
However I do get the the *right* version of qemu-kvm, provided by:
[root@rocky1 ~]# dnf info qemu-kvm
Last metadata expiration check: 18:02:00 ago on Tue 13 Jul 2021
02:37:31 AM IDT.
Installed Packages
Name : qemu-kvm
Epoch : 15
Version : 5.2.0
Release : 16.el8
Architecture : x86_64
Size : 0.0
Source : qemu-kvm-5.2.0-16.el8.src.rpm
Repository : @System
From repo : ovirt-4.4-advanced-virtualization
[root@rocky1 ~]# grep -A2 ovirt-4.4-advanced-virtualization
/etc/yum.repos.d/ovirt-4.4-dependencies.repo
[ovirt-4.4-advanced-virtualization]
name=Advanced Virtualization packages for $basearch
mirrorlist=
http://mirrorlist.centos.org/?arch=$basearch&release=8&repo=virt-...
So oVirt is ready to rock on Rocky with little help from Centos :-)
I'm not sure about the future of the ovirt-4.4-advanced-
virtualization
repository after Centos 8 will be discontinued, so this does not look
like production ready yet.
The advanced virtualization packages are likely needed by other
virtualization
systems (openstack, proxmox, ...) or anyone that wants to consume the
latest
features from libvirt and qemu, so packing it in oVirt is not the
right solution.
Nir
So some good news on the adv. virt front -- My colleague Louis has
informed me that the module is actually already staged for build &
import in Distrobuild with some passing builds in Koji & MBS.
https://distrobuildstg.rockylinux.org/packages/3424
I have no ETA on when those will be available in repos, and is 110%
being put back until we have Secure Boot completed, but it's a start!
You can see the MBS link in the Builds column for logs & info from our
MBS instance, and r8-stream-rhel is a link to the RPM sources in our
Gitlab.
Good progress!
If someone would go ahead and verify that the package versions in here
match what oVirt needs, that'd give us some sense of assurance that
we're poking the right bear, so to speak haha
--
- Hayden, Rocky Team Lead
9:19 a.m.
On 7/12/21 2:11 AM, Nir Soffer wrote:
On Mon, Jul 12, 2021 at 1:50 AM Branimir Pejakovic
<branimirp(a)gmail.com> wrote:
> It was a fresh install of 2 VMs on top of VirtualBox with Rocky fully updated on both
prior to oVirt installation. I installed it yesterday and followed the usual way of
installing it: https://www.ovirt.org/download/alternate_downloads.html.
>
> Here are the oVirt packages that are installed on the hypervisor:
Unfortunately vdsm (the core package for ovirt host) does not
have ovirt-prefix. Which version do you have?
...
> ovirt-imageio-client-2.2.0-1.el8.x86_64
This package requires qemu-img >= 5.2.0
Maybe the requirement is broken (missing epoch).
As you quoted, the requirement
states:
%if 0%{?rhel} >= 8
%if 0%{?centos}
Rocky linux probably doesn't have these macros.
OTOH 'ovirt-host' package requires plain 'libvirt',
no version limitations, and that probably sucks in "any 'qemu-kvm'
possible".
Regards, Marcin
What does "qemu-img --version" tell?
Nir
_______________________________________________
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/FGKGSVRMFVE...
2:18 p.m.
On Tue, Jul 13, 2021 at 4:19 PM Marcin Sobczyk <msobczyk(a)redhat.com> wrote:
On 7/12/21 2:11 AM, Nir Soffer wrote:
> On Mon, Jul 12, 2021 at 1:50 AM Branimir Pejakovic <branimirp(a)gmail.com>
wrote:
>> It was a fresh install of 2 VMs on top of VirtualBox with Rocky fully updated on
both prior to oVirt installation. I installed it yesterday and followed the usual way of
installing it: https://www.ovirt.org/download/alternate_downloads.html.
>>
>> Here are the oVirt packages that are installed on the hypervisor:
> Unfortunately vdsm (the core package for ovirt host) does not
> have ovirt-prefix. Which version do you have?
> ...
>> ovirt-imageio-client-2.2.0-1.el8.x86_64
> This package requires qemu-img >= 5.2.0
> Maybe the requirement is broken (missing epoch).
As you quoted, the requirement states:
%if 0%{?rhel} >= 8
%if 0%{?centos}
Rocky linux probably doesn't have these macros.
OTOH 'ovirt-host' package requires plain 'libvirt',
no version limitations, and that probably sucks in "any 'qemu-kvm'
possible".
I expect "rhel" to be available on every rhel-like distro but centos is
most likely not available.
So we expect to use the rhel branch:
# 4.4, AV 8.4 - https://bugzilla.redhat.com/1948532
Requires: qemu-kvm >= 15:5.2.0-15.module+el8.4.0+10650+50781ca0
And this should fail if only qemu-kvm 4.2.0 is available.
I could reproduce this strange behavior, even when qemu 5.2.0
is available:
1. Remove host from engine
2. dnf remove vdsm-\* qemu-\* libvirt-\*
3. dnf install qemu-img-4.2.0
(I needed this for testing imageio patch)
4. dnf install vdsm vdsm-client
And I ended with qemu-kvm 4.2.0 instead of 5.2.0.
5. dnf update
qemu-kvm was updated to 5.2.0.
I hope that someone community can help to resolve this issue.
vdsm patches can be sent using gerrit, please see:
https://github.com/oVirt/vdsm/blob/master/README.md#submitting-patches
Nir
1:56 p.m.
I've been giving this a look and it seems that we aren't building the
advanced virt modules because CentOS builds them from upstream?
I've found no mention of them in their Pagure, and they're built on
their Community Build System via a SIG, with the metadata set on them
as `Extra: {'source': {'original_url': 'libvirt-7.0.0-
14.1.el8.src.rpm'}}`.
My colleague Neil looked into it, and concluded it seems to be a CLI
build being manually run(?).
We could investigate building that, but I'm not sure how good we'd be
to do so as it would likely involve repackaging straight from RHEL
sources via a RHEL machine.
Anyway, happy to help in any way I can on this, I'm in our
SIG/Virtualization channel on Mattermost if anyone wants to get to me
easily.
--
- Hayden, Rocky Team Lead
3:59 p.m.
On Mon, Jul 12, 2021 at 8:59 PM Hayden Young via Users <users(a)ovirt.org> wrote:
I've been giving this a look and it seems that we aren't building the
advanced virt modules because CentOS builds them from upstream?
I've found no mention of them in their Pagure, and they're built on
their Community Build System via a SIG, with the metadata set on them
as `Extra: {'source': {'original_url': 'libvirt-7.0.0-
14.1.el8.src.rpm'}}`.
My colleague Neil looked into it, and concluded it seems to be a CLI
build being manually run(?).
We could investigate building that, but I'm not sure how good we'd be
to do so as it would likely involve repackaging straight from RHEL
sources via a RHEL machine.
Anyway, happy to help in any way I can on this, I'm in our
SIG/Virtualization channel on Mattermost if anyone wants to get to me
easily.
Great to hear about that, oVirt needs a stable replacement for Centos.
I hope that Sandro should be able to help with this.
Nir
8:11 a.m.
I've been giving this a look and it seems that we aren't
building the
advanced virt modules because CentOS builds them from upstream?
I've found no mention of them in their Pagure, and they're built on
their Community Build System via a SIG, with the metadata set on them
as `Extra: {'source': {'original_url': 'libvirt-7.0.0-
14.1.el8.src.rpm'}}`.
My colleague Neil looked into it, and concluded it seems to be a CLI
build being manually run(?).
We could investigate building that, but I'm not sure how good we'd be
to do so as it would likely involve repackaging straight from RHEL
sources via a RHEL machine.
Anyway, happy to help in any way I can on this, I'm in our
SIG/Virtualization channel on Mattermost if anyone wants to get to me
easily.
Hi Hayden
If you can do this - the word awesome would be an understatement ;-)
I have been using oVirt for 7 years now and it is a fantastic product (I started using it
when it was 3.1 or 3.4). I am in a similar position as Jason who started this thread. The
main goal of my experiment described above is to see if I can deploy it on bare metal
nodes with Rocky as a hypervisor replacement for CentOS. I actually wanted to convert to
Proxmox but wanted to give oVirt one more chance :)
Thank you.
Kind regards,
Branimir
9:07 a.m.
On 7/13/2021 8:11 AM, Branimir Pejakovic wrote:
> I've been giving this a look and it seems that we aren't
building the
> advanced virt modules because CentOS builds them from upstream?
>
> I've found no mention of them in their Pagure, and they're built on
> their Community Build System via a SIG, with the metadata set on them
> as `Extra: {'source': {'original_url': 'libvirt-7.0.0-
> 14.1.el8.src.rpm'}}`.
>
> My colleague Neil looked into it, and concluded it seems to be a CLI
> build being manually run(?).
>
> We could investigate building that, but I'm not sure how good we'd be
> to do so as it would likely involve repackaging straight from RHEL
> sources via a RHEL machine.
>
> Anyway, happy to help in any way I can on this, I'm in our
> SIG/Virtualization channel on Mattermost if anyone wants to get to me
> easily.
Hi Hayden
If you can do this - the word awesome would be an understatement ;-)
I have been using oVirt for 7 years now and it is a fantastic product (I started using it
when it was 3.1 or 3.4). I am in a similar position as Jason who started this thread. The
main goal of my experiment described above is to see if I can deploy it on bare metal
nodes with Rocky as a hypervisor replacement for CentOS. I actually wanted to convert to
Proxmox but wanted to give oVirt one more chance :)
Thank you.
Kind regards,
Branimir
Thanks, Branimir.
I am really hoping that Sandro and the rest of the oVirt team can help
make this possible for Rocky Linux. It seems like it won't be too
tricky. I've heard offline from a lot of people who would be very
interested in using Rocky Linux for this very purpose, so there's a lot
of interest out there. It would be a huge win for oVirt.
Jason.
8:23 a.m.
On Wed, Jun 30, 2021 at 10:45 AM Jason Keltz <jas(a)yorku.ca> wrote:
I see the 4.4.6 was released in time with RHEL 8.3. I'd like to use
Rocky Linux 8.4 because I believe RHEL has re-enabled mptsas (though I
know still unsupported) from 8.4+ which will make things easier.
Are you sure that's the case? Maybe I'm missing something, but I don't
see any changes to SAS drivers with the EL8.4 kernel:
https://git.centos.org/rpms/kernel/c/116f1376adb4d274cc50b1f4e70010f6bf17...
--
真実はいつも一つ！/ Always, there's only one truth!
11:13 a.m.
On 7/1/2021 8:23 AM, Neal Gompa wrote:
On Wed, Jun 30, 2021 at 10:45 AM Jason Keltz <jas(a)yorku.ca>
wrote:
>
> I see the 4.4.6 was released in time with RHEL 8.3. I'd like to use
> Rocky Linux 8.4 because I believe RHEL has re-enabled mptsas (though I
> know still unsupported) from 8.4+ which will make things easier.
>
Are you sure that's the case? Maybe I'm missing something, but I don't
see any changes to SAS drivers with the EL8.4 kernel:
https://git.centos.org/rpms/kernel/c/116f1376adb4d274cc50b1f4e70010f6bf17...
Hi Neal,
I read that somewhere, but for the LIFE of me, I cannot find the
document where I read it. I then found this reference (which is not
where I originally read this):
https://access.redhat.com/discussions/3722151?page=3
where someone reports that hey installed RHEL8.4 beta , and mptsas was
loaded but with a warning in dmesg:
"[Tue Apr 13 07:23:08 2021] megasas: 07.714.04.00-rh1
[Tue Apr 13 07:23:08 2021] Warning: megaraid_sas 0000:03:00.0
[1000:0079] - this hardware has not undergone testing by Red Hat and
might not be certified. Please consult https://catalog.redhat.com for
certified hardware."
... so maybe I wasn't dreaming after all.
Jason.
1259
days inactive
1272
days old
18 comments
8 participants
participants (8)
-
Branimir Pejakovic -
branimirp＠gmail.com
-
Hayden Young -
Jason Keltz -
Marcin Sobczyk -
Neal Gompa -
Nir Soffer -
Vojtech Juranek