Bug 2149022
Summary: | qemu-kvm: Missing dependencies between devices | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | Andrea Bolognani <abologna> | |
Component: | qemu-kvm | Assignee: | Miroslav Rezanina <mrezanin> | |
qemu-kvm sub component: | General | QA Contact: | Guo, Zhiyi <zhguo> | |
Status: | CLOSED ERRATA | Docs Contact: | ||
Severity: | unspecified | |||
Priority: | unspecified | CC: | berrange, bfu, coli, gveitmic, jinzhao, juzhang, lijin, lpivarc, virt-maint, ymankad | |
Version: | 9.1 | Keywords: | Triaged | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | qemu-kvm-7.2.0-1.el9 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 2150210 (view as bug list) | Environment: | ||
Last Closed: | 2023-05-09 07:20:55 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: | ||||
Bug Depends On: | ||||
Bug Blocks: | 2150210 |
Description
Andrea Bolognani
2022-11-28 15:34:31 UTC
> Manually installing the qemu-kvm-device-display-virtio-gpu package
> makes the issue go away, but since virtio-gpu is apparently needed
> for virtio-gpu-pci to work, this dependency should be made explicit
> in the spec file.
Right, instantiating a 'virtio-gpu-pci' device has a hard dependency on instantiating a 'virtio-gpu' device
So we need a 'Requires: qemu-kvm-device-display-virtio-gpu' to be present in the 'qemu-kvm-device-display-virtio-gpu-pci' sub-RPM
Likewise for the -gl / -gl-pci variants.
Most modules don't need such RPM dependencies since they are self-contained. The virtio device modules are special because the virtio transport is pluggable, so the -pci device is an add-on to the generic device.
(In reply to Daniel Berrangé from comment #1) > > Manually installing the qemu-kvm-device-display-virtio-gpu package > > makes the issue go away, but since virtio-gpu is apparently needed > > for virtio-gpu-pci to work, this dependency should be made explicit > > in the spec file. > > Right, instantiating a 'virtio-gpu-pci' device has a hard dependency on > instantiating a 'virtio-gpu' device > > So we need a 'Requires: qemu-kvm-device-display-virtio-gpu' to be present in > the 'qemu-kvm-device-display-virtio-gpu-pci' sub-RPM > > Likewise for the -gl / -gl-pci variants. > > Most modules don't need such RPM dependencies since they are self-contained. > The virtio device modules are special because the virtio transport is > pluggable, so the -pci device is an add-on to the generic device. Thanks for clarification, Daniel. I miss-read Andrea's report and not realize the problem is between modules subpackages and not in core subpackage. I'll prepare fix for this. Working on this revealed the we do not provide *-gl devices as they are not compiled. So instead of adding the dependency we are going to remove the *-gl packages. Is this ok, Yash? (In reply to Miroslav Rezanina from comment #3) > Working on this revealed the we do not provide *-gl devices as they are not > compiled. So instead of adding the dependency we are going to remove the > *-gl packages. > > Is this ok, Yash? Hi Mirek, As they were not being compiled, no one could have been using them. I don't remember seeing any cases for missing -gl packages or gl support. So, from my perspective, they are good to be dropped. Asking Germano to review just in case he has seen any customers / Layered products requesting this. I don't think a customer can hit this. Seems this could be more of a problem when generating the container image and not RPM dependencies? So RHEL 9.1 uses uses 7.0 qemu, not 7.1. And I cannot reproduce this, while not exactly what was suggested in comment #1, the dependency is there: # rpm -q --whatrequires qemu-kvm-device-display-virtio-gpu qemu-kvm-7.0.0-13.el9.x86_64 # rpm -q --whatrequires qemu-kvm-device-display-virtio-gpu-pci qemu-kvm-7.0.0-13.el9.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 9.1 (Plow) If I try to remove qemu-kvm-device-display-virtio-gpu[-pci] then the whole thing, including qemu-kvm, is removed as a dependency. This dependency should be the one here: https://gitlab.com/redhat/centos-stream/src/qemu-kvm/-/blob/0ecc97f29e3689f80f41a87a86f705acf8252133/.distro/qemu-kvm.spec#L115, which is used here https://gitlab.com/redhat/centos-stream/src/qemu-kvm/-/blob/0ecc97f29e3689f80f41a87a86f705acf8252133/.distro/qemu-kvm.spec#L335 Isn't it a problem when building the container image actually, ignoring dependencies? Not sure how a customer can hit it, and LPs have complete control over the libvirt XML and we don't support qemu command line or using container images for virtual machines (outside of LPs - and we only support downstream images). Unless this is going to show up in 9.2+ or 10+ without using container images I don't think we need to care much about it. And LPs using images (CNV/OSP) should take care and test their images to ensure it has all the RPMs required for the features they support. (In reply to Germano Veit Michel from comment #5) > I don't think a customer can hit this. Seems this could be more of a problem > when generating the container image and not RPM dependencies? > > So RHEL 9.1 uses uses 7.0 qemu, not 7.1. > > And I cannot reproduce this, while not exactly what was suggested in comment > #1, the dependency is there: > > # rpm -q --whatrequires qemu-kvm-device-display-virtio-gpu > qemu-kvm-7.0.0-13.el9.x86_64 > # rpm -q --whatrequires qemu-kvm-device-display-virtio-gpu-pci > qemu-kvm-7.0.0-13.el9.x86_64 > # cat /etc/redhat-release > Red Hat Enterprise Linux release 9.1 (Plow) > > If I try to remove qemu-kvm-device-display-virtio-gpu[-pci] then the whole > thing, including qemu-kvm, is removed as a dependency. Note that there's a difference between the qemu-kvm and qemu-kvm-core packages. The former provides a full-featured QEMU installation, while the latter contains just the basics and allows you to choose how much functionality you want to add on top. KubeVirt, for example, only needs the virtio-gpu and usb-redirect devices, which means that it can avoid installing qemu-kvm-audio-pa qemu-kvm-block-curl qemu-kvm-block-rbd qemu-kvm-block-ssh qemu-kvm-device-display-virtio-vga qemu-kvm-device-usb-host qemu-kvm-ui-egl-headless qemu-kvm-ui-opengl and all their dependencies for a much smaller disk and security footprint. This kind of fine-grained installation is exactly what this bug is all about. Setups where the qemu-kvm package is installed are, as you correctly point out, unaffected. (In reply to Andrea Bolognani from comment #6) > Note that there's a difference between the qemu-kvm and qemu-kvm-core > packages. The former provides a full-featured QEMU installation, > while the latter contains just the basics and allows you to choose > how much functionality you want to add on top. Ahh thank you! You just had qemu-kvm-core, I missed that from comment #0. > KubeVirt, for example, only needs the virtio-gpu and usb-redirect > devices, which means that it can avoid installing > > qemu-kvm-audio-pa > qemu-kvm-block-curl > qemu-kvm-block-rbd > qemu-kvm-block-ssh > qemu-kvm-device-display-virtio-vga > qemu-kvm-device-usb-host > qemu-kvm-ui-egl-headless > qemu-kvm-ui-opengl Yes, but this is all shipped in a container image (virt-launcher) created by us so customers won't be hit. Same for OSP. > This kind of fine-grained installation is exactly what this bug is > all about. Setups where the qemu-kvm package is installed are, as you > correctly point out, unaffected. Indeed, but this fine-grained installation would not affect customers. We have 1) RHEL KVM RHEL8 Docs: dnf module install virt RHEL9 Docs: dnf install qemu-kvm libvirt virt-install virt-viewer 2) RHV Manages the packages on the host itself, installs qemu-kvm 3) OSP Uses Red Hat provided container image 4) OCP-V Uses Red Hat provided container image So hitting this would really be a corner sub-case of 1 when one is not following the documentation on purpose and looking for a specific setup that does not fall into the main 4 categories above. Should be really rare. And in that case the newly added dependency fixes it. I don't think its worth to KCS this for customers, never seen it on RHEL or any LP - and it would be really weird on LP if it exposes a feature but never shipped the required package, means no testing at all, so I doubt it would happen. But I can do one if you all disagree. (In reply to Germano Veit Michel from comment #7) > this fine-grained installation would not affect customers. We > have > > 1) RHEL KVM > RHEL8 Docs: dnf module install virt > RHEL9 Docs: dnf install qemu-kvm libvirt virt-install virt-viewer > > 2) RHV > Manages the packages on the host itself, installs qemu-kvm > > 3) OSP > Uses Red Hat provided container image > > 4) OCP-V > Uses Red Hat provided container image > > So hitting this would really be a corner sub-case of 1 when one is not > following the documentation on purpose and looking for a specific setup that > does not fall into the main 4 categories above. > Should be really rare. > > And in that case the newly added dependency fixes it. I don't think its > worth to KCS this for customers, never seen it on RHEL or any LP - and it > would be really weird on LP if it exposes a feature but never shipped the > required package, means no testing at all, so I doubt it would happen. But I > can do one if you all disagree. Sorry, what's KCS again? I agree with you that the issue will be rarely, if ever, be hit by customers. It has impacted at least upstream KubeVirt though. Honestly I'm unclear on whether you are opposed to applying the fix? Or are you just arguing that the impact is going to be minimal? Because I agree with that assessment. Either way, I think Yash wanted you to confirm that it's okay for us to drop the (currently empty) qemu-kvm-device-display-virtio-gpu-gl* packages. Which is not what the bug report was initially about, just something that Mirek discovered in the process of addressing it. (In reply to Andrea Bolognani from comment #9) > Sorry, what's KCS again? Knowledge article for end customers to warn about the missing dependency and the removed package. > > I agree with you that the issue will be rarely, if ever, be hit by > customers. It has impacted at least upstream KubeVirt though. > > Honestly I'm unclear on whether you are opposed to applying the fix? > Or are you just arguing that the impact is going to be minimal? > Because I agree with that assessment. > > Either way, I think Yash wanted you to confirm that it's okay for us > to drop the (currently empty) qemu-kvm-device-display-virtio-gpu-gl* > packages. Which is not what the bug report was initially about, just > something that Mirek discovered in the process of addressing it. No no, sorry. I'm in favour of both. I just don't think its useful to initiate anything on the CEE side because of this, we have not seen any customers and a KCS probably won't help anyone. For LPs, both RHV and OCP-V are on RHEL8 so not a concern. But it would be nice to confirm we won't break anything with yum upgrades on RHEL9 KVM and any OSP17 container image (which just moved to 9.0 AFAIK) with these changes. QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass. Check point for 8c6834fe(Remove opengl display device subpackages): When installing qemu-kvm-7.1.0-6.el9.x86_64, the dependent packages will be installed has prefix qemu-kvm are: qemu-kvm-tools-7.1.0-6.el9.x86_64 qemu-kvm-common-7.1.0-6.el9.x86_64 qemu-kvm-core-7.1.0-6.el9.x86_64 qemu-kvm-audio-pa-7.1.0-6.el9.x86_64 qemu-kvm-block-rbd-7.1.0-6.el9.x86_64 qemu-kvm-device-display-virtio-gpu-7.1.0-6.el9.x86_64 qemu-kvm-device-display-virtio-gpu-gl-7.1.0-6.el9.x86_64 qemu-kvm-device-display-virtio-gpu-pci-7.1.0-6.el9.x86_64 qemu-kvm-device-display-virtio-gpu-pci-gl-7.1.0-6.el9.x86_64 qemu-kvm-device-display-virtio-vga-7.1.0-6.el9.x86_64 qemu-kvm-device-display-virtio-vga-gl-7.1.0-6.el9.x86_64 qemu-kvm-device-usb-host-7.1.0-6.el9.x86_64 qemu-kvm-device-usb-redirect-7.1.0-6.el9.x86_64 qemu-kvm-docs-7.1.0-6.el9.x86_64 qemu-kvm-ui-opengl-7.1.0-6.el9.x86_64 qemu-kvm-ui-egl-headless-7.1.0-6.el9.x86_64 qemu-kvm-7.1.0-6.el9.x86_64 Now when installing qemu-kvm-7.2.0-2.el9.x86_64, the dependent packages will be installed has prefix qemu-kvm are: qemu-img x86_64 17:7.2.0-2.el9 beaker-AppStream 2.3 M qemu-kvm-audio-pa x86_64 17:7.2.0-2.el9 beaker-AppStream 73 k qemu-kvm-block-rbd x86_64 17:7.2.0-2.el9 beaker-AppStream 78 k qemu-kvm-common x86_64 17:7.2.0-2.el9 beaker-AppStream 653 k qemu-kvm-core x86_64 17:7.2.0-2.el9 beaker-AppStream 4.0 M qemu-kvm-device-display-virtio-gpu x86_64 17:7.2.0-2.el9 beaker-AppStream 83 k qemu-kvm-device-display-virtio-gpu-pci x86_64 17:7.2.0-2.el9 beaker-AppStream 68 k qemu-kvm-device-display-virtio-vga x86_64 17:7.2.0-2.el9 beaker-AppStream 69 k qemu-kvm-device-usb-host x86_64 17:7.2.0-2.el9 beaker-AppStream 82 k qemu-kvm-device-usb-redirect x86_64 17:7.2.0-2.el9 beaker-AppStream 87 k qemu-kvm-docs x86_64 17:7.2.0-2.el9 beaker-AppStream 1.1 M qemu-kvm-tools x86_64 17:7.2.0-2.el9 beaker-AppStream 533 k qemu-kvm-ui-egl-headless x86_64 17:7.2.0-2.el9 beaker-AppStream 68 k qemu-kvm-ui-opengl x86_64 17:7.2.0-2.el9 beaker-AppStream 74 k qemu-pr-helper x86_64 17:7.2.0-2.el9 beaker-AppStream 471 k All xxx-gl packages are gone Try to install qemu-kvm-device-display-virtio-gpu-gl will prompt cannot find such package: # yum install qemu-kvm-device-display-virtio-gpu-gl No match for argument: qemu-kvm-device-display-virtio-gpu-gl Error: Unable to find a match: qemu-kvm-device-display-virtio-gpu-gl Checkpoint for 0ecc97f2(spec: Add requires for packages with additional virtio-gpu variants): Check the dependent packages of qemu-kvm-device-display-virtio-gpu-pci-7.1.0-6.el9.x86_64: # yum deplist qemu-kvm-device-display-virtio-gpu-pci package: qemu-kvm-device-display-virtio-gpu-pci-17:7.1.0-6.el9.x86_64 dependency: libc.so.6(GLIBC_2.2.5)(64bit) provider: glibc-2.34-54.el9.x86_64 dependency: qemu-kvm-common(x86-64) = 17:7.1.0-6.el9 provider: qemu-kvm-common-17:7.1.0-6.el9.x86_64 Check the dependent packages of qemu-kvm-device-display-virtio-gpu-pci-7.2.0-2.el9.x86_64: # yum deplist qemu-kvm-device-display-virtio-gpu-pci package: qemu-kvm-device-display-virtio-gpu-pci-17:7.2.0-2.el9.x86_64 dependency: libc.so.6(GLIBC_2.2.5)(64bit) provider: glibc-2.34-54.el9.x86_64 dependency: qemu-kvm-common(x86-64) = 17:7.2.0-2.el9 provider: qemu-kvm-common-17:7.2.0-2.el9.x86_64 provider: qemu-kvm-common-17:7.2.0-2.el9.x86_64 dependency: qemu-kvm-device-display-virtio-gpu = 17:7.2.0-2.el9 provider: qemu-kvm-device-display-virtio-gpu-17:7.2.0-2.el9.x86_64 provider: qemu-kvm-device-display-virtio-gpu-17:7.2.0-2.el9.x86_64 We can see qemu-kvm-device-display-virtio-gpu has been added as a dependent package of qemu-kvm-device-display-virtio-gpu-pci Hi Boqiao, Can you help to verify 0ecc97f2(spec: Add requires for packages with additional virtio-gpu variants) for device-display-virtio-gpu-ccw? Thanks! Zhiyi This system is not registered with an entitlement server. You can use subscription-manager to register. Last metadata expiration check: 0:04:54 ago on Fri Jan 6 04:55:41 2023. package: qemu-kvm-device-display-virtio-gpu-ccw-17:7.2.0-2.el9.s390x dependency: libc.so.6(GLIBC_2.2)(64bit) provider: glibc-2.34-54.el9.s390x dependency: qemu-kvm-common(s390-64) = 17:7.2.0-2.el9 provider: qemu-kvm-common-17:7.2.0-2.el9.s390x dependency: qemu-kvm-device-display-virtio-gpu = 17:7.2.0-2.el9 provider: qemu-kvm-device-display-virtio-gpu-17:7.2.0-2.el9.s390x As the test result, it's added Thanks Boqiao! Verified this bug per comment 14 and comment 16 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: qemu-kvm security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:2162 |