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.

Bug 1084393

Summary: virt-viewer --direct tries to connect to localhost when remote VM is only listening on 127.0.0.1
Product: Red Hat Enterprise Linux 7 Reporter: Christophe Fergeau <cfergeau>
Component: virt-viewerAssignee: Christophe Fergeau <cfergeau>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: acathrow, dblechte, fidencio, juzhou, lcui, marcandre.lureau, mzhan, tzheng, zsong
Target Milestone: rcKeywords: Reopened
Target Release: 7.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: virt-viewer-2.0-1.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1085216 (view as bug list) Environment:
Last Closed: 2015-11-19 07:34:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1181288    
Bug Blocks: 1085216    

Description Christophe Fergeau 2014-04-04 08:54:47 UTC
This bug is spawned off bug #1079211.

Steps to Reproduce:
I've found bug 730911#4,it points that there are three guest configurations that should be tested,so I tested this scenario.

 1. No listen attribute

      <graphics type='vnc' port='-1' autoport='yes'/>

Scenario 1:
It defaults to 127.0.0.1 test as below:
1.On host A(ip:10.66.5.145),prepare a vnc guest.
# virsh list 
 Id    Name                           State
----------------------------------------------------
 45    demo-vnc                     running

# virsh dumpxml demo-vnc
    <graphics type='vnc' port='-1' autoport='yes'/>

2.On host B(ip:10.66.5.7),use virt-viewer to connect the guest on host A using --direct:
# virt-viewer --direct -c qemu+ssh://10.66.5.145/system demo-vnc

2.1 On host B,if there is no guest running using vnc protocal with port 5900,error will show as:
"Unable to connect to the graphic server 127.0.0.1:5900"

2.2 On host B,if there is a guest running using vnc protocal with port 5900,
# virsh dumpmxl demo
    <graphics type='vnc' port='5900' autoport='no' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>

# virt-viewer --direct -c qemu+ssh://10.66.5.145/system demo-vnc
Then the vm 'demo' on host B will be opened instead of remote guest demo-vnc on host A.

Comment 2 Christophe Fergeau 2014-04-04 09:17:42 UTC
Just like virt_viewer_replace_host() is doing some magic when g_inet_address_get_is_any() is TRUE, in the --direct case we need to detect loopback addresses and error out in this case ( g_inet_address_get_is_loopback() ).

Comment 3 RHEL Program Management 2014-04-16 05:48:11 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 4 Marc-Andre Lureau 2014-07-03 14:08:51 UTC
This looks a lot related to bug 1108523, assigning to Christophe.

Comment 6 Christophe Fergeau 2014-08-06 08:47:05 UTC
I think this is a duplicate, marking it as such.

*** This bug has been marked as a duplicate of bug 1108524 ***

Comment 7 zhoujunqin 2015-03-12 04:58:32 UTC
I can also reproduce this issue on package:
virt-viewer-0.6.0-12.el7.x86_64

Steps:
env:
Prepare 2 hosts

1.On host A(ip:10.66.7.91),prepare a vnc guest.

# virsh list 
 Id    Name                           State
----------------------------------------------------
 2     rhel6.6-ide                    running


# virsh dumpxml rhel6.6-ide   
...
    <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>
...

2.On host B(ip:10.66.4.126),use virt-viewer to connect the guest on host A using --direct:
# virt-viewer --direct -c qemu+ssh://10.66.7.91/system rhel6.6-ide

2.1 On host B,if there is no guest running using vnc protocal with port 5900, check whether guest on remote host can be launched.

Result: "Unable to connect to the graphic server 127.0.0.1:5900"

2.2 On host B, if there is a guest demo running using vnc protocal with port 5900:
# virsh dumpxml win2008r2-x64-qcow2
...
    <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
...
# virt-viewer --direct -c qemu+ssh://10.66.7.91/system rhel6.6-ide
root.7.91's password: 

Result: Then the vm 'win2008r2-x64-qcow2' on host B opened instead of remote guest 'rhel6.6-ide' on host A.

Since bug can also reproduced, and before it closed as a duplicate of bug 1108524 (that bug is about 'qemu+tcp' connection issue), this bug is about 'qemu+ssh' connection issue, they are different, reopened it, please fix it, thanks.

Comment 8 Christophe Fergeau 2015-03-12 10:03:54 UTC
Patch on the mailing list: https://www.redhat.com/archives/virt-tools-list/2015-March/msg00063.html

Comment 13 zhoujunqin 2015-06-17 03:22:48 UTC
I can reproduce this issue as Comment 7 described.

Then try to verify this bug with new build:
virt-viewer-2.0-1.el7.x86_64

steps to verify:
Prepare 2 hosts: A&B

1.On host A, prepare a vnc guest.

# virsh list 
 Id    Name                           State
----------------------------------------------------
 15    cdrom-rhel6u6-x64              running

# virsh dumpxml rhel6.6-snapshot0610-clone
...
    <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>
...


2.On host B,use virt-viewer to connect the guest on host A using --direct:
# virt-viewer --direct -c qemu+ssh://$hostA_ip/system b

2.1 On host B, if there is no guest running using vnc protocal with port 5900,check whether guest on remote host can be launched.

# virt-viewer --direct -c qemu+ssh://10.66.4.227/system rhel6.6-snapshot0610-clone 
root.4.227's password: 

Result: 
After input right password, a dialog window pop up:
Failed to connect: Guest 'rhel6.6-snapshot0610-clone' is not reachable
Then click "Close" button, virt-viewer exit successfully.

2.2 On host B,if there is a guest running using vnc protocal with port 5900:
# virsh dumpxml win7
...
    <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
...
# virt-viewer --direct -c qemu+ssh://$hostA_ip/system rhel6.6-snapshot0610-clone
root.4.227's password: 

Result: same with step2.1.

So move this bug from ON_QA to VERIFIED.

Comment 15 errata-xmlrpc 2015-11-19 07:34:26 UTC
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://rhn.redhat.com/errata/RHBA-2015-2211.html