Monday, 25 January 2016

Connecting A ESXi 5.5 U3b Host To A vCenter With A Lower Version.

Written by Suhas Savkoor



Lately, I have been seeing more and more cases with VMware Support regarding, "Unable to connect an ESXi host to a vCenter after upgrading it to 5.5 U3b" The common error you get when you try adding this host to a vCenter is

" Cannot contact the specified host. The host may not be available on the network, a network configuration problem may exist, or the management service on this host is not responding "


This is because, with 5.5 U3b SSLv3 is disabled, however, on a vCenter that is on a version lower than 5.5 U3b has SSLv3 enabled.
To resolve this, the best method would be to upgrade your vCenter to 5.5 U3b.

If you do not want to upgrade vCenter, then you can enable SSLv3 on that upgraded ESXi host. However, this is not a best practice and is not recommended by VMware, because it defeats the purpose of the upgrade. However, if you want to, then you can proceed with the below steps:

There are two parts were you need to enable SSLv3:

A) Enabling SSLv3 for Hostd - Port 443
1. Open a SSH to this ESXi host.
2. Browse to this location using the below command:
# cd /etc/vmware/rhttpproxy
3. Backup the config file:
# cp config.xml config.xml.bak
4. Edit the file using the below command (Press i to begin edit)
# vi config.xml
Locate the <vmacore>, then locate the <ssl> Under <ssl> add the following entry:
<sslOptions>16924672</sslOptions>
5.Save the file by pressing Esc and then typing :wq!

B) Enabling SSLv3 for Port 902 (Required to connect to vCenter)
1. From the same SSH of the host, run the below command:
# esxcli system settings advanced set -o /UserVars/VMAuthdDisabledProtocols -s ""

Restart the rhhtpproxy using the below command:
# /etc/init.d/rhttpproxy restart
That's it, now you can connect this ESXi 5.5 U3b host to a lower version of vCenter. However, again, this would not be a recommended practice as this will expose the host to SSLv3 POODLE vulnerability.

Thursday, 21 January 2016

Configuring Serial Port As A Loop-back COM Port For The Same Virtual Machine.

Written by Suhas Savkoor



If you have missed out on "How to configure COM ports between two virtual machines" video, here is the link to it.

In this article, we will see how to configure COM port on the same virtual machine. This is used in a scenario like; You have an application that monitors a set of readings in your environment. When the readings cross a particular threshold, then it has to generate a signal or send some information to an alerting system using a COM port.

Now, in Windows, when you go to device manager and expand the Ports option, you can see that there are two COM ports; COM1 and COM2. These are always there irrespective of whether you have configured serial port or not for that specific virtual machine.

Configuring serial port for the same machine:

1. Power OFF the virtual machine for which you are trying to configure this COM port.
2. Go to Edit Settings and Click Add. Here select Serial Port and click Next. 
3. Select Output to named pipe and click Next
4. The pipe name should be of the format: \\.\pipe\<pipe_name>
5. Near End: Server; Far End: A process
6. Create another COM port for this same virtual machine. Click Add. Select Serial Port and Output to named pipe option again.
7. Here the pipe name should be the same as the one with first serial port.
8. Configuration for second serial port; Near End: Client; Far End: A process
9. Click OK

Testing COM port setup:


1. Power ON the virtual machine and open CMD in administrative mode, and open Putty to COM1 in serial.
2. Type the following command in CMD:
echo text > COM2
3. In the Putty you can see the message "text" being echoed.
4. The Putty is on COM2 and CMD on COM1. Hence the Putty is listening for incoming traffic on COM1 and the CMD is sending the message to COM2, which is why Putty is opened in COM1 serial.

Simple, isn't it?

Update Manager Service Crashes During A Scan Operation On An ESXi Host

Written by Suhas Savkoor



Today, I came across an issue with Update Manager while working on a support request. The environment, comprised of two vCenter in linked mode and each of them having their own Update Manager server. The update manager was installed on a machine of their own. The second vCenter was running well and good, however, on the first vCenter there was an issue with the "Scan" operation.

Whenever a baseline was attached to any of the hosts under this vCenter, and a scan operation was performed, the progress would go to 10 percent, stop there for few minutes and then the vSphere Update Manager service used to stop and crash causing the VUM to lose connectivity with the vCenter.

Upon on reviewing the logs for the failure, vmware-vum-server-log4cpp.log, I noticed the following:
Error accessing stagepath C:/ProgramData/VMware/VMware Update Manager/Data/host_upgrade_packages/esxi-upgrade-ryvdmfvtoz type 1 error 0/The operation completed
This means that the patch store and the DB are not in-sync

When I browse C:\ProgramData\VMware\VMware Update Manager\Data, I do not see the host_upgrade_packages folder, and the scan is failing because it is unable to find this folder.
The install directory may vary depending on your installation settings.

What can be done?

1. If you have your old update manager (Rarely happens), then you can copy paste this folder into this directory and the scan will work good!

If not, then we will have to re-initialize the update manager database.
**Re-initializing the database will clear out the database for update manager, which means, if you had any custom baselines and patches downloaded, they will be lost**

Steps to Re-initialize the VUM database:

1. First Login to SQL management studio hosting this update manager database. Expand Database > Right click the VUM database > All Tasks > Backup. Back this database to a disk.
2. Stop the Update Manager service from services.msc
3. Open a command prompt in elevated permission mode (Administrative mode) change the drive to the VUM installed disk drive and run the below command:
cd "C:\Program Files (x86)\VMware\Infrastructure\Update Manager\" 
4. Then run the below command to re-initialize the database:
vciInstallUtils.exe -O dbcreate -C . -L . 
(Both . should be used)

5. Once command has executed restart the Update Manager service.
6. Login to vCenter > Select ESXi host > Update Manager > Admin View
7. Under Configuration tab select Download Settings and download the patches again. If you want to add your custom baselines, then you can go ahead and do so
8. Go back to Compliance View and Attach and Scan, and this time the operation should succeed!

Wednesday, 20 January 2016

"No Network Adapters Found" For Nested ESXi 6.0 Host

Written by Suhas Savkoor



While setting up a nested ESXi 6.0 host, you will come across the following error during the installation:


Now, it says no network adapter found for this virtual machine on where I am trying to install the ESXi 6.0. Funny, because during creation of the virtual machine I have specified one network card of the e1000 type.
Now, if I SSH to the actual ESXi hosting this virtual ESXi, I see that there is a network adapter "e1000" listed in the .vmx file of the virtual machine. And this virtual machine resides on the appropriate network.


Now the funny thing about this is, the virtual machine that I created for this ESXi was allocated with 2GB of RAM. The minimum memory requirement for a 6.0 ESXi host is a 4GB RAM. I did not receive a warning during the installation, which is quite weird. However, upon changing the memory to 4GB I was able to proceed with the installation successfully.

Well, there you go!

Tuesday, 19 January 2016

Changing The Network Adapter Type of A Virtual Machine Without Removing The NIC

Written by Suhas Savkoor



If we have a virtual machine with the NIC given to it as E1000 and we want to change this NIC to VMXNET3, then from the Edit Settings on the virtual machine we will select the Network adapter. Here you will notice that you do not have an option to change the Adapter Type.
The classic step we would follow is to login to the virtual machine and make a note of the network settings. We then, remove the Network adapter from the Edit Settings of the virtual machine. Once the NIC is removed, we will go ahead and a new NIC, and while adding a new adapter, we get the choice of choosing the adapter type. Once the adapter is added, we login back to the VM and re-populate the network settings.
This all works good, however, removing the NIC and adding a new one will change the MAC address of the device. Every network adapter will have a MAC address which will be listed under the adapter type option in the Edit Settings of the virtual machine. If an application is dependent on the MAC address, for example a VM hosting telephone IVR operation, this might break as it uses the MAC address of the device. In scenarios like this, we will have to reconfigure the application.

The other way to change the network adapter type is:

1. Power OFF the required virtual machine.
2. Take a SSH (Putty) to the host where this virtual machine resides. Change the directory to the virtual machine's directory.
3. Open the virtual machine's .vmx file using the vi editor
# vi <vm_name>.vmx
4. Locate the following line
ethernet0.virtualDev = "e1000"
Press " i " to begin edit and change the e1000 to vmxnet3 (Retain the quotes and text is case sensitive). Press Esc and type :wq! to save and exit the file.

5. Remove the virtual machine from Inventory.
6. Browse the datastore where this VM resides and right click the .vmx file and add this vmx file of the virtual machine to the inventory.
7. Go back to Edit Settings of the virtual machine, select the network adapter and you will see the updated adapter type with the same MAC address.

You just saved a MAC address!

Error Licensing A vCenter: License File Not Found.

Written by Suhas Savkoor



When you are adding a license to your vCenter 5.x, you receive the error:

Diagnostic message: License File Not Found



This error message is received if the license you are adding is a 6.0 license. A 5.5 vCenter cannot be licensed with a 6.0 key. 

To downgrade your license key you can follow this article here.
Once the license key is downgraded to 5.x, you will receive a new key, for the downgraded version, you can then apply this license to your 5.5 vCenter successfully.

Sunday, 17 January 2016

Port 80 Already In use During vCenter Installation

Written by Suhas Savkoor



During vCenter installation, you will come across the port details wizard page and when you click Next, you will receive an error message similar to the one below:

" The following port numbers are either invalid or already in use. VMware VirtualCenter HTTP Port: 80 "

You can have a look at this KB article here, however, sometimes even though all the conditions in this article are met, you might still receive the above mentioned error.

How do we get past this?

1. Open a command prompt in elevated mode (As administrator) on the machine where you are installing the vCenter Server. Run the below command:
netstat -ano | find "80"
This command tells which process is currently listening on port 80. You will see a Process ID (PID) of 4 which is running on this port blocking the installation of vCenter.
2. Open Task Manager on the same machine. Navigate to Processes tab. Click View and click Select Columns and make sure PID is checked and then select OK
3. Now, if it is a normal application or IIS, disable it or uninstall. If it is a System Process: PID 4 - you need to disable the HTTP.sys driver
4. On the same machine, open regedit (Start > regedit)
5. Go to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP
6. Change the value of " start " to 4 which means disabled
7. Reboot the machine and perform the installation again.