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.
On Wed, Jun 30, 2021 at 5:45 PM Jason Keltz <jas@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/Packag... 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
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/Packag...
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.
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-op... 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-brochur...
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
On Sat, Jul 10, 2021 at 6:55 PM <branimirp@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
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
On Mon, Jul 12, 2021 at 1:50 AM Branimir Pejakovic <branimirp@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
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
On Tue, Jul 13, 2021 at 2:57 PM Branimir Pejakovic <branimirp@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-dvd... 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-advanced-virtualization 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
On Tue, 2021-07-13 at 21:01 +0300, Nir Soffer wrote:
On Tue, Jul 13, 2021 at 2:57 PM Branimir Pejakovic < branimirp@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-dvd...
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-advanced-virtualization
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
On 7/12/21 2:11 AM, Nir Soffer wrote:
On Mon, Jul 12, 2021 at 1:50 AM Branimir Pejakovic <branimirp@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@ovirt.org To unsubscribe send an email to 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/FGKGSVRMFVED3H...
On Tue, Jul 13, 2021 at 4:19 PM Marcin Sobczyk <msobczyk@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@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
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
On Mon, Jul 12, 2021 at 8:59 PM Hayden Young via Users <users@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
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
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.
On Wed, Jun 30, 2021 at 10:45 AM Jason Keltz <jas@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/116f1376adb4d274cc50b1f4e70010f6bf170f3... -- 真実はいつも一つ！/ Always, there's only one truth!
On 7/1/2021 8:23 AM, Neal Gompa wrote:
On Wed, Jun 30, 2021 at 10:45 AM Jason Keltz <jas@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/116f1376adb4d274cc50b1f4e70010f6bf170f3...
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.
participants (8)
-
Branimir Pejakovic -
branimirp＠gmail.com
-
Hayden Young -
Jason Keltz -
Marcin Sobczyk -
Neal Gompa -
Nir Soffer -
Vojtech Juranek