vCenter Server Appliance – filesystem out of space

So it’s all happening this week with this upgrade/clean up of the MTI solution centre!! =)

Upon finishing all the upgrades and reconfiguring vSphere Replication and Site Recovery Manager, I noticed the DR vCSA was a bit unresponsive…. taking ages to log into Web Client (sometimes it didn’t even get that far) – signing into the VAMI, I noticed that there was a critical error regarding the log file.

vcsa01

If you weren’t aware, one of the changes to vCSA with 6.0 was the deployment of 11 VMDKs with the appliance, one for each component service of vCenter. In previous versions there were only 2 virtual disks and this proved problematic when trying to increase disk capacity for particular components of vCenter Server (ie if you only wanted to increase the log directory).

As the vCSA was running in a demo environment, I decided to only do a ‘Tiny’ install – and it turns out that vCSA just ran out of capacity for logging – a quick jump onto the console proved this to be true:

vcsa02

The following VMware KB provides details into the 11 VMDKs and what mount points are attached to each vdisk: https://kb.vmware.com/kb/2126276.

vcsa04

I followed the instructions to increase the capacity of the log vdisk (VMDK5) and then gave the vCSA a reboot…..

vcsa03

The vCSA is now healthy and back to normal. =)

As a footnote, here’s a VMware KB that explains how to increase he maximum backup size and index of the vCSA to try and resolve he issue of the log directory fill up: https://kb.vmware.com/kb/2143565

Advertisements

Cannot connect to vCenter Server via vSphere Client – timeout

I’ve been upgrading my company’s solution centre to vSphere/vCenter 6.0 update 2 the past week and noticed that I was having issues logging into the vCenter Server Appliances I had deployed.

It was a strange issue because I could log into the Windows vCenter Server I had deployed in my primary cluster, but couldn’t log into the vCenter Server Appliance I had deployed in my secondary cluster….. hmmm…. Web Client worked fine for both, but it was the vSphere C# client that was timing out for the vCSA!

vc01.jpg

After much head scratching and trawlling through logs (Found at C:\Users\username\AppData\Local\VMware\vpx\viclient-x-0000.log), it turns out the problem is with the default time out value of the vSphere client for authentication.

The default timeout value is 30 seconds, and my suspicion is that the vCSA was taking slightly longer to respond to authentication…. changed the value to 60 seconds and it all worked fine!

Fire up vSphere Client and connect to another vCenter Server or ESXi host, then click Edit->Client Settings. Change the Client-Server Command Timeout value to Use a custom value and the Timeout in seconds to 60.

vc02

Here’s the VMware KB article about timeout values: https://kb.vmware.com/kb/2072539, there’s also instructions on how to edit the Windows registry if you can’t bring up vSphere client.

Just for the sake of it, here’s the error log:

[viclient:Error :P: 3] 2016-09-06 10:12:35.520 RMI Error Vmomi.SessionManager.Login - 4
<Error type="VirtualInfrastructure.Exceptions.RequestTimedOut">
 <Message>The request failed because the remote server 'xxxxx' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)</Message>
 <InnerException type="System.Net.WebException">
 <Message>The command has timed out as the remote server is taking too long to respond.</Message>
 <Status>Timeout</Status>
 </InnerException>
 <Title>Connection Error</Title>
 <InvocationInfo type="VirtualInfrastructure.MethodInvocationInfoImpl">
 <StackTrace type="System.Diagnostics.StackTrace">
 <FrameCount>17</FrameCount>
 </StackTrace>
 <MethodName>Vmomi.SessionManager.Login</MethodName>
 <Target type="ManagedObject">SessionManager:SessionManager [xxxxx]</Target>
 <Args>
 <item></item>
 <item></item>
 <item></item>
 </Args>
 </InvocationInfo>
 <WebExceptionStatus>Timeout</WebExceptionStatus>
 <SocketError>Success</SocketError>
</Error>
[viclient:Critical:M: 6] 2016-09-06 10:12:35.531 Connection State[xxxxx]: Disconnected
[viclient:SoapMsg :M: 6] 2016-09-06 10:12:35.532 Attempting graceful shutdown of service ...
[viclient:SoapMsg :M: 6] 2016-09-06 10:12:35.534 Pending Invocation Count: 0
[viclient:SoapMsg :M: 6] 2016-09-06 10:12:35.535 Graceful shutdown of service: Success
[ :Error :M: 6] 2016-09-06 10:12:35.543 Error occured during login
VirtualInfrastructure.Exceptions.LoginError: The server 'xxxxx' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)
 at VirtualInfrastructure.LoginMain.Process(BackgroundWorker worker, DoWorkEventArgs e)
 at VirtualInfrastructure.LoginWorkerImpl.Worker_DoWork(Object sender, DoWorkEventArgs e)
...
 at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
 VirtualInfrastructure.Exceptions.RequestTimedOut: The request failed because the remote server 'xxxxx' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)
 at VirtualInfrastructure.Soap.SoapServiceWrapper.DoInvokeSync(ManagedObject mo, MethodName methodName, Object[] parameters, Int32 timeoutSecs)
 at VirtualInfrastructure.Soap.SoapTransport.VirtualInfrastructure.Transport.InvokeMethod(ManagedObject mo, MethodName methodName, Object[] pars)
 at VirtualInfrastructure.ManagedObject.InvokeMethod(MethodName methodName, Object[] pars)
 at Vmomi.SessionManager.Login(String userName, String password, String locale)
 at VmomiSupport.VcServiceImpl.LoginNormally(LoginSpec loginSpec)
 at VmomiSupport.VcServiceImpl.Login(LoginSpec loginSpec)
 at VirtualInfrastructure.LoginMain.Process(BackgroundWorker worker, DoWorkEventArgs e)
 System.Net.WebException: The command has timed out as the remote server is taking too long to respond.

 --- End of inner exception stack trace ---