Hide Forgot
Created attachment 1237854 [details] virt-manager-screenshot Description of problem: Virt-viewer cannot connect to guest when graphics listen type is network. Remote-viewer works well with same configurations. Version-Release number of selected component (if applicable): libvirt-0.10.2-62.el6.x86_64 virt-viewer-2.0-18.el6.x86_64 virt-manager-0.9.0-33.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. define a guest like following : # virsh dumpxml r62 | grep graphics -A 3 ...... <graphics type='spice' autoport='yes'> <listen type='network' network='default'/> </graphics> 2. start guest, using virt-viewer to connect the guest #virsh start r62 #virt-viewer r62 it will report an error: Failed to connect: Display can only be attached through libvirt with --attach #virt-viewer r62 --attach report same error as above. 3. check domain xml # virsh dumpxml r62 | grep graphics -A 9 <graphics type='spice' port='5900' autoport='yes'> <listen type='network' address='192.168.122.1' network='default'/> </graphics> using remote-viewer to connect as following, it can connect successfully # remote-viewer spice://192.168.122.1:5900 ... Actual results: With configurations in guest xml as step 1, both virt-manager and virt-viewer cannot connect to guest. Expected results: It can connect to guest successfully. Additional info : 1. on rhel7.3, after starting guest, xml like following: ...... <graphics type='spice' port='5900' autoport='yes' listen='192.168.122.1'> <listen type='network' address='192.168.122.1' network='default'/> </graphics> ...... and virt-viwer works well on rhel7.3. 2. virt-viewer log [root@rhel6 ~]# virt-viewer r62 --debug (virt-viewer:27781): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed (virt-viewer:27781): virt-viewer-DEBUG: connecting ... (virt-viewer:27781): virt-viewer-DEBUG: Opening connection to libvirt with URI <null> (virt-viewer:27781): virt-viewer-DEBUG: Add handle 7 1 0x1af9600 (virt-viewer:27781): virt-viewer-DEBUG: initial connect (virt-viewer:27781): virt-viewer-DEBUG: notebook show status 0x1a90000 (virt-viewer:27781): virt-viewer-DEBUG: virt_viewer_app_set_uuid_string: UUID changed to 021eeb81-27b3-0a23-e1f0-c122bd8de046 (virt-viewer:27781): virt-viewer-DEBUG: No guest-specific fullscreen config, using fallback (virt-viewer:27781): virt-viewer-DEBUG: notebook show status 0x1a90000 (virt-viewer:27781): virt-viewer-DEBUG: Guest r62 is running, determining display (virt-viewer:27781): virt-viewer-DEBUG: Set connect info: (null),(null),(null),-1,(null),(null),(null),0 (virt-viewer:27781): virt-viewer-DEBUG: Guest r62 has a spice display (virt-viewer:27781): virt-viewer-DEBUG: Using direct libvirt connection (virt-viewer:27781): virt-viewer-DEBUG: Error operation virDomainOpenGraphics forbidden for read only access (virt-viewer:27781): virt-viewer-DEBUG: After open connection callback fd=-1 (virt-viewer:27781): virt-viewer-DEBUG: Dispatch handler 7 1 0x1af9600 (virt-viewer:27781): virt-viewer-DEBUG: Dispatch handler 7 2 0x1af9600 (virt-viewer:27781): virt-viewer-DEBUG: Dispatch handler 7 1 0x1af9600 (virt-viewer:27781): virt-viewer-DEBUG: Dispatch handler 7 2 0x1af9600 (virt-viewer:27781): virt-viewer-DEBUG: Remove handle 1 7 (virt-viewer:27781): virt-viewer-DEBUG: Disposing window 0x1a4f510
Can you please say a little bit more about the reason for moving it? Thanks I see that the screenshot is from virt-manager " Error operation virDomainOpenGraphics forbidden for read only access" I don't know why it is a read only access ^
> With configurations in guest xml as step 1, both virt-manager and virt-viewer cannot connect to guest. So it seems one bug is used to report the same problem in two different apps :-( I'll clone this to virt-manager too, and leave this one to track virt-viewer fix.
(In reply to Pavel Grunt from comment #2) > Can you please say a little bit more about the reason for moving it? Thanks Apparently virt-viewer and virt-manager are not able to properly get the IP address from the XML when the domain is configured with <listen type="network" .../> and try to use virDomainOpenGraphics instead. virDomainOpenGraphics fails, but the failure is not a bug. The API should not have been used in this case and that's what needs to be fixed.
Yep, that's likely, faulty code is probably https://git.fedorahosted.org/cgit/virt-viewer.git/tree/src/virt-viewer.c#n503
Yes, the thing is that "listen" attribute of "graphics" element is available only for <listen type='address'>, but in case of <listen type='network'> the "listen" attribute is not set and "address" attribute of "listen" element must be used: <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'> <listen type='address' address='127.0.0.1'/> </graphics> <graphics type='spice' port='5900' autoport='yes'> <listen type='network' network='default' address='192.168.122.1'/> </graphics> In general, the "listen" attribute is only for backward compatibility and if libvirt supports "listen" element the "listen" attribute shouldn't be used at all.
Thanks for the explanation!
socket has same problem as "listen". <graphics type='vnc' socket='/var/lib/libvirt/qemu/domain-5-rhel7.2/vnc.sock'> <listen type='socket' socket='/var/lib/libvirt/qemu/domain-5-rhel7.2/vnc.sock'/> </graphics> <graphics type='spice'> <listen type='socket' socket='/var/lib/libvirt/qemu/domain-1-fedora25-workstation/spice.sock'/> <image compression='off'/> </graphics>
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. The official life cycle policy can be reviewed here: http://redhat.com/rhel/lifecycle This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: https://access.redhat.com/