Bug 851952 - VNC/TLS to view consoles of remote connections fail
VNC/TLS to view consoles of remote connections fail
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-27 02:49 EDT by Andrew Gillies
Modified: 2012-11-26 17:02 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-26 17:02:30 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
requested guest xml (2.22 KB, application/xml)
2012-10-15 17:34 EDT, Andrew Gillies
no flags Details

  None (edit)
Description Andrew Gillies 2012-08-27 02:49:02 EDT
Description of problem:
Viewing the consoles of remote guests (i.e. guests on remote hosts) fails using VNC over TLS.  In the user virt-manager.log, the messages are:

[Sun, 26 Aug 2012 17:16:31 virt-manager 4914] DEBUG (console:1116) Starting connect process for proto=vnc trans=tls connhost=mangrove connuser=kauri connport=None gaddr=127.0.0.1 gport=5902 gsocket=None
[Sun, 26 Aug 2012 17:16:31 virt-manager 4914] DEBUG (console:412) VNC connection to 127.0.0.1:5902
[Sun, 26 Aug 2012 17:16:31 virt-manager 4914] DEBUG (console:1001) Viewer disconnected

Here, mangrove is a resolvable remote host running a valid libvirtd service over TLS, and kauri is the local machine.  The log shows that gaddr is loopback - this is wrong as the gport is the correct remote port (i.e. on remote mangrove not on localhost).

Note, these same VNC/TLS connections (and certificates) worked on fc16.


Version-Release number of selected component (if applicable):
virt-manager-0.9.4-1.fc17.noarch
virt-manager-common-0.9.4-1.fc17.noarch


How reproducible:
always

Steps to Reproduce:
1. start virt-manager
2. make a connection to remote server
3. open a console on one of the remote guests
  
Actual results:
console reports failed connection

Expected results:
the console should be shown, via VNC/TLS

Additional info:

I have fixed the behaviour by editing /usr/share/virt-manager/virtManager/console.py 
(i.e. remote access to consoles over VNC/TLS now works for me).
However, I do not know the code and I am not a programmer, so would appreciate a more knowledgeable solution.

method get_conn_host() in class ConnectionInfo (line 81 of console.py)

def get_conn_host(self):
  host = self._connhost
  port = self._connport

  if not self.need_tunnel():
    port = self.gport
    if self.gaddr != "0.0.0.0":
      host = self.gaddr

VNC/TLS is not a tunnel, and host is being set to loopback.  Commenting out or changing the last "if" so as it fails, solves the problem for me.
Comment 1 Cole Robinson 2012-10-13 21:49:07 EDT
Hi Andrew, thanks for the psuedo patch! Can you provide the XML of the guest so I can get a better idea of what's going on?

sudo virsh dumpxml $vmname
Comment 2 Andrew Gillies 2012-10-15 17:34:03 EDT
Created attachment 627713 [details]
requested guest xml

I run about 100 guests distributed on 3 remote physical machines.  I have attached the output of 'virsh dumpxml' for one of the guests.

Some of the remote physical machines run Fedora 17, one CentOS 6, but all display OK in the 'patched' version of virt-manager.
Comment 3 Cole Robinson 2012-10-19 12:59:15 EDT
Strange, I don't get why there isn't a listen= address in the XML, libvirt should always put one there.

What settings have you changed in /etc/libvirt/qemu.conf ?

And can you also attach /var/log/libvirt/qemu/$vmname.log for that VM?
Comment 4 Cole Robinson 2012-10-19 12:59:46 EDT
Whoops, forgot to set needinfo. Andrew, please see comment #3
Comment 5 Cole Robinson 2012-11-26 17:02:30 EST
No response for a month, so closing. Andrew, if you can still reproduce, please reopen and provide the info in Comment #3

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