CITV vSphere Web Client Plugin stuck at first run - Compellent - Storage - Dell Community

CITV vSphere Web Client Plugin stuck at first run

Storage

Storage
Information and ideas on Dell storage solutions, including DAS, NAS, SAN and backup.

CITV vSphere Web Client Plugin stuck at first run

This question has suggested answer(s)

Hello everyone.

Environment.

Data collector 15.1.10.81

several sc8000 storage systems connected to data collector.

Vsphere 6.0U1

CITV Appliance 030000_012A

Everything set as described in Compellent Integration Tools for VMware Version 3.0 Administrator’s Guide.

VASA works as intended, vcenter plugin successfully connected and registered at vcenter server, event of plugin registration appear in vcenter events.

After relogin to vsphere web client, Dell storage icon appears.

Trying to access it, instead getting started page i get progress bar with "checking credentials and retrieving dell storage information", few hours of waiting, nothing happens.

vsphere-client-virgo.log have no errors.

restarting vsphere-client service, vcenter appliance, RMSV service, CITV appliance not help.

Any suggestions ? 

All Replies
  • Hello,

    Assuming you've completed the configuration of Enterprise Manager details under the Manage Tab. Does this behavior occurs once you complete the configuration with EM and on clicking the Submit in the configuration wizard for the first time ?

    Also can you please verify the Firewall settings in the System where Enterprise Manager is installed. If the firewall is "ON", please turn OFF the firewall and verify does the plug-in works ?

    Thanks.

  • Hello. This is first run after plugin registration, i ever can't get to plugin welcome page and provide details for CITV, looks like SSO or Java issue for me now. Firewall on EM is off. Will try clean vcsa install and test on it.

  • When I click submit on in the configuration wizard for the first time I get the next error:

    Error Stack

    ---------------------

    TypeError: Error #1009

    at com.dell.compellent.vsp.flex.views.connectionmanager::CompellentUserPopup/validateCallback()

    at com.vmware.flexutil.proxies::BaseProxy/notify()

    at com.vmware.flexutil.proxies::BaseProxy/fault()

    at com.vmware.flexutil.proxies::BaseProxy/onInvocationComplete()

    at OperationInvoker/faultResponseForRequest()

    at OperationInvoker/fault()

    at mx.rpc::AsyncToken/www.adobe.com/.../internal::applyFault()

    at mx.rpc.events::FaultEvent/www.adobe.com/.../internal::callTokenResponders()

    at mx.rpc::AbstractOperation/www.adobe.com/.../internal::dispatchRpcEvent()

    at mx.rpc::AbstractInvoker/www.adobe.com/.../internal::faultHandler()

    at mx.rpc::Responder/fault()

    at mx.rpc::AsyncRequest/fault()

    at NetConnectionMessageResponder/statusHandler()

    at mx.messaging::MessageResponder/status()

    Is this a known issue and how can i resolve it?

  • I'm having problems when submitting the credentials. I check the logging and see the validating of the user failing with this error:

    [2015-12-28T16:17:10.653+01:00] [WARN ] http-bio-9090-exec-2          org.springframework.flex.core.DefaultExceptionLogger              The following exception occurred during request processing by the BlazeDS MessageBroker and will be serialized back to the client:  flex.messaging.MessageException: java.lang.NoClassDefFoundError : Could not initialize class com.vmware.vim25.ws.XmlGen

  • After being unable to get the credentials to be applied (error 1009) and waiting a day now I also get the hang on the message "checking credentials and retrieving dell storage information". Were you able to resolve the issue?

  • We done some research in our lab environment with some support provided by EMC (their plugin for vnx2 storage also stop work after vcenter updates). In our case problem reproduces only on domain joined vcenter. EMC technician suggest that case is local (non latin) symbols in object names. Making fresh domain + vcenter + storage plugins confirm that theory. As workaround we decide move vcenters from domain until future fix.

  • Same problem here with CIT 3.1 or 4.0. The plugin registration works but clicking on the Dell Storage icon just bring "checking credentials and retrieving dell storage information" and it hangs forever :(

    I have some working installations with SC 2000/4020 but all version are slighlty different. Btw. i think that the WebClient plugin together with the SC2020(SAS) is very limited.

    Regards,
    Joerg

  • Same problem. After about a month not getting it resolved with Copilot I just let the case close. We were on vCSA 6.0 U2 at the time.

  • Sorry to hear that still the issue persists. Request you to raise a support ticket for the same. Thanks.

  • If anyone is still running into this issue. (hangs when clicking in the vcenter web UI) The solution is as follows:

    1. Enable ssh and bash login on the vcenter appliance (https:// vcenterserver:5480)

    2. login via ssh as root user

    3. cd /usr/lib/vmware-virgo/

    4. chown vsphere-client server (change owner of server folder to the user that runs the vsphere web client)

    5. /etc/init.d/vsphere-client restart (restart web client services)

    Once you do this and webclient services come back up, you can now use the client plugin.

    The reason for this is that the storage manager extension creates a sqllite db to hold your credentials, when it tries to do this it fails to write to that directory since its owned by root.

  • This doesn't seem to work in vsphere 6.5, but the change allowed the config page to come up, just getting web client crashing issues after settings are put in...  maybe something changed in 6.5?

  • See error:

    Error Stack
    ---------------------
    TypeError: Error #1009
    at com.dell.compellent.vsp.flex.views.connectionmanager::CompellentTopLevel/checkForUserCallback()
    at com.vmware.flexutil.proxies::BaseProxy/notify()
    at com.vmware.flexutil.proxies::BaseProxy/result()
    at com.vmware.flexutil.proxies::BaseProxy/onInvocationComplete()
    at OperationInvoker/resultResponseForRequest()
    at OperationInvoker/result()
    at mx.rpc::AsyncToken/www.adobe.com/.../internal::applyResult()
    at mx.rpc.events::ResultEvent/www.adobe.com/.../internal::callTokenResponders()
    at mx.rpc::AbstractOperation/www.adobe.com/.../internal::dispatchRpcEvent()
    at mx.rpc::AbstractInvoker/www.adobe.com/.../internal::resultHandler()
    at mx.rpc::Responder/result()
    at mx.rpc::AsyncRequest/acknowledge()
    at NetConnectionMessageResponder/resultHandler()
    at mx.messaging::MessageResponder/result()

  • I took a look into this solution as well however it looks like even wiht folder ownership there is something preventing the pluging from creating the cmldb and cmldb-journal files and accessing them as it wishes.  Looks to be something selinux~ish based on the audit logs but not being terribly familar with the new Photon OS and the fact that these are an appliance vm for a reason I figured I should leave further tweaking to the experts.  I am going to pop open a case and see what I hear back.

    CIT 4.0 was working on vcsa 6.0, exhibiting these symptoms after migration to 6.5 and re-registering.

  • Just closed out my support case, 6.5 is not supported.  I can confirm seeing CIT 4.0 work on multiple vcsa 6.0 environments though so if you are running to that issue on 6.0 you should give them a call.

  • Someone has solved the issue on vCSA 6.5?

    I cannot register the plugin correctly on this version, using DSITV 4.1

    Exactly the registration process finishes successfully but I cannot see the plugin into my home page.

    Any suggestion?