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.
Bug 1445531 - block upgrade of libvirt if corresponding qemu-kvm or qemu-kvm-rhev is not available
Summary: block upgrade of libvirt if corresponding qemu-kvm or qemu-kvm-rhev is not av...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jiri Denemark
QA Contact: chhu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-25 21:41 UTC by Jeff Nelson
Modified: 2017-12-04 12:34 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-04 12:34:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jeff Nelson 2017-04-25 21:41:17 UTC 
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:
Comment 1 Jiri Denemark 2017-04-26 06:00:40 UTC 
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.
Comment 2 Daniel Berrangé 2017-04-26 10:46:29 UTC 
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.
Comment 3 Jeff Nelson 2017-04-28 01:10:19 UTC 
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.
Comment 5 Ademar Reis 2017-04-28 16:03:25 UTC 
(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?
Comment 6 Jiri Denemark 2017-06-06 10:36:58 UTC 
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 10 Jaroslav 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
Note You need to log in before you can comment on or make changes to this bug.