Hide Forgot
Description of problem: virt-manager cannot open graphic of a remote guest with listen='127.0.0.1' after configure spice_password Version-Release number of selected component (if applicable): libvirt-2.0.0-10.el7_3.2.x86_64 virt-manager-1.4.0-2.el7.noarch How reproducible: 100% Steps to Reproduce: 1.Prepare a guest on hostA, with default spice graphic: <graphics type='spice' autoport='yes'/> 2.Start the guest, check its xml by dumpxml: <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'> <listen type='address' address='127.0.0.1'/> </graphics> 3.On hostB, open virt-manager, connect to hostA by adding a remote connection: File -> Add Connection -> Hypervisor(QEMU/KVM) -> Enable "Connect to remote host" -> MEthod(SSH) -> Username (root) -> Hostname(hostA's IP) ->Click 'connect' 4.In virt-manager, double-click the running guest in the remote connection with hostA, open window for the guest, type spice_password and login, check the display. Result: virt-manager can open the graphic of guest normally, user can interact with guest sucessfully. 5.On hostA: Configure spice_password, restart libvirtd. #vim /etc/libvirt/qemu.conf spice_password = "XYZ12345" #service libvirtd restart 6.On hostB: close and reopen virt-manager, connect the connection with hostA, destroy then start the guest again, repeat step4, check the display. 7.On hostA: edit the xml changing listen address to be "listen=0.0.0.0"; On hostB:destroy then start the guest again, repeat step4, check the display. Result: Same as step4. Actual results: 1.In step6, virt-manager cannot open graphic of the guest with listen='127.0.0.1' after configure spice_password, meanwhile even the guests with only vnc graphic cannot be opened too. 2.For log of "virt-manager --debug" and the screenshot of the guest, pls refer to the attachments. Expected results: virt-manager should be able to open the graphic of guest normally, user can interact with guest sucessfully, just as the result in step4. listen address should not affects. Additional info: 1.It exists on both rhel7.3 and rhel6.9. 2.Cannot reproduce by virt-viewer: #virt-viewer -c qemu+ssh://hostB_IP/system guest 3.Cannot reproduce when use virt-manager to open local guest.
Created attachment 1228291 [details] screenshot of the guest which cannot display correctly
Upstream commit: commit b8dccf6aca6ba5e5523749b54cf5040404b5ff26 Author: Pavel Hrdina <phrdina> Date: Tue Feb 7 17:46:25 2017 +0100 virtManager/viewers: fix connection to remote SPICE with password
I can reproduce this issue with package: virt-manager-1.4.0-2.el7.noarch Then try to verify this bug with new build: virt-manager-1.4.1-1.el7.noarch libvirt-3.1.0-2.el7.x86_64 qemu-kvm-rhev-2.8.0-6.el7.x86_64 spice-gtk3-0.33-2.el7.x86_64 Steps: Environment setup: Need 2 hosts: hostA and hostB. 1.Prepare a guest on hostA, with default spice graphic: <graphics type='spice' autoport='yes'/> 2.Start the guest, check its xml by dumpxml: <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'> <listen type='address' address='127.0.0.1'/> <image compression='off'/> </graphics> 3.On hostB, launch virt-manager, connect to hostA by adding a remote connection: File -> Add Connection -> Hypervisor(QEMU/KVM) -> Enable "Connect to remote host" -> Method(SSH) -> Username (root) -> Hostname(hostA's IP) ->Click 'Connect' 4.In virt-manager, double-click the running guest in the remote connection with hostA, open window for the guest, type spice_password and login, check the display. Result: virt-manager can open the graphic of guest normally, user can interact with guest sucessfully. 5.On hostA: Configure spice_password, restart libvirtd. #vim /etc/libvirt/qemu.conf spice_password = "XYZ12345" #service libvirtd restart 6.On hostB: close and reopen virt-manager, connect the connection with hostA, destroy then start the guest again, repeat step4, check the display. Result: virt-manager open graphic of the guest with listen='127.0.0.1' after configure spice_password normally, user can interact with guest sucessfully. So move this bug from ON_QA to VERIFIED.
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://access.redhat.com/errata/RHBA-2017:2072