Sunday, 6 December 2015

VDP 6.0.1: Server has a weak ephemeral Diffie-Hellman public key

           ,      No comments   

Written by Suhas Savkoor



When you deploy a 6.0.1 VDP appliance in your vCenter, you configure it by going to the VDP configuration page.

               https://<vdp_ip>:8543/vdp-configure

 Then, you receive this classic message, "Server has a weak ephemeral Diffie-Hellman public key"



5 simple steps to fix this issue:

Step 1:

SSH / Open Console to the VDP Appliance.
The Username is: root
Default Password: changeme

Step 2:

 Change your directory to:

Open server.xml



Step 3:

 Locate the following lines:





Step 4:

 Replace them with the following lines: Press " i " to begin edit



Save changes by Pressing Esc and then :wq

Step 5:

 Reboot the VDP appliance and login again to the management web page.
This time, you will be able to login to the web page without the Error.

Saturday, 5 December 2015

Configuring Serial Port For A Virtual Machine

                No comments   

Written by Suhas Savkoor



You can use virtual ports to send debugging data from a virtual machine to the host system or to another virtual machine.

In this video, I have configured Serial Port for two Windows 2008 virtual machines, and I am testing them by echoing a ext message to the configured COM port, COM1



Click this link for, Configuring Serial Port for a Loop-Back

Friday, 4 December 2015

Check For Virtual Machine Memory Reservation From Inside the VM's Guest

                No comments   

Written by Suhas Savkoor



If we wanted to check whether we have any memory reservations done for the VM, we go to the virtual machine's Edit Settings and under Resources tab we will be able to see the CPU and memory reservations. 

Now, I came across this issue when I was working with a customer:

The customer was trying to install a Mobile View software on his Windows virtual machine and this software was checking for memory reservation on the VM. 
This was very "peculiar" indeed, and we were having a discussion regarding how a virtual machine works. The discussion included that the virtual machine is not aware that it is actually virtual. It thinks that it is a physical machine and continues to behave like one. 

But the question remained, how the software was able to check memory reservations. The installation would not proceed further and would pop a error, "Not enough memory reserved" 

Then, I questioned, what about VMware tools? Can the guest query VMware tools for memory reservations done on it? 

Well, it turns out it can query VMware tools for this information.

Open a Command prompt from the VM:

For Memory Reservation:

Change Directory to 
C:\Program Files\VMware\VMware Tools

Run the command 

For CPU Reservation:

Change Directory to 
C:\Program Files\VMware\VMware Tools

Run the command 

The output is something as seen below:


So the guest does know!!

Configuring vSphere Web Client On A Custom Port

                1 comment   

Written by Suhas Savkoor



During installation of Web Client you will come across a step in the wizard for configuring the port. The default https port used is 9443

Now, you decide that you want to change this https port to a custom port of your choice. Do you really want to reinstall web client? Not a wise choice. You can perform a little tweak to change this.

All you need to do is edit the Web Client configuration file.

Where is this file located?

C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\configuration

 Make a copy of the tomcat-server.xml file. Then, edit the original file.

And what to edit here?

Locate the following line

<Connector port="9443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="500" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" 

And change the 9443 Port value to the required unused port. I changed it to 9444

Once the change is done, go ahead and restart the Web Client Service.

Then login to web client and there you go you have your own Custom port. 

Thursday, 3 December 2015

VPXD Process Reports 100 Percent CPU Usage

                No comments   

Written by Suhas Savkoor



In task manager, you notice the VMware vpxd.exe process is using almost 100 percent of CPU and also a high memory usage. Sometimes, this also hinders you from logging into vCenter Server via a vSphere client saying the application took too long to respond.

What do we do in this case? We might end up rebooting the vCenter machine, and it might work good for sometime, but then again after a couple of hours or days it might start throwing up this 100 percent CPU usage causing lethargic behavior.

What did I do when I came across this issue? Well, the vCenter Logs is what came to the rescue.

From the vCenter vpxd logs located in:
C:\ProgramData\VMware\VMware VirtualCenter\Logs\vpxd-X.log



Here, we have excessive calls being done to the Performance Manager API and this causing the vpxd.exe process to consume 100 percent CPU.

Here we see, we have a process ID 3b863d5f-99a5-f4d0-0cce-667f34d1c3a4  Now what we need to do is track which process ID is this or a source making this repeated API Calls. 

 For this, we need to open the vpxd-profiler.log (Again located in the same directory as your vpxd.log) 

 My vpxd-profiler.log looked like this:


Here, we see we have a service account MYCMSC\svc_vdmadmin and an IP 172.25.20.193 making this repeated API calls.

The vpxd-profiler.log also recorded the following information.




CPU usage mean/min and max is 10000, which corresponds to 100 percent

To mitigate this issue, you need to see the service account triggering this API call, and disable/prevent it for access to vCenter. In my case, it was a third party security software making this API call. This software was no where related or required for vCenter, and I went ahead and disabled it, resolving the 100 percent CPU usage.


Free the usage!



Tuesday, 1 December 2015

HTTP 404 Error While Logging Into Web Client

                No comments   

Written by Suhas Savkoor



So, you might have deployed a fresh instance of vCenter and everything is going well. You are able to login to the vCenter using the Windows C# client. Then you think, why not I use web client too, and you open up a browser and enter the vCenter IP and the web client port and it pops up a message saying HTTP 404 Error.


Well, what now?

It looks like this is a known issue with Web Client 5.1 and 5.5. There are a couple of workarounds.

First one:

1. Uninstall and reinstall the Web Client
2. During installation do not specify any specific paths, keep all the values to default.

Unfortunately this did not work for my case. What was happening in my case was, the default installation directory was going to C:\Program Files\VMware.....
Now, this space between Program and Files can cause the HTTP 404 Issue. Note that this won't be the case for everyone.

So in this case, we need to specify a Custom Directory, this brings to next path.

Second One:

1. Uninstall Web Client
2. Reinstall with a Custom directory with no spaces at all. My directory in this case was C:\WebClient

Well, this worked. I gave a couple of minutes for the service to kick in and I was able to login to web Client.

Third One:

If you install Web Client on a different directory, then you will have to perform some additional steps. You will have to create a symbolic link for the registry update.

These steps can be found in this KB.

Well, if you are lucky everything will run well. If not, workarounds save the day.

Sunday, 29 November 2015

Automatic Shell and SSH Session Logout

                No comments   

Written by Suhas Savkoor



We have all used SSH Sessions to the ESXi hosts. We use either Putty or other means to obtain access to ESXi Shell, so that we can perform certain operations through the command line for the host. 

One additional thing is required for this process. We need to Start the SSH Service for the host. This is found Under Configuration > Security Profile > Services. This is disabled by default for security purposes. 

Everything is great. We can even make this service better by configuring time-outs. 

There are two time-outs that we can configure.

1. ESXi Shell Interactive Time Out - This is applicable to the SSH Sessions that were opened after the configuration was done. Let's say we have configured this time-out to 60 seconds. So once this configuration is done, and a new Putty Session is opened, it automatically closes after 60 seconds of no activity. Well, if you don't run any commands or you don't scroll in the SSH Session for 60 seconds, you will be logged out automatically. 

2. ESXi Shell Time Out - Remember that SSH Service that we were talking about, yes? We can configure a time-out for this as well. Setting this to, for example 60 seconds, will cause the SSH Service to stop automatically after 60 second regardless of any activity being done or not in the Putty terminal. Shell time out stops access to new Putty Sessions, however, if you have already open Putty Sessions, they will continue to work just fine. 

How do we configure this? 

Method 1: GUI

Select the Host > Configuration > Advanced (Under Software)
Here scroll down to UserVars and locate ESXiShellInteractiveTimeOut and ESXiShellTimeOut and set them to a required value (in seconds)

Method 2: Command Line

Open a SSH to the host that requires to be configured and run these two commands:

ESXi Shell Interactive Time Out


ESXi Shell Time Out


Restart the services for the changes to be applied.



esxcli with time-outs folks!