I've got 2 servers (ESX server 3.0.2). Both are linux based.
I've got Virtual infrastructure Client 2.0.1
Using the VC, i'm able to manage one of my 2 servers. When I go to connect the second, after the wizard completes, tosses me the error "A general system error has occured: internal error". The second server is added, but listed as disconnected. Trying to connect results in the same error.
I'm able to pull up the second server directly, and there are working VMs running on it.
Does anyone have any thoughts on what might be causing this problem? Or (hopefully) a way to fix it?
Thanks
Can you check in the VC server logs (vpxd*.log) for more details about the error?
also, from the console or using Putty, check to make sure the ESX servers VC Agent is the same as the virtual center build
vpxa -v
That returns
"VMware VirtualCenter Agent Daemon 2.0.1 build-40644"
Which is the build of my VC
Try setting the VC server log level to verbose.
Hi,
Sorry, just to confirm is the impacted ESX server and all sessions hosted on it greyed out and labelled "disconnected"?
As well as checking the logs and the VC agent, you could check your virtual memory......One possible reason is oversized log files is stopping your service console from bringing the server back online in VC. Is your Service Console memory at default 272MB? You can run "free -m" from the Service Console, this will display how much swap (virtual memory) you are currently using.
Good luck!
The VC shows the exs server host as disconnected. It does not show the VMs that are running on that server.
It is possible to log into the server listed as disconnected directly. It is running VMs.
The virtual memory would appear to be a little less then 50% full
So with verbose logging I get a bit more in the way of logs. I'm still not sure what's going wrong here.
-- BEGIN task-746 -- group-h437 -- vim.Folder.addStandaloneHost
SSLVerifyCertAgainstSystemStore: Subject mismatch: localhost.localdomain vs 192.168.2.226
SSLVerifyCertAgainstSystemStore: The remote host certificate has these problems:
The host name used for the connection does not match the subject name on the host certificate
A certificate in the host's chain is based on an untrusted root.
SSLVerifyIsEnabled: failed to read registry value. Assuming verification is disabled. LastError = 0
SSLVerifyCertAgainstSystemStore: Certificate verification is disabled, so connection will proceed despite the error
FormatField: Optional unset (vim.event.HostCnxFailedBadUsernameEvent.host)
============BEGIN FAILED METHOD CALL DUMP============
(vim.host.LocalAccountManager.AccountSpecification) {
dynamicType = <unset>,
id = "vpxuser",
password = (not shown),
description = "VMware VirtualCenter administration account",
}
Fault Msg: "The specified key, name, or identifier already exists."
============END FAILED METHOD CALL DUMP============
FormatField: Optional unset (vim.event.HostCnxFailedBadUsernameEvent.host)
============BEGIN FAILED METHOD CALL DUMP============
'vim.Folder:ha-folder-root'
(vim.AuthorizationManager.Permission) [
(vim.AuthorizationManager.Permission) {
dynamicType = <unset>,
entity = <unset>,
principal = "vpxuser",
group = false,
roleId = -1,
propagate = true,
}
]
Fault Msg: "The requested change could leave the system without full administrative privileges for any user or group."
============END FAILED METHOD CALL DUMP============
-- FINISH task-746 -- group-h437 -- vim.Folder.addStandaloneHost
FormatField: Optional unset (vim.event.HostCnxFailedBadUsernameEvent.host)
-- BEGIN task-internal-982 -- -- vmodl.query.PropertyCollector.Filter.destroy
-- FINISH task-internal-982 -- -- vmodl.query.PropertyCollector.Filter.destroy
FormatField: Optional unset (vim.event.HostCnxFailedBadUsernameEvent.host)
Ah, ok. This is a bug in VC that has been fixed in VC 2.5. As a workaround you can connect to the ESX directly with the VI client and assign an admin role to the root user.
I've had an admin role assigned to the root user all along, but I still can't pull it into my VC. Looks like I may have to consider upgrading. =/
So both vpxuser and root have an admin role on the host? Did you try removing the vpxuser account completely from the host and then try adding the host?
First we need to see where the problem is. vpxa or hostd.
Can we connect to this ESX server directly? If so, we hae a working hostd. The problem likely on the vpxa part.
What we can do is copy the uninstall script from VC (under C:\Program Files\VMware\VirtualCenter Server\upgrade) You need vpx-uninstall-esx-6-linux-xxxx and vpx-upgrade-esx-6-linux-xxxx.to ESX server
run the uninstall "sh vpx-uninstall-esx-6-linux-xxxx"
either run the upgrade script or just reconnect to VC.