Bug 874698
| Summary: | [spice - remote viewer] Can't open console to VM on 5.9 host "Unable connect to the graphic server" | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Pavel Stehlik <pstehlik> | ||||||||||||
| Component: | mingw-virt-viewer | Assignee: | Marc-Andre Lureau <marcandre.lureau> | ||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||
| Priority: | unspecified | ||||||||||||||
| Version: | 3.0.7 | CC: | acathrow, cfergeau, dblechte, djasa, jbiddle, mkrcmari, vehrlich | ||||||||||||
| Target Milestone: | --- | Keywords: | Regression | ||||||||||||
| Target Release: | 3.2.0 | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| 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 20:01:05 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: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Pavel Stehlik
2012-11-08 17:00:21 UTC
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. > 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) (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. (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 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. Created attachment 652729 [details]
r-v debug output
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?). (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 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).
(In reply to comment #15) > (it's hard to say given ... given the random reproducibility at my setup) (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... 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 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...
(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. (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 Created attachment 655203 [details]
last patch
I couldn't reproduce for quite a number tries so I think that the last patch indeed fixes the bug. The patch has been released as part of spice-gtk v0.15, but not yet in mingw64-rhel-6.3. Fix is included in mingw-virt-viewer-0.5.3-18.el6ev 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 |