VMware Cloud Community
Hodniel
Contributor
Contributor

"A general system error occured: internal error"

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

0 Kudos
12 Replies
admin
Immortal
Immortal

Can you check in the VC server logs (vpxd*.log) for more details about the error?

0 Kudos
Troy_Clavell
Immortal
Immortal

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

0 Kudos
Hodniel
Contributor
Contributor

-- BEGIN task-731 -- host-564 -- vim.HostSystem.reconnect

-- FINISH task-731 -- host-564 -- vim.HostSystem.reconnect

Is all that is in the log. Too bad it's just as informative as the error message...

0 Kudos
Hodniel
Contributor
Contributor

That returns

"VMware VirtualCenter Agent Daemon 2.0.1 build-40644"

Which is the build of my VC

0 Kudos
admin
Immortal
Immortal

Try setting the VC server log level to verbose.

0 Kudos
sonofploppy
Enthusiast
Enthusiast

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!

0 Kudos
Hodniel
Contributor
Contributor

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

0 Kudos
Hodniel
Contributor
Contributor

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============

Invoking on

Arg user:

(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============

Invoking on

Arg entity:

'vim.Folder:ha-folder-root'

Arg permission:

(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)

0 Kudos
admin
Immortal
Immortal

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.

Hodniel
Contributor
Contributor

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. =/

0 Kudos
admin
Immortal
Immortal

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?

0 Kudos
postfixreload
Hot Shot
Hot Shot

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.

0 Kudos