Bug 874698 - [spice - remote viewer] Can't open console to VM on 5.9 host "Unable connect to the graphic server"
[spice - remote viewer] Can't open console to VM on 5.9 host "Unable connect ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer (Show other bugs)
3.0.7
All All
unspecified Severity high
: ---
: 3.2.0
Assigned To: Marc-Andre Lureau
Desktop QE
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-08 12:00 EST by Pavel Stehlik
Modified: 2013-06-10 16:01 EDT (History)
7 users (show)

See Also:
Fixed In Version: mingw-virt-viewer-0.5.3-18.el6ev
Doc Type: Bug Fix
Doc Text:
Previously, when attempting to connect to a 5.9 host using SPICE, the console would occasionally fail with a message saying 'Unable to connect to the graphic server'. Now, 'IN' and 'HUP' events are handled correctly during the protocol version switch, therefore the SPICE console should connect without errors.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-10 16:01:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
vdsm59 (57.21 KB, text/plain)
2012-11-08 12:00 EST, Pavel Stehlik
no flags Details
r-v debug output (21.31 KB, text/plain)
2012-11-27 08:40 EST, David Jaša
no flags Details
another error (4.97 KB, text/plain)
2012-11-27 11:25 EST, David Jaša
no flags Details
yet another error (19.59 KB, text/plain)
2012-11-30 12:45 EST, David Jaša
no flags Details
last patch (4.85 KB, patch)
2012-11-30 14:37 EST, Marc-Andre Lureau
no flags Details | Diff

  None (edit)
Description Pavel Stehlik 2012-11-08 12:00:21 EST
Created attachment 640947 [details]
vdsm59

Description of problem:
 Once I add 5.9 host rhevh-5.9-20121017.2.el5 into ic158.2, I can't open spice console. Console opens, trying to connect & says:  "Unable connect to the graphic server". It looks like remote-viewer is not able to connect to older server.
 Note I have this 'new' version of spice client cause I already connect to RHEVM3.1 from this client.

qemu log on server says:
reds_handle_read_header_done: version mismatch


Actually that's really sad we can't have debug for spice: https://bugzilla.redhat.com/show_bug.cgi?id=767581#c10

Version-Release number of selected component (if applicable):
ic158.1 - wpf, IE8, cluster 2.2 & host 5.9 & Virtual Machine Viewer 0.5.3

How reproducible:
90%


Steps to Reproduce:
1. have above version installed 
2. try to open spice console against 5.9 host
3.
  
Actual results:
I can't open every time console. However 90% as I succeed once to open it.
I can open console on 3.0/3.1 server in 3.0 cluster all the time I want.

Expected results:
Open spice console also on 5.9 host.

Additional info:
vdsm.log as att (contains also qemu part).
Comment 5 Marc-Andre Lureau 2012-11-14 09:27:28 EST
I didn't manage to reproduce.

This bug is strangely close to bug 813889. I would suggest you try to reproduce on Linux and give as much information about your server setup and network as possible. If QA can't reproduce either or if the bug is the same as 813889, we should close or close as duplicate imho.
Comment 7 Vaclav Ehrlich 2012-11-23 10:39:40 EST
> I didn't manage to reproduce.
> 
> This bug is strangely close to bug 813889. I would suggest you try to
> reproduce on Linux and give as much information about your server setup and
> network as possible. If QA can't reproduce either or if the bug is the same
> as 813889, we should close or close as duplicate imho.

Reproduced on:

RHEVM 3.0:
rhevm-backend-3.0.5_0001-5.el6_3.x86_64
rhevm-admin-portal-wpf-3.0-52.el6_2.noarch
rhevm-3.0.5_0001-5.el6_3.x86_64

Host:
RHEV Hypervisor - 5.9 - 20121114.2

Client RHEL6.4:
virt-viewer-0.5.2-16.el6.x86_64

I'm not sure, if the  bug is the same, because I've not found 'reds_handle_read_header_done: version mismatch' in 813889 bug logs.(In reply to comment #5)
Comment 8 Marc-Andre Lureau 2012-11-23 11:51:42 EST
(In reply to comment #7)
> I'm not sure, if the  bug is the same, because I've not found
> 'reds_handle_read_header_done: version mismatch' in 813889 bug logs.(In
> reply to comment #5)

this is a normal message, since the client first attempt to connect with new protocol before chosing the older version.
Comment 9 Marc-Andre Lureau 2012-11-23 11:53:07 EST
(In reply to comment #5)
> I didn't manage to reproduce.
> 
> This bug is strangely close to bug 813889. I would suggest you try to
> reproduce on Linux and give as much information about your server setup and
> network as possible. If QA can't reproduce either or if the bug is the same
> as 813889, we should close or close as duplicate imho.

please try to give more informations, the bug still can't be reproduced on my side
Comment 10 Pavel Stehlik 2012-11-26 06:54:52 EST
Please tell us how to provide more information. The att contains vdsm & qemu output. There's nothing more (ok screenshot will help? I doubt) we can do probably now.
 The environ is 3.0 rhevm (which works with equal client from win). Once you update to client from 3.1 rhevm (remote-viever) you can't open spice. Only message is in attached log.
AFAIK we can't have more details due to  https://bugzilla.redhat.com/show_bug.cgi?id=767581

Based on c#7 also SPICE-QE (part of Desktop-QE) reproduced this on different environment. Try to work with them closely pls.
Comment 12 David Jaša 2012-11-27 08:40:31 EST
Created attachment 652729 [details]
r-v debug output
Comment 13 David Jaša 2012-11-27 08:44:39 EST
The bug reproducibility varies: it occurs at every attempt sometimes, sometimes only at every fifth attempt or so.

Looking at the log, the bug may be somehow related to main channel switching from "unsecure" to tls (plaintext channel closed before secured one is established?).
Comment 14 Marc-Andre Lureau 2012-11-27 11:09:51 EST
(In reply to comment #13)
> The bug reproducibility varies: it occurs at every attempt sometimes,
> sometimes only at every fifth attempt or so.

It never fails for me here, so it is a bit hard to fix it. But the log from David helps pointing out some potential issues.

It seems we receive both IO_IN and IO_HUP simultaneously. But we treat hup before reading the server link data, that may lead us to reconnect to protocol version 1.

I switched the HUP check after the read, which making sure that if the channel is being reconnected, we ignore the earlier HUP error for normal reconnection to happen.

Can you test with the DLL from:
http://elmarco.fedorapeople.org/libspice-client-glib-2.0-8.dll
(just copy over in the virt-viewer install $prefix\bin directory)

thanks
Comment 15 David Jaša 2012-11-27 11:25:10 EST
Created attachment 652866 [details]
another error

The error c12/c13 seems to be gone (it's hard to say given but on 11th attempt or so, I got this different error (in the attachment).
Comment 16 David Jaša 2012-11-27 11:36:36 EST
(In reply to comment #15)
> (it's hard to say given 

... given the random reproducibility at my setup)
Comment 17 Marc-Andre Lureau 2012-11-27 11:44:27 EST
(In reply to comment #15)
> Created attachment 652866 [details]
> another error
> 
> The error c12/c13 seems to be gone (it's hard to say given but on 11th
> attempt or so, I got this different error (in the attachment).

thanks a lot, so it doesn't seem that trivial to fix, the problem is lying at a lower level in glib win32 socket handling it seems, so instead of getting the HUP before the read, we now get it during read, not surprising, sigh...
Comment 18 Marc-Andre Lureau 2012-11-27 13:15:54 EST
http://elmarco.fedorapeople.org/libspice-client-glib-2.0-8.dll updated to cope with further read errors during link time, and switch back to protocol 1 if any errors. As always, tested succesfully on my side, please try in your side. thanks
Comment 19 David Jaša 2012-11-30 12:45:51 EST
Created attachment 655164 [details]
yet another error

the last testing glib managed to connect every time I tried but once I got this error few seconds after the connection was established...
Comment 20 Marc-Andre Lureau 2012-11-30 14:11:16 EST
(In reply to comment #19)
> Created attachment 655164 [details]
> yet another error
> 
> the last testing glib managed to connect every time I tried but once I got
> this error few seconds after the connection was established...

Ok, that's my fault, respinning a patch & dll.
Comment 21 Marc-Andre Lureau 2012-11-30 14:28:46 EST
(In reply to comment #20)
> Ok, that's my fault, respinning a patch & dll.

The previous patch was throwing a channel link error when switching protocol due to that HUP/RHEL5 spice server issue. Now it shouldn't throw it when switching protocol reconnecting the channel. David, thanks for carrying on testing of http://elmarco.fedorapeople.org/libspice-client-glib-2.0-8.dll
Comment 22 Marc-Andre Lureau 2012-11-30 14:37:12 EST
Created attachment 655203 [details]
last patch
Comment 23 David Jaša 2012-12-03 11:46:02 EST
I couldn't reproduce for quite a number tries so I think that the last patch indeed fixes the bug.
Comment 24 Marc-Andre Lureau 2013-02-06 12:54:34 EST
The patch has been released as part of spice-gtk v0.15, but not yet in mingw64-rhel-6.3.
Comment 26 Marc-Andre Lureau 2013-02-14 14:26:55 EST
Fix is included in mingw-virt-viewer-0.5.3-18.el6ev
Comment 30 errata-xmlrpc 2013-06-10 16:01:05 EDT
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.

http://rhn.redhat.com/errata/RHEA-2013-0889.html

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