Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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>
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.
(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 :)
(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.
(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 7Marc-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 8Marc-Andre Lureau
2015-01-06 12:53:47 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 10Marc-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
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 ***