RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1156339 - virt-viewer cannot connect guest with fullscreen mode on 4 monitor
Summary: virt-viewer cannot connect guest with fullscreen mode on 4 monitor
Keywords:
Status: CLOSED DUPLICATE of bug 1076098
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-24 09:01 UTC by CongDong
Modified: 2015-02-10 13:55 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-10 13:55:41 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
virt-viewer and spice log (32.32 KB, text/plain)
2014-10-24 09:01 UTC, CongDong 		no flags Details
screen shot for 4 display (1.03 MB, image/png)
2014-10-24 09:02 UTC, CongDong 		no flags Details
View All

Description CongDong 2014-10-24 09:01:41 UTC 
Created attachment 950276 [details]
virt-viewer and spice log

Description of problem:
virt-viewer cannot connect a spice guest with "-f" on a 4 monitors
machine

Version-Release number of selected component (if applicable):
virt-viewer-0.6.0-10.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. prepare a spice + qxl guest on a 4 monitors machine
2. # virt-viewer $vm -f

Actual results:
Just one virt-viewer window comes out with message:
"Connected to graphic server"

Expected results:
Should connect the guest and open 4 displays with fullscreen.
If the configuration of guest cannot support 4 displays, should
report and error.

Additional info:
No problem if I configure the guest like this:
# virsh edit $vm
<domain type='kvm' id='5' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
  <qemu:commandline>
    <qemu:arg value='-global'/>
    <qemu:arg value='qxl-vga.vgamem_mb=32'/>
  </qemu:commandline>
</domain>
Comment 1 CongDong 2014-10-24 09:02:35 UTC 
Created attachment 950278 [details]
screen shot for 4 display
Comment 3 Jonathon Jongsma 2014-10-24 15:11:14 UTC 
This seems like a bug in the guest. If configuring 4 fullscreen displays does not work, it should fall back to its previous configuration. Which guest were you using? A debug log might help understand what happened on the guest and why it's not reverting to a previous configuration.
Comment 4 CongDong 2014-10-27 01:32:22 UTC 
(In reply to Jonathon Jongsma from comment #3)
> This seems like a bug in the guest. If configuring 4 fullscreen displays
> does not work, it should fall back to its previous configuration. Which
> guest were you using? A debug log might help understand what happened on the
> guest and why it's not reverting to a previous configuration.

Both rhel7.0 and rhel6.6 guest can reproduce this problem.
And which log do you need? I've attached the virt-viewer debug log :)
Comment 5 Jonathon Jongsma 2014-10-27 14:58:41 UTC 
(In reply to CongDong from comment #4)

> Both rhel7.0 and rhel6.6 guest can reproduce this problem.
> And which log do you need? I've attached the virt-viewer debug log :)

Oh, sorry, I missed that.

So, from the log I can see that virt-viewer attempted to set the guest display properly, but it seems that the guest never responded with a MonitorsConfig message. Re-assigning to vdagent.
Comment 6 Uri Lublin 2015-01-05 15:30:05 UTC 
(In reply to CongDong from comment #0)
> Additional info:
> No problem if I configure the guest like this:
> # virsh edit $vm
> <domain type='kvm' id='5'
> xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
> ...
>   <qemu:commandline>
>     <qemu:arg value='-global'/>
>     <qemu:arg value='qxl-vga.vgamem_mb=32'/>
>   </qemu:commandline>
> </domain>

This then seems to me like a configuration issue.
What was the value of qxl-vga.vgamem_mb before you changed it ?
How did you create the VM ?
Can you please attach the output of -- virsh dumpxml $vm ?
Comment 7 Marc-Andre Lureau 2015-01-06 01:49:43 UTC 
I can't reproduce with current 7.1 guest on 7.1 host. I am using
<video>
  <model type='qxl' ram='65536' vram='65536' vgamem='32768' heads='1'/>
</video>

Please try with video settings, and avoid qemu:commandline options. Thanks
Comment 8 Marc-Andre Lureau 2015-01-06 12:53:47 UTC 
moving
Comment 9 CongDong 2015-01-08 05:40:18 UTC 
(In reply to Marc-Andre Lureau from comment #7)
> I can't reproduce with current 7.1 guest on 7.1 host. I am using
> <video>
>   <model type='qxl' ram='65536' vram='65536' vgamem='32768' heads='1'/>
> </video>
> 
> Please try with video settings, and avoid qemu:commandline options. Thanks

Yes, with the video setting, can connect the guest with 4 displays.
I think this is fixed.

BTW, the default size of vgamem is 8192, this is not enough for support 4 monitors.
Do you think libvirt should set the default size to enough for 4 monitors?
Comment 10 Marc-Andre Lureau 2015-01-08 11:46:27 UTC 
(In reply to CongDong from comment #9)
> (In reply to Marc-Andre Lureau from comment #7)
> > I can't reproduce with current 7.1 guest on 7.1 host. I am using
> > <video>
> >   <model type='qxl' ram='65536' vram='65536' vgamem='32768' heads='1'/>
> > </video>
> > 
> > Please try with video settings, and avoid qemu:commandline options. Thanks
> 
> Yes, with the video setting, can connect the guest with 4 displays.
> I think this is fixed.
> 
> BTW, the default size of vgamem is 8192, this is not enough for support 4
> monitors.
> Do you think libvirt should set the default size to enough for 4 monitors?

afaik, qemu has a patch for that already. Moving components for further discussion
Comment 11 Jiri Denemark 2015-02-10 13:55:41 UTC 
The original default for qxl-vga.vgamem was 16 MB, which is apparently not enough for 4 monitors (or even a large resolution on fewer monitors). Thanks to bug 1076098, users can now increase the video memory size in a supported way (no qemu:commandline) in domain XML. I think there's nothing more we could do about this.

*** This bug has been marked as a duplicate of bug 1076098 ***
Note You need to log in before you can comment on or make changes to this bug.