Bug 1668141
| Summary: | libvirt can set default video model=cirrus even if qemu doesn't support it | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | zonglin jiang <zjiang> |
| Component: | libvirt | Assignee: | Pavel Mores <pmores> |
| Status: | CLOSED WONTFIX | QA Contact: | Lili Zhu <lizhu> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | chhu, crobinso, dyuan, fjin, jdenemar, jsuchane, lizhu, lmen, pmores, rbalakri, tzheng, xuzhang, yalzhang |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-6.0.0-17.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1668139 | Environment: | |
| Last Closed: | 2020-08-15 05:31:51 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: | 1668139 | ||
| Bug Blocks: | 1746622 | ||
|
Description
zonglin jiang
2019-01-22 03:37:05 UTC
From https://bugzilla.redhat.com/show_bug.cgi?id=1668139#5 > Looks like a libvit bug. qemuDomainDeviceVideoDefPostParse will set a video > model without checking if qemu supports it, despite the fact that > qemuProcessStartValidateVideo later will check qemu capabilities and reject > the cirrus config. > > Kind of a corner case though so not a priority for fixing in 8.0 GA Fixed by d3f2a8bd47 qemu: added tests of the new default video type selection algorithm 33a9757852 qemu: the actual change of default video devide type selection algorithm 4a067e70fa qemu: prepare existing test for change of the default video device type b648d96289 qemu: default video device type selection algoritm moved into its own function v5.9.0-395-gb648d96289 Hi Pavel,
I test with libvirt-6.0.0-17.module+el8.3.0+6423+e4cb6418.x86_64 and qemu-kvm-4.2.0-23.module+el8.3.0+6922+fd575af8.x86_64, libvirt still set 'cirrus' video as the default video. Could you help to check that please?
# virsh domcapabilities | grep -A8 video
<video supported='yes'>
<enum name='modelType'>
<value>vga</value>
<value>cirrus</value>
<value>qxl</value>
<value>virtio</value>
<value>none</value>
<value>bochs</value>
</enum>
</video>
# /usr/libexec/qemu-kvm -device cirrus-vga
qemu-kvm: -device cirrus-vga: warning: 'cirrus-vga' is deprecated, please use a different VGA card instead
Remove video device in guest xml, then check the default video devcie added by libvirt:
#virsh dumpxml vm1 | grep -A5 video
# virsh dumpxml vm1 | grep -A4 video
<video>
<model type='cirrus' vram='16384' heads='1' primary='yes'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
</video>
Hi, if cirrus is supported by an emulator binary - as seems to be the case here (judging from the 'virsh domcapabilities' output that you posted) - then cirrus is still preferred to plain vga (please see also https://bugzilla.redhat.com/show_bug.cgi?id=1668139#c8 and the discussion that follows) so its addition as a default video device is expected and OK. Now, admittedly I'm not sure how to interpret the output of the 'qemu-kvm -device cirrus-vga' command. Is /usr/libexec/qemu-kvm the same binary as the one that 'virsh domcapabilities' outputs capabilities for? In any case my fix relies on QEMU capabilities to decide whether cirrus is supported. So as long as the capabilities indicate that cirrus is indeed supported, it will be used. Hope this helps, please don't hesitate to let me know if it doesn't. (In reply to Pavel Mores from comment #6) > Hi, > > if cirrus is supported by an emulator binary - as seems to be the case here > (judging from the 'virsh domcapabilities' output that you posted) - then > cirrus is still preferred to plain vga (please see also > https://bugzilla.redhat.com/show_bug.cgi?id=1668139#c8 and the discussion > that follows) so its addition as a default video device is expected and OK. > > Now, admittedly I'm not sure how to interpret the output of the 'qemu-kvm > -device cirrus-vga' command. Is /usr/libexec/qemu-kvm the same binary as > the one that 'virsh domcapabilities' outputs capabilities for? > > In any case my fix relies on QEMU capabilities to decide whether cirrus is > supported. So as long as the capabilities indicate that cirrus is indeed > supported, it will be used. > > Hope this helps, please don't hesitate to let me know if it doesn't. But it's not reasonable that libvirt still uses cirrus as default video even when cirrus is supported but deprecated by qemu-kvm。 (In reply to yafu from comment #7) > But it's not reasonable that libvirt still uses cirrus as default video even > when cirrus is supported but deprecated by qemu-kvm。 The intention of the original bug was that libvirt would be changed to not hardcode cirrus usage when we know the qemu binary has cirrus compiled out. I thought that was the case for RHEL8. Turns out cirrus is compiled in, but prints a warning message to the logs that it is deprecated. IMO libvirt is behaving correctly here with respect to libvirt policies. qemu technically provides cirrus support even if in RHEL we don't 'support' it. libvirt in this case will continue to use cirrus when no explicit video model is specified, to maintain config back compat with the way it has always behaved. Changing libvirt to use something else even when cirrus is available is a possibility but it would be a downstream only change and IMO not worth bothering with. The case of a user entering a bare <video> device with no specified model is really a corner case that we shouldn't stress over, all apps that specify <video> are going to fill in a better value here since it requires knowledge of what guest OS is being installed. Because cirrus isn't compiled out in RHEL8 this bug report is more tracking a theoretical issue than a practical one affecting the distro. On those grounds we could just close this and drop it from the errata. Or mark it VERIFIED on those grounds and continue on. But I don't think there's any more work that needs to be done in this area (unless I'm missing something) Based on the grounds mentioned in Comment 8, mark the bug as closed. Please help to drop it from the errata. Thanks Has been dropped from errata Has been dropped from errata |