Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
In the past we have had occurrences of libvirt being upgraded while qemu-kvm-rhev was not. This results in untested, unsupported configurations and has caused customer issues. The most recent example is a customer upgrade from RHEL-7.2 to RHEL-7.3: libvirt from RHEL-7.3 was installed, but qemu-kvm-rhev was not, leaving it at RHEL-7.2.
The goal of this BZ is to prevent customers from accidentally creating or upgrading their systems into configurations that are unsupported.
Perhaps one way is to block the libvirt installation if the corresponding qemu-kvm or qemu-kvm-rhev is unavailable. One associate suggests this may be possible using specfile "Conflicts" directives. For example, the libvirt specfile for RHEL-7.4 could contain something like this:
Conflict any qemu-kvm < qemu-kvm-1.5.3
Conflict any qemu-kvm-rhev < qemu-kmv-rhev-2.9.0
Version-Release number of selected component (if applicable):
How reproducible:
100%
Steps to Reproduce:
1. Install RHEL-7.3 libvirt and RHEL-7.2 qemu-kvm-rhev (2.3.0)
2. Try running a virtual machine
Actual results:
Installation succeeds, but virtual machine fails to run.
Expected results:
Installation at step 1 should have failed.
Additional info:
This won't really help much. Even if the required new qemu-kvm(-rhev) is installed, existing domains will still be running with the old version of QEMU.
Are we trying to avoid an existing problem with this or is this just a theoretical exercise? AFAIK even partial upgrades from RHEL-x.y to RHEL-x.y+n are not supported and yet very few packages actually try to prevent users from doing it. I think it only makes sense if there is a real issue resulting from a mixed environment.
I tend to agree we shouldn't do this. Libvirt is expected to work against both the old & new QEMU, and if it didn't that would itself be considered a bug in libvirt we would aim fix.
Jiri writes:
>This won't really help much. Even if the required new qemu-kvm(-rhev) is >installed, existing domains will still be running with the old version of QEMU.
I gave you a bad example on how to reproduce the problem. Here is a better one.
1. Install RHEL-7.2 including libvirt
2. Install qemu-kvm-rhev from the RHEL-7.2 timeframe
(qemu-kvm-rhev-2.3.0-31.el7 up to qemu-kvm-rhev-2.3.0-31.el7_2.25)
3. Create and start a virtual machine
4. Upgrade RHEL to RHEL-7.3
5. Restart the virtual machine
Actual results: guest fails to restart, reports problem with "arat" flag.
>Are we trying to avoid an existing problem with this or is this just
>a theoretical exercise? AFAIK even partial upgrades from RHEL-x.y to
>RHEL-x.y+n are not supported and yet very few packages actually try
>to prevent users from doing it. I think it only makes sense if there
>is a real issue resulting from a mixed environment.
This is not a theoretical issue, it is a real problem. See BZ 1371617.
(In reply to Daniel Berrange from comment #2)
> I tend to agree we shouldn't do this. Libvirt is expected to work against
> both the old & new QEMU, and if it didn't that would itself be considered a
> bug in libvirt we would aim fix.
I agree with you in the context of upstream, but downstream this is not supported, not tested by QE and, as Jeff pointed out in the previous two comments, results(ed) in bad customer experience in the field.
I've seen resistance to the change being proposed, but no real reasons why it should not be implemented. Is there any technical problem with adding the requirements/conflicts to the package?
See https://bugzilla.redhat.com/show_bug.cgi?id=1456235#c6 for some details how this would not make customer experience much better.
Anyway, as I said in https://bugzilla.redhat.com/show_bug.cgi?id=1456235#c5 I'm not completely against conflicting with old qemu-kvm-rhev to prevent customer from upgrading RHEL underneath a layered product which has not been updated yet as a one-time workaround, but we should really make sure a proper solution is implemented for future releases.
Comment 10Jaroslav Suchanek
2017-12-04 12:34:21 UTC
I am closing this as wont fix.
- downstream patch was rejected
- it brings more troubles that it solves
- error message coming from conflicting rpm update would not really help customer to identify what is wrong
- handling one of many libvirt's dependencies this way is not a solution for the real problem
- issues have to be addressed at their primary source