On 11/13/19 8:22 AM, Martin Kletzander wrote:
On Mon, Oct 07, 2019 at 02:56:11PM +0200, Pavel Mores wrote:
>
> Hi,
>
> I'm looking into fixing
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=1668141
>
> (as a short summary, if a graphics device is added to XML that has no
> video
> device, libvirt automatically adds a video device which is always of type
> 'cirrus' - even if the underlying qemu doesn't support cirrus).
>
> I'm able to affect the behaviour in question by using qemu
> capabilities in
> qemuDomainDeviceVideoDefPostParse(), see proof-of-concept change in
> [1]. I
> have a couple of questions though:
>
> 1) is this a proper place and approach to fix the bug?
I don't think so because the guest ABI could change. Imagine there is an
application that just starts a simple VM (with graphics with no model)
and out
of nowhere (after a long time) they upgrade libvirt and qemu and the VM
will
look differently.
> 2) what would be the full specification of expected behaviour? The
> bug report
> only states that the video type shouldn't be cirrus but doesn't say
> what it
> should be. [2] gives some information about the order of preference
> of video
> device types but I was wondering if there are any opinions about
> this on this
> list?
>
Reading the BZ it looks to me like virt-manager should allow choosing
cirrus and
the different default could be chosen in virt-manager. The BZ is not well
described, to be honest.
My take on the bug was: libvirt shouldn't use a default configuration
that we blatantly know will result in unbootable qemu. So, don't use
cirrus when qemuCaps tells us that the qemu binary definitely doesn't
have cirrus support.
Pavel's v2 series changes the behavior to:
* use cirrus if it's available, so current working behavior is maintained
* if cirrus is unavailable but vga _is_ available, use that. this fixes
the rhel case, but also likely fixes the default for non-x86 archs that
didn't ever have cirrus
* if cirrus and vga aren't available, explicitly error that the user
needs to specify a video model because we didn't find one for them.
Which all sounds good to me.
Thanks,
Cole