Bug 1008935

Summary: [User Porta] Autoconnect does not work
Product: Red Hat Enterprise Virtualization Manager Reporter: Jiri Belka <jbelka>
Component: ovirt-engine-userportalAssignee: Frantisek Kobzik <fkobzik>
Status: CLOSED DUPLICATE QA Contact: Pavel Stehlik <pstehlik>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 3.3.0CC: acathrow, ecohen, iheim, mavital, michal.skrivanek, Rhev-m-bugs, yeylon
Target Milestone: ---Keywords: Regression, Triaged
Target Release: 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-23 11:22:42 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 Flags
engine.log, vdsm.log none

Description Jiri Belka 2013-09-17 11:21:09 UTC
Description of problem:

Autoconnect does not work. Client: RHEL6 FF 17.0.8/17.0.9
Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. assign one vm to a user, start it from admin portal but do not open console!
2. login as the user to basic user portal while 'Connect Automatically' is checked on login screen
3.

Actual results:
no console is opened when 'connect automatically' is checked

Expected results:
console is opened when 'connect automatically' is checked

Additional info:

Comment 1 Jiri Belka 2013-09-17 11:42:36 UTC
2013-09-17 13:39:05,157 INFO  [org.ovirt.engine.core.bll.LogoutUserCommand] (ajp-/127.0.0.1:8702-6) Running command: LogoutUserCommand internal: false.
2013-09-17 13:39:05,178 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-6) Correlation ID: 5f8b7961, Call Stack: null, Custom Event ID: -1, Message: User vdcadmin logged out.
2013-09-17 13:39:06,938 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-94) Command GetCapabilitiesVDS execution failed. Exception: VDSNetworkException: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
2013-09-17 13:39:09,981 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-3) Command GetCapabilitiesVDS execution failed. Exception: VDSNetworkException: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
2013-09-17 13:39:13,049 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-1) Command GetCapabilitiesVDS execution failed. Exception: VDSNetworkException: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
2013-09-17 13:39:13,810 INFO  [org.ovirt.engine.core.bll.LoginUserCommand] (ajp-/127.0.0.1:8702-7) Running command: LoginUserCommand internal: false.
2013-09-17 13:39:13,849 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-7) Correlation ID: 37204c99, Call Stack: null, Custom Event ID: -1, Message: User vdcadmin logged in.
2013-09-17 13:39:16,084 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-7) Command GetCapabilitiesVDS execution failed. Exception: VDSNetworkException: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
2013-09-17 13:39:19,131 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (DefaultQuartzScheduler_Worker-14) Command GetCapabilitiesVDS execution failed. Exception: VDSNetworkException: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

There is no SetVmTicketCommand.

VDSM     => vdsm-4.12.0-138.gitab256be.el6ev.x86_64
libvirt  => libvirt-0.10.2-24.el6.x86_64
qemu     => qemu-kvm-rhev-0.12.1.2-2.402.el6.x86_64

vdsm.log is full of tracebacks:

BindingXMLRPC::ERROR::2013-09-17 13:38:01,619::BindingXMLRPC::72::vds::(threaded_start) xml-rpc handler exception
Traceback (most recent call last):
  File "/usr/share/vdsm/BindingXMLRPC.py", line 68, in threaded_start
    self.server.handle_request()
  File "/usr/lib64/python2.6/SocketServer.py", line 278, in handle_request
    self._handle_request_noblock()
  File "/usr/lib64/python2.6/SocketServer.py", line 288, in _handle_request_noblock
    request, client_address = self.get_request()
  File "/usr/lib64/python2.6/SocketServer.py", line 456, in get_request
    return self.socket.accept()
  File "/usr/lib64/python2.6/site-packages/vdsm/SecureXMLRPCServer.py", line 122, in accept
    client, address = self.connection.accept()
  File "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 167, in accept
    ssl.accept_ssl()
  File "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 156, in accept_ssl
    return m2.ssl_accept(self.ssl, self._timeout)
SSLError: sslv3 alert certificate unknown

Comment 2 Jiri Belka 2013-09-17 11:43:12 UTC
Created attachment 798767 [details]
engine.log, vdsm.log

Comment 3 Jiri Belka 2013-09-17 12:00:16 UTC
Same issue with prestarted pool.

Comment 4 Jiri Belka 2013-09-17 12:18:45 UTC
In User Portal I see follow info even my browser is supported FF from RHEL6.

spice-xpi-2.7-22.el6.x86_64
firefox-17.0.9-1.el6_4.x86_64

  Console :
  (Edit)
  Your browser/platform does not support console opening

I can, of course, open any console manually with double-clicking on icon.

Comment 5 Jiri Belka 2013-09-17 12:33:05 UTC
It issue seems to be related to slow console detection time. I mean this: when you login to User Portal next to 'Console:' there is no console type written. The type is visible after next page automatic reload. Thus it seems that autoconnect wants to open console but as it does not know type of the console, the console is not opened.

But... when you login without autoconnect, you wait a while to see console type, then you do Edit, click OK (then this saves it to local storage, IIRC), it makes autoconnect working when you try to use autoconnect on next login - as it knows the type from local storage (???).

Comment 6 Frantisek Kobzik 2013-09-17 14:14:06 UTC
This seems to be related to newly introduced async operation to console availability detection. There is a patch posted to fix this already. I'll check if it solves this issue. If so, I'll mark this as a dupe.

Comment 7 Frantisek Kobzik 2013-09-23 11:22:42 UTC

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