Time Sync issue => There are currently no logon servers to service the logon request

[kfranks]

I'm seeing the following error sequence when running the harness; it appears to relate to logging into vCenter.

20120302-14:12:21	VMmark2 : Checking Client Time Sync
20120302-14:12:21	Tile 0 : Prime Client Time 1330726341 : Client client0 Time : 1330726341 :: TimeErrors : 0 :: Clock Skew 0
20120302-14:12:23	Stafcmd Process: vCServer : Checking VXGLE2VMVC01.VXGLE2.VTG.VCE.COM Time Sync failed to start/complete. Returned: RC = 10002, STAFResult = {'fileList': [{'staf-map-class-name': 'STAF/Service/Process/ReturnFileInfo', 'data': 'System error 1311 has occurred.\r\n\r\nThere are currently no logon servers available to service the logon request.\r\n\r\n', 'rc': '0'}], 'key': None, 'staf-map-class-name': 'STAF/Service/Process/CompletionInfo', 'rc': '2'}
20120302-14:12:23	Stafcmd Process: vCServer : Checking VXGLE2VMVC01.VXGLE2.VTG.VCE.COM Time Sync also returned: STAFResultContext. Display User Job Log
20120302-14:12:23	Error ! Clients or vCServer Out of Sync : []

What is causing this and how can I fix it? I can RDP from the Client to the vCenter server (VXGLE2VMVC01.VXGLE2.VTG.VCE.COM). I can also staf ping the VMs from the prime client. I'm reading about cached credentials can cause this kind of issue in a Windows environment but I don't know if that's applicable or something else.

I ported this tile over from another Vblock and have been working the past couple of weeks to get it running. It was almost running on the other Vblock; I had a mailserver issue to resolve...but it could run everything else.

Thanks!

[jpschnee]

Have you tried rebooting the prime client and the vCServer?  Often that will fix these types of issues.

[kfranks]

That didn't do it. I've even tried using the IP of the vCenter server.

[jpschnee]

Can you send me your VMmark2.config file? 

[kfranks]

Here is the config file from the latest results folder. I was wondering, since the vCenter is in the Vblock's domain controller, do I need some sort of trust relationship between the tile's domain and the Vblock's domain?

Thanks,

-Kirk

[jpschnee]

You might try taking it out of the domain.

In the meantime, I'll take a look and get back to you.

Thanks,

-Joshua

[kfranks]

Joshua,

I can't really do that, it's a shared Vblock testbed. I'll have to figure out another way. Exactly what kind of connection is it trying to make? That might give me a way to troubleshoot it.

Thanks,

-Kirk

Sent from my iPhone

[jamesz08]

It is polling the VC server with the "net time" command.

Since the client is joined to the tile0 mailserver domain I am not sure the domain that the VC is part of will allow it.  I am not that well versed on AD though, not sure if it checks permissions for that.

It could just be a DNS issue.  The client is trying to find out who services the VC's domain but canot resolve the name.  Add the second domain's nameserver as a secondary DNS to the client to see if that will get it working?

[kfranks]

I think it is a access problem with the vc's domain. I stuck the vc's IP in the config, with the same result, and the vc's domain server is in the client's list already.

Thanks,

-Kirk

Sent from my iPhone

[jpschnee · Accepted solution]

Like James, I'm really not versed enough on AD to determine if the issue is there.

Here as a test script that should help you try different options (credentials, ip, etc) outside the harness so you can speed up the testing.  I set it up so its exactly like the VMMARK2.config you sent but it should be pretty easy for you to modify as necessary.  Just remember to leave the STAF commands as is and run it from a command shell.  Maybe a few different iterations will shed some light on the problem.

[kfranks]

Joshua,

Thanks for the script. I ran it this morning and it produced good results from the VC, strangely enough. Upon seeing that I decided to make a short run, and it too worked. I think there may be a caching mechanism somehow responsible for the inability of the client to find a logon server (for VC) I was seeing. That thought is disturbing because it implies things can appear to be broken, when in fact they may not be...making troubleshooting perplexing to say the least. I've gone ahead and started a full run to see if I still have an issue with the mailserver workload. That was the problem I was trying to resolve last week, the results of the mailserver load was zero in the final output of a full run. I'll let you know later how that turned out.

Thanks,

-Kirk