<div dir="ltr"><div dir="ltr">On Wed, Aug 5, 2020 at 4:19 AM Andrea Bolognani <<a href="mailto:abologna@redhat.com">abologna@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2020-08-05 at 02:09 -0400, Mark Mielke wrote:<br>> In testing qemu-5.1rc2 on my Fedora 32 home system, I found that<br>
> the Fedora rawhide package has broken out both the QXL display<br>
> device and the USB redirect device into separate RPM modules:<br>
> <br>
> qemu-device-display-qxl.x86_64         2:5.1.0-0.1.rc2.fc32<br>
> qemu-device-usb-redirect.x86_64        2:5.1.0-0.1.rc2.fc32<br>
> <br>
> The upgrade from 5.0.0 to 5.1.0 does not treat these sub-packages<br>
> as mandatory packages, therefore a straight upgrade of packages<br>
> causes these domcapabilities to disappear.<br>
> <br>
> If the user tries to use libvirt after this, then existing domains<br>
> using QXL display device or USB redirect device will fail to start.<br>
> If the user then investigates and realizes that they now need to<br>
> install the above packages separately, they find that qemu-kvm<br>
> recognizes the modules right away, but libvirt does not. This looks<br>
> to be due to the libvirt domcapabilities cache?<br>
I guess we need to start checking the modules directory in addition<br>
to the main QEMU binary, and regenerate capabilities every time its<br>
contents change.<br></blockquote><div><br></div><div>I was wondering if checking /usr/lib64/qemu (the module directory) might be sufficient? Adding or removing content from the modules directory would potentially change the domcapabilities? I don't know if there is a reliable way of determining this directory from libvirt?</div><div><br></div><div>In general - a user might add or remove such packages at any time, and expect it to automatically work. I don't think having a list of modules would be effective, but if just checking the module directory itself worked, that could be the right compromise?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That said, if upgrading QEMU results in losing features, even though<br>
you can recover them through additional steps I would argue that's a<br>
bug in the packaging that should be addressed on the QEMU side.<br></blockquote><div><br></div><div>I had the same thought. However, I'm expecting this will be part of Fedora 33 (not yet out), and the QXL display driver is possibly becoming optional? Within the same release of Fedora, I expect the default module list should be stable, but between releases it might not be? But, what about long-lived major releases like RHEL / CentOS? Or people who "upgrade" from the distro release to the "advanced virtualization" release (RHEL / CentOS 8)? I also would expect functionality which seems pretty default - to stay default, although perhaps it could be a weak package dependency or similar, to permit people to uninstall it?</div><div><br></div><div>They also moved qemu-device-usb-smartcart to optional along with the already mentioned qemu-device-display-qxl and qemu-device-usb-redirect, and I believe this has happened in the past with some of the block device drivers, only I might not use them, so they might not have affected me? I think everything in the module directory is really in scope.</div><div><br></div><div>Thanks,</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">Mark Mielke <<a href="mailto:mark.mielke@gmail.com" target="_blank">mark.mielke@gmail.com</a>><br><br></div></div>