Bug 1445531

Summary:	block upgrade of libvirt if corresponding qemu-kvm or qemu-kvm-rhev is not available
Product:	Red Hat Enterprise Linux 7	Reporter:	Jeff Nelson <jen>
Component:	libvirt	Assignee:	Jiri Denemark <jdenemar>
Status:	CLOSED WONTFIX	QA Contact:	chhu
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.4	CC:	areis, berrange, dyuan, jdenemar, jen, jsuchane, lmen, mrezanin, ovasik, rbalakri, xuzhang, yalzhang, zpeng
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-04 12:34:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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