Bug 795688 - Use vga as the default display adapter in libvirt for QEMU
Summary: Use vga as the default display adapter in libvirt for QEMU
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-21 10:03 UTC by Marko Myllynen
Modified: 2012-02-27 09:35 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 797769 797772 (view as bug list)
Environment:
Last Closed: 2012-02-22 16:57:24 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Marko Myllynen 2012-02-21 10:03:17 UTC
Description of problem:
Libvirt leaves the policy of the default display adapter hardware up to the hypervisor meaning that with QEMU one gets Cirrus instead of vga. However, as can be shown with glxgears vga provides much better FPS rate than Cirrus (these numbers are from RHEL 6.2 host/guest on a Lenovo laptop):

cirrus : 78 FPS
vga    : 260 FPS

Please make vga as the default display adapter in libvirt when using QEMU.

Version-Release number of selected component (if applicable):
RHEL 6.2

Additional info:
With the proposed optimizations in the bugs below the difference is even greater to vga's advantage:

https://bugzilla.redhat.com/show_bug.cgi?id=795685
https://bugzilla.redhat.com/show_bug.cgi?id=795686

Comment 2 Richard W.M. Jones 2012-02-21 10:30:07 UTC
libvirt leaves the policy up to qemu, so make this argument
on the upstream qemu mailing lists first.

Comment 3 Dave Allan 2012-02-22 16:57:24 UTC
Marko, I understand what you're saying, but libvirt explicitly leaves this kind of decision up to either qemu or to management applications using libvirt (e.g., ovirt, virt-manager), so I have to close this as NOTABUG.  I'm sure that there are places where we've failed to follow that rule, but in general we try to honor it.

Comment 4 Eric Blake 2012-02-22 17:38:44 UTC
(In reply to comment #3)
> Marko, I understand what you're saying, but libvirt explicitly leaves this kind
> of decision up to either qemu or to management applications using libvirt
> (e.g., ovirt, virt-manager), so I have to close this as NOTABUG.  I'm sure that
> there are places where we've failed to follow that rule, but in general we try
> to honor it.

That said, we should probably open bugs against virt-install and virt-manager so that default creation of new guests prefers vga where appropriate, rather than deferring to hypervisor defaults.

Comment 5 Marko Myllynen 2012-02-27 09:31:08 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Marko, I understand what you're saying, but libvirt explicitly leaves this kind
> > of decision up to either qemu or to management applications using libvirt
> > (e.g., ovirt, virt-manager), so I have to close this as NOTABUG.  I'm sure that
> > there are places where we've failed to follow that rule, but in general we try
> > to honor it.
> 
> That said, we should probably open bugs against virt-install and virt-manager
> so that default creation of new guests prefers vga where appropriate, rather
> than deferring to hypervisor defaults.

I've now proposed this change in the upstream mailing list:

http://lists.nongnu.org/archive/html/qemu-devel/2012-02/msg03274.html

Per Eric's suggestion I'll clone this bug against virt-install and virt-manager.

Thanks.


Note You need to log in before you can comment on or make changes to this bug.