Bug 1134980 - Should export first vga display with Spice
Summary: Should export first vga display with Spice
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1058625
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-28 14:35 UTC by Marc-Andre Lureau
Modified: 2015-03-05 09:54 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1058625
Environment:
Last Closed: 2015-03-05 09:54:04 UTC


Attachments (Terms of Use)
Xorg.log (8.53 KB, text/plain)
2014-12-12 08:40 UTC, mazhang
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0624 normal SHIPPED_LIVE Important: qemu-kvm-rhev security, bug fix, and enhancement update 2015-03-05 14:37:36 UTC

Description Marc-Andre Lureau 2014-08-28 14:35:12 UTC
+++ This bug was initially created as a clone of Bug #1058625 +++


--- Additional comment from Marc-Andre Lureau on 2014-08-28 10:23:58 EDT ---

The spice assert is solved by the following Spice server patch:

http://lists.freedesktop.org/archives/spice-devel/2013-November/015453.html

However, qemu did not register the vga display channel, so you get a "connected to display" virt-viewer info, but no actual guest display. Let's clone this bug for that.

Comment 1 Marc-Andre Lureau 2014-08-28 14:36:06 UTC
Note that the first display is correctly registered in qemu upstream.

Comment 3 Marc-Andre Lureau 2014-08-28 14:39:30 UTC
Can be reproduced with 'qemu-kvm -spice disable-ticketing,port=5931 -device qxl'

The Spice assert() would not happen if the first display would be exported.

(the assert() is solved in original bug)

Comment 4 Gerd Hoffmann 2014-08-29 08:05:03 UTC
Sounds like a bug 987312 duplicate, please check.

Comment 5 Gerd Hoffmann 2014-10-27 10:01:04 UTC
Moving to qemu-kvm-rhev.  Should have picked up the fix by 2.1 rebase.
Please verify.

Comment 9 mazhang 2014-12-12 03:13:43 UTC
For this bug reproduce:
This bug was clone of bz1058625 which is a spice bug, and component has changed from qemu-kvm to qemu-kvm-rhev, so just use qemu-kvm and old spice could reproduce it.

Here is my test:

Host:
qemu-kvm-1.5.3-83.el7.x86_64
spice-server-0.12.4-6.el7.x86_64

Boot guest with following command line, qemu-kvm aborted.
gdb --args /usr/libexec/qemu-kvm \
-M pc \
-cpu SandyBridge \
-m 2G \
-smp 4,sockets=120,cores=2,threads=1,maxcpus=240 \
-enable-kvm \
-name rhel7 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-rtc base=localtime,clock=host,driftfix=slew \
-nodefaults \
-monitor stdio \
-qmp tcp:0:5555,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-monitor unix:/tmp/monitor0,server,nowait \
-usb \
-device usb-tablet,id=tablet0 \
-global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 \
-serial unix:/tmp/ttyS0,server,nowait \
-monitor unix:/tmp/monitor-unix0,server,nowait \
-netdev tap,id=hostnet0,vhost=on \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:00:B6:40:22,bus=pci.0,addr=0x3 \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \
-drive file=/root/rhel7-64.raw,if=none,id=drive-virtio-disk1,format=raw,cache=none,werror=stop,rerror=stop,aio=native \
-device virtio-blk-pci,scsi=off,bus=pci.0,drive=drive-virtio-disk1,id=virtio-disk1,bus=pci.0,addr=0x6,bootindex=0,ioeventfd=on \
-spice port=5901,disable-ticketing \
-device qxl,id=video1,bus=pci.0,addr=0x7,vram_size=134217728 -device qxl,id=video2,bus=pci.0,addr=0x8,vram_size=134217728 -device qxl,id=video3,bus=pci.0,addr=0x9,vram_size=134217728 -device qxl,id=video4,bus=pci.0,addr=0xa,vram_size=134217728 \


Update qemu to qemu-kvm-rhev-2.1.2-16.el7.x86_64 re-test this bug.

Host:
qemu-kvm-rhev-2.1.2-16.el7.x86_64
3.10.0-213.el7.x86_64
spice-server-0.12.4-8.el7.x86_64

Guest:
3.10.0-213.el7.x86_64

Steps:
1. Boot guest with 4 qxl device.
-spice port=5901,disable-ticketing \
-device qxl,id=video1,bus=pci.0,addr=0x7,vram_size=134217728 -device qxl,id=video2,bus=pci.0,addr=0x8,vram_size=134217728 -device qxl,id=video3,bus=pci.0,addr=0x9,vram_size=134217728 -device qxl,id=video4,bus=pci.0,addr=0xa,vram_size=134217728

2. Connect guest by remote-viewer.

Result:
1. Guest boot up, but spice shows black screen with just a underline flash if set guest graphical mode.
2. Can login guest with text mode.

notice:
The command line without -vga device or -device qxl-vga.

Gerd, If qemu export first vga display to spice, guest display supposed to work.
could you please have a look at this bug if work as expected?

Thanks,
Mazhang.

Comment 10 Gerd Hoffmann 2014-12-12 08:29:06 UTC
> Steps:
> 1. Boot guest with 4 qxl device.
> -spice port=5901,disable-ticketing \
> -device qxl,id=video1,bus=pci.0,addr=0x7,vram_size=134217728 -device
> qxl,id=video2,bus=pci.0,addr=0x8,vram_size=134217728 -device
> qxl,id=video3,bus=pci.0,addr=0x9,vram_size=134217728 -device
> qxl,id=video4,bus=pci.0,addr=0xa,vram_size=134217728
> 
> 2. Connect guest by remote-viewer.
> 
> Result:
> 1. Guest boot up, but spice shows black screen with just a underline flash
> if set guest graphical mode.
> 2. Can login guest with text mode.

Looks like the guest has trouble dealing with that setup.
Can you attach Xorg.log?

Comment 11 mazhang 2014-12-12 08:40:42 UTC
Created attachment 967521 [details]
Xorg.log

Comment 12 Gerd Hoffmann 2014-12-15 07:12:11 UTC
[    25.597] (EE) no screens found(EE)

Yep, that's it.  I think the xorg driver supports qxl-vga only, the multihead mode with secondary qxl devices was only ever used with windows guests.  So I suspect this setup simply lacks guest side support ...

Comment 13 mazhang 2014-12-15 07:51:06 UTC
(In reply to Gerd Hoffmann from comment #12)
> [    25.597] (EE) no screens found(EE)
> 
> Yep, that's it.  I think the xorg driver supports qxl-vga only, the
> multihead mode with secondary qxl devices was only ever used with windows
> guests.  So I suspect this setup simply lacks guest side support ...

Gerd, Is this a configuration problem, How do I setup guest to support qxl devices? if not, should I open a new bz trace it?

Thanks,
Mazhang.

Comment 14 Gerd Hoffmann 2014-12-15 08:15:33 UTC
(In reply to mazhang from comment #13)
> (In reply to Gerd Hoffmann from comment #12)
> > [    25.597] (EE) no screens found(EE)
> > 
> > Yep, that's it.  I think the xorg driver supports qxl-vga only, the
> > multihead mode with secondary qxl devices was only ever used with windows
> > guests.  So I suspect this setup simply lacks guest side support ...
> 
> Gerd, Is this a configuration problem, How do I setup guest to support qxl
> devices? if not, should I open a new bz trace it?

No.  Additional '-device qxl' devs is the old fashioned way to do multihead.  It's deprecated since spice got support for multihead with a single '-device qxl-vga'.

Comment 15 mazhang 2014-12-15 08:27:02 UTC
(In reply to Gerd Hoffmann from comment #14)
> (In reply to mazhang from comment #13)
> > (In reply to Gerd Hoffmann from comment #12)
> > > [    25.597] (EE) no screens found(EE)
> > > 
> > > Yep, that's it.  I think the xorg driver supports qxl-vga only, the
> > > multihead mode with secondary qxl devices was only ever used with windows
> > > guests.  So I suspect this setup simply lacks guest side support ...
> > 
> > Gerd, Is this a configuration problem, How do I setup guest to support qxl
> > devices? if not, should I open a new bz trace it?
> 
> No.  Additional '-device qxl' devs is the old fashioned way to do multihead.
> It's deprecated since spice got support for multihead with a single '-device
> qxl-vga'.

Summary:
1. After update qemu to qemu-kvm-rhev-2.1.2-16.el7.x86_64, qemu-kvm not crash any more.
2. Guest black screen with 4 qxl devices, but qxl device has deprecated.
So the test result was expected, set this bug as verified.
Any problem please let me know.

Thanks,
Mazhang.

Comment 17 errata-xmlrpc 2015-03-05 09:54:04 UTC
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, 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://rhn.redhat.com/errata/RHSA-2015-0624.html


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