Created attachment 837537 [details]
log for spice guest

With virt-viewer-0.5.7-3.el7.x86_64
spice+qxl+spicevmc guest also has the same problem.

But if use spice guest, an error dialog will pop out:
Unable to connect to the graphic server localhost:5900

If use a vnc guest, the virt-viewer window just close.
There is no error dialog.

(In reply to CongDong from comment #0)

> After input the password second time, connection failed and a message pop
> out.
> (virt-viewer:25881): Gtk-WARNING **: Attempting to add a widget with type
> VncDisplay to a container of type VirtViewerDisplayVnc, but the widget is
> already inside a container of type VirtViewerDisplayVnc, please use
> gtk_widget_reparent()
> 

This one is unrelated to this bug (do you get asked for a password even if libvirt XML does not have a 'passwd' attribute in the <graphics> node?) and is fixed by upstream commit bffbd2a7e7bc4ddd84e482bfb3489021b65401cf

I've tested this with virt-viewer-0.5.7-2.el7.x86_64 but connecting to a RHEL6 hypervisor ( qemu-kvm-0.12.1.2-2.415.el6_5.3.x86_64 spice-server-0.12.4-6.el6.x86_64 libvirt-0.10.2-29.el6.1.x86_64 ) and connections through qemu+ssh:// work both for spice and vnc.
I don't have yet a RHEL7 on physical hardware in order to test if I can reproduce using a RHEL7 qemu/libvirt.

Still can reproduce with:
virt-viewer-0.5.7-7.el7.x86_64

Both vnc and spice have the problem (as comment 0 and 2)
So update the summary.

What happens is that virt-viewer tries to run 
ssh -l root $remote-ip nc localhost $vncport
and the nc invocation fails (even when run in a local shell) because nc chooses to connect to localhost in ipv6 rather than ipv4.

Changing this to
ssh -l root $remote-ip nc 127.0.0.1 $vncport
or
ssh -l root $remote-ip nc -4 localhost $vncport

Hopefully virt-viewer has enough information from libvirt to decide whether netcat should forward ipv4 or ipv6 from the remote system.

Use the listen ip '127.0.0.1' instead of ''0.0.0.0', virt-viewer could connect guest as above settings. '127.0.0.1' is default setting in guest xml.
And according to comment6, this is a defect bug not a block issue.

After a discussion with danpb,

11:23 < teuf> danpb: do you know if nc localhost $port should figure out by itself to connect to $port using ipv4 or ipv6, or is it up
              to remote-viewer to be more specific than 'localhost' there ?
11:24 < danpb> assuming 'localhost' has mappings for both ipv4 + ipv6 then the code should try both
11:25 < danpb> basically  getaddrinfo() will return multiple results and the application is supposed to try each result in order until
               it successfuly connects or runs out of results to try
11:46 < teuf> danpb: nmap-ncat does not seem to be doing that /o\ they have a 'resolve' function which only keep the first result from
              getaddrinfo
11:46 < teuf> and  ncat -4 -l 8080 + ncat localhost 8080 fails on rhel7/f20 :(
11:47 < teuf> guess I'll move the bug there and see how it goes
11:48 < danpb> teuf: basically this page describes correct usage  http://www.akkadia.org/drepper/userapi-ipv6.html
11:48 < supybot> Title: Userlevel IPv6 Programming Introduction (at www.akkadia.org)
11:48 < danpb> "The most important thing when using getaddrinfo is     to make sure     that all results are used in order.  To stress
               the important words
11:48 < danpb> again: all and order.  Too many (incorrect) programs     only use the first result.  The order in which the results are
               returned is not arbitrary or random.  The results are in     fact sorted."

Reassigning to nmap-ncat, ncat/ncat_core.c:resolve_internal() seems to only keep the first result returned by getaddrinfo. 
Running 'ncat -4 -l 8080' and 'ncat localhost 8080' fails on RHEL7/f20 systems.

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.

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