The bug reproduce with the following packages
libvirt-1.0.5-2.el7.x86_64
virt-viewer-0.5.6-1.el7.x86_64

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.

Reassigning to gtk-vnc, according to: https://bugzilla.redhat.com/show_bug.cgi?id=882110#c3

Figured out a way to fix this in combination with a SPICE server patch to more proactively detect & drop bogus clients.

Solution is described in https://lists.freedesktop.org/archives/spice-devel/2017-January/035201.html

commit 7f4f2fe8da72ed9fef5dd4319e19feb2b4f3d62e
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Thu Jan 26 09:31:40 2017 +0000

    Add workaround to avoid hangs when connecting to SPICE
    
    When used with QEMU at least, both SPICE and VNC live in the same port
    range (5900+). It is thus not entirely uncommon for a user to mistakenly
    connect to a SPICE server with a VNC client, or vica-verca.
    
    When connecting to VNC server with a SPICE client, you quickly get an
    error. This is because the VNC server sends its short greeting and then
    sees the RedLinkMess from the SPICE client, realizes its garbage and
    drops the connection.
    
    When connecting to a SPICE server with a VNC client though, you get an
    indefinite hang. The VNC client is waiting for the VNC greeting, which
    the SPICE server will never send. The SPICE server is waiting for the
    RedLinkMess which the VNC client will never send.
    
    In VNC the protocol starts with the follow data sent:
    
     Server: "RFB 003.008\n"
     Client: "RFB 003.008\n"
    
    This can be tweaked so the client proactively sends the first four
    bytes
    
     Client: "RFB "
     Server: "RFB 003.008\n"
     Client: "003.008\n"
    
    From the VNC server POV, it'll still be receiving the same 12 bytes from
    the client - it just happens that 4 of them might arrive a tiny bit
    earlier than the other 8 of them. IOW nothing should break in the VNC
    server from this change.
    
    The SPICE server, waiting for its RedLinkMess message will see these
    four bytes "RFB " and interpret them as the SPICE magic number. This
    will be invalid and so the SPICE server will drop the connection.
    This avoids the VNC client hanging forever when connecting to a SPICE
    server by mistake.
    
    Signed-off-by: Daniel P. Berrange <berrange@redhat.com>

This requires a corresponding fix in the SPICE server in order to work https://bugzilla.redhat.com/show_bug.cgi?id=1416692

Tested with: 

virt-viewer-5.0-2
libvirt-3.2.0-3

There is still no error message and the VNC display has "Waiting for display 1..." 

The debug output:

[root@dhcp-10-19-63-104 images]# remote-viewer vnc://localhost:5900 --debug
(remote-viewer:29067): virt-viewer-DEBUG: Opening display to vnc://localhost:5900
(remote-viewer:29067): virt-viewer-DEBUG: Guest (null) has a vnc display
(remote-viewer:29067): virt-viewer-DEBUG: After open connection callback fd=-1
(remote-viewer:29067): virt-viewer-DEBUG: Opening connection to display at vnc://localhost:5900
(remote-viewer:29067): virt-viewer-DEBUG: notebook show status 0x5626612fa230
(remote-viewer:29067): virt-viewer-DEBUG: notebook show status 0x5626612fa230
(remote-viewer:29067): virt-viewer-DEBUG: Insert display 0 0x5626610e0660
(remote-viewer:29067): virt-viewer-DEBUG: notebook show status 0x5626612fa230
(remote-viewer:29067): virt-viewer-DEBUG: Allocated 1024x740
(remote-viewer:29067): virt-viewer-DEBUG: Child allocate 1024x640

(remote-viewer:29067): Gtk-WARNING **: Allocating size to VncDisplay 0x5626613ac230 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

spice-server is missing a required patch, see rhbz#1416692

(In reply to Bill Sanford from comment #15)
> Tested with: 
> 
> virt-viewer-5.0-2
> libvirt-3.2.0-3
> 
> There is still no error message and the VNC display has "Waiting for display
> 1..." 

Hopefully this will work as expected with spice-0.12.8-2.el7

Yeah, this version is spice-server-0.12.8-1.el7

I updated the machine with spice-server-0.12.8-2.el7 and I get the same error as the previous version.

Installed RHEL-7.4-20170421.1 and updated spice server to spice-server-0.12.8-2.el7 and completely rebooted VM and machine.

I installed RHEL-7.4-20170426.4 and the command remote-viewer "vnc://localhost:5900 --debug" shows: 

[root@dhcp-10-19-63-104 test]# remote-viewer vnc://127.0.0.1:5900 --debug
(remote-viewer:14526): virt-viewer-DEBUG: Opening display to vnc://127.0.0.1:5900
(remote-viewer:14526): virt-viewer-DEBUG: Guest (null) has a vnc display
(remote-viewer:14526): virt-viewer-DEBUG: After open connection callback fd=-1
(remote-viewer:14526): virt-viewer-DEBUG: Opening connection to display at vnc://127.0.0.1:5900
(remote-viewer:14526): virt-viewer-DEBUG: notebook show status 0x558a27354230
(remote-viewer:14526): virt-viewer-DEBUG: notebook show status 0x558a27354230
(remote-viewer:14526): virt-viewer-DEBUG: Insert display 0 0x558a27136660
(remote-viewer:14526): virt-viewer-DEBUG: notebook show status 0x558a27354230
(remote-viewer:14526): virt-viewer-DEBUG: Allocated 1024x740
(remote-viewer:14526): virt-viewer-DEBUG: Child allocate 1024x640

(remote-viewer:14526): Gtk-WARNING **: Allocating size to VncDisplay 0x558a27406230 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
(remote-viewer:14526): virt-viewer-DEBUG: Not removing main window 0 0x558a27119320
(remote-viewer:14526): virt-viewer-DEBUG: Disconnected
(remote-viewer:14526): virt-viewer-DEBUG: close vnc=0x558a27406230
(remote-viewer:14526): virt-viewer-DEBUG: notebook show status 0x558a27354230
(remote-viewer:14526): virt-viewer-DEBUG: Guest (null) display has disconnected, shutting down
[root@dhcp-10-19-63-104 test]# 

The remote-viewer opens and then closes with no error of not being able to connect to server. The "spice://localhost:5900 --debug" command shows the error message while trying to connect to a VNC server.

I think for now it's expected that no error message is shown.

(In reply to Christophe Fergeau from comment #22)
> I think for now it's expected that no error message is shown.

Can you explain this? 

In https://bugzilla.redhat.com/show_bug.cgi?id=921330#c0 is clearly stated Expected results:
There is error messages shows:Unable to connect to the graphic server vnc://localhost:5900

(In reply to Radek Duda from comment #23)
> (In reply to Christophe Fergeau from comment #22)
> > I think for now it's expected that no error message is shown.
> 
> Can you explain this? 
> 
> In https://bugzilla.redhat.com/show_bug.cgi?id=921330#c0 is clearly stated
> Expected results:
> There is error messages shows:Unable to connect to the graphic server
> vnc://localhost:5900

I know what the bug description is saying, but I think that what is currently implemented is that remote-viewer no longer waits undefinitely for a connection, but exits instead. So this is an improvement, even if this does not fully match what this bug is requesting.

So there's two separate issues here really. This bug addressed the GTK-VNC portion of the fix, which ensures we abort the connection with an error when connecting to SPICE. This is happening, as evidenced by fact that remote-viewer exits, instead of hanging forever.

Separately though, remote-viewer needs fixing to be able to actually report error messages from GTK-VNC. The recently released GTK-VNC introduced a new 'vnc-error' signal that provides the error message, which remote-viewer needs to handle.

I'm putting this back on QA since the GTK-VNC fix is done

Verified that remote-viewer is closed and doesn't hang.

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/RHSA-2017:2258