My IT Adventure
使用vSphere Client登录vCenter Server 6.0时可能会出现如下报错信息：
Login to the query service failed.
The server could not interpret the communication from the client. (The remote server returned an error: (500) Internal Server Error.)
这是因为在登录vSphere Client时勾选了”Use Windows session credentials“。试试取消它。
相关知识库链接：Searching the Inventory with the vSphere Client fails (2143566)
You may see following problem if you login vCenter Server 6.0 by vSphere Client:
Login to the query service failed.
The server could not interpret the communication from the client. (The remote server returned an error: (500) Internal Server Error.)
That’s because “Use Windows session credentials” checkbox is selected. Deselect it and give it a try.
Refer KB Searching the Inventory with the vSphere Client fails (2143566)
Just a quick update that VDP will discontinued in future release of vSphere. It doesn`t impact to existing customers till 2022. VMware offers free migration to Dell EMC Avamar Virtual Edition in limited time if customers want to move to other backup solution. Customers can also use other 3rd party backup solutions to integrate with vCenter Server via storage API.
Read this FAQ for detail. VMware products lifecycle matrix for your reference.
vCenter Server 5.5 Update 2e contains fix of Storage Monitor Service. It’s also a stable version since 5.5 Update 1. I got a problem when I upgraded my development vCenter Server last weekend. I’d like to share the solution since VMware doesn’t document that problem. (Maybe I didn’t find it. :-)) It’s kind tricky.
vCenter Server 5.5 Update 2e包含SMS服务的bug修复，它也是当前比较稳定的版本。上周我在升级vCenter Server到这个版本时遇到了一个问题。此问题不是那么容易修复因为VMware的KB并没有提供解决方案，我在这里把我的方法共享出来。
Continue reading “CustomAction VM_InstallJRE returned actual error code 1624”
You probably will see similar issue below if you upgrade vCenter Server from 5.x to 5.5.
vSphere Client show following error when login to vCenter Server by domain account.
The vSphere Client could not connect to vCenter server. The server vCenter server took too long to respond. (The command has timed out as the remote server is taking too long to respond.)
Continue reading “vSphere Client time out to login vCenter and domain user cannot login vcops”
That’s a very small problem but it struggles you if you are enterprise datacenter administrator. As you may know the best practices to run application is by service account. But sometimes you may testing applications by your own domain account and forget remove it.
Few days ago, my domain account locked out on domain controller. The audit report indicated it locked out by vCenter Server every 5 seconds. Then I logged in the vCenter Server, checked out Task Scheduler, Services, Task Manager…etc. Nothing was running under my domain account. I stopped applications one by one on the vCenter Server and related plugin services. No help, I felt so frustrated!!!
Here is how I figured it out eventually.
After the steps above I finally figured out that root cause was my VMware View LAB VM tried to authenticate on vCenter Server by my domain account and stored old password. I powered up the old VM few days ago.
这可能是一个很小的问题，但如果你是企业级数据中心管理员，这个问题可能会很困扰你。如你所知在日常使用中最好用Service Account来运行应用程序。但是有时候你可能和我一样需要用自己的域帐号做一些测试但之后又忘记删除了。
几天前，我的域帐号被域控制器锁定了。域报告显示我的帐号每5秒钟就会被vCenter服务器锁定一次。我在vCenter服务器上检查了任务管理器、服务、计划任务等等，并没有发现任何东西使用我的帐号。然后我将vCenter服务器上的所有服务、应用程序都停了，还是不行！
最终我找到了问题原因，以下是方法：
最终原因是我几天前把一台旧的VM开机了，这台VM上是当时以我的域帐号安装的VMware View做测试用。
If you have set of group VMs and particular group can access each set VMs, you should grant access on vSphere Client or vSphere Web Client.
SSO is slowly sometimes, you could use following CLI to do it more efficient.
New-VIPermission -Entity “Folder Name” -Principal “Domaingroup name” -Role “Role name”
You could do it faster for regular folder name or group name by excel and notepad:
|
New-VIPermission -Entity “ |
Folder Name |
” -Principal “ |
Domaingroup name |
” -Role “Role name“ |
Guess how to do it. 
It’s been a long time since last post, I was pretty busy on a storage issue, I did a lot of work with hardware vendor and VMware for this weird issue.
During our troubleshooting, I noticed a minor problem when I try search VM in vSphere Client, everytime it gave me error message “Unable to connect to web services to execute query“, it requested me “Verify that the VMware VirtualCenter Management Webservices service is running”
I tried to reboot vCenter Server, restart Management webservices and even re-installed vSphere Client, no lucky….Finally I fixed the problem by following step:
It’s simple steps to fix the problem, but this issue confused me and VMware support for a long time. This problem appeared after we upgraded vCenter Server from 5.0 to 5.1, first thing we suspected was inventory services, error message below was logged in ds.log when we searched VM.
[2013-05-25 12:04:31,995 http-nio-/0.0.0.0-10443-exec-634 INFO com.vmware.vim.vcauthenticate.servlets.AuthenticationServlet] Sending security error because of exception : com.vmware.vim.vcauthenticate.exception.SsoUnreachableException: com.vmware.vim.dataservices.ssoauthentication.exception.ServiceCommunicationException: com.vmware.vim.sso.admin.exception.InternalError: General failure.
It looks like a authentication issue, right? So we checked SSO, service account…etc. The unclearly logs lead to a wrong way. 🙂
Since nobody complained to me, I suspected that’s a client side issue, then we tried search on another purge client but same issue. We also suspected the cache of vCenter inventory, but logs didn’t evidence it is, we cannot just reset inventory cache database since that’s production environment!
Okay, I talk too much about troubleshooting process, let’s talk about the search function of vSphere, my understood is vCenter search objects by two different way: Web Client or vSphere Client. It looks like Web Client retrieve data from database or Web Client server.
vSphere Client get data from cache database. The cache database is located in vCenter Server install folder, default path is C:Program FilesVMwareInfrastructuretomcatwebappssmsWEB-INFclassescomvmwarevimsms. the cache file is actually H2 databases, it work together with Tomcat web services, sms folder contains application files of Storage Monitoring Services, it use H2 database engine v1.2.147. Please comments if you think I’m wrong.
If the H2 database incorrupt, storage monitoring services also stop working, you can find the service in Service initializing… status with warning status in vCenter Service Status node of vSphere Client.
One solution fix two issue, I like it!
Today, we P2V one vCenter Server, I re-added identify source for some reason, I didn’t modified any existing domain group and ACL.
After a while I got a interesting case. User reported they got “No permission to login to vCenter Server 5.1 by vSphere Client”.
I looked into the vpxa.log of vCenter Server, it show that:
2013-05-01T11:08:01.399-05:00 [09108 error '[SSO]' opID=6e704a51] [UserDirectorySso] AcquireToken InvalidCredentialsException: Authentication failed: Authentication failed 2013-05-01T11:08:01.399-05:00 [08644 error 'authvpxdUser' opID=5469f71e] Failed to authenticate user <xxxx>
I was not 100% sure that log related to the real problem. but that’s indicated it should be something related to authentication components.
After compared working SSO with the fault SSO, I noticed Domain Alias was blank on fault SSO:
Then I added a domain group on fault vCenter Server and compared the group with working vCenter Server, it’s shows format different, just like that:
Working SSO – CONTOSOTEST-GROUP
Fault SSO – CONTOSO.COMTEST-GROUP
Okay…now I know why user logging got fault. The identify source configured Domain Alias before I removed it on fault SSO, then I added identify source without Domain Alias, and thenvCenter Server used Domain name as default prefix of domain group, it lead to original domain groups format ( CONTOSOxxxx ) cannot be identified by SSO.
So I deleted the identify source and added a same source with Domain alias, problem fixed…