Last week I was deploying a VMware vRealize Operations Manager (vROPS) environment at a customer and that was causing problems because of no TCP/IP connectivity to the virtual machines. At first, it seemed like an administrator configuration error or typo, but it appeared to be a VMware bug. This blog post is about my findings and the solution to this problem.

Problem:

To find the source of the TCP/IP communication problems, I did some basic testing:

• Is the vROPS web interface available on port 80 or 443?
• Does the virtual machine respond to a ping (ICMP) request?
• Is the vNIC enable on the virtual machine?
• Is the vNIC connected to the right Port Group of (NSX) Logical Switch?
• Are there no NSX Distributed Firewall (DFW) or physical firewall blocking the traffic?

After these tests, I could confirm the problem is inside the appliance/virtual machine.

Solution:

When I was looking at the network card configuration files it appeared that there was a problem with the configured subnet mask. The ‘NETMASK’ field has a prefix notation filled in… not a subnet mask notation. Here is a quick write-up to fix your problem.

1. Open the Virtual Machine console with the vSphere Web Client or vSphere Client.
2. Press ALT + F1 to get into the console (Hint: ALT + F2 to get back to the main screen).
3. Login with the root account and root password.
4. Open the network card configuration file with the vi editor (vi /etc/sysconfig/network/ifcfg-eth0).
5. Search for the line that starts with ‘NETMASK’.
6. Replace the current prefix 28 to a subnet mask 255.255.255.240 (Hint: The values listed here are an example).
7. Restart the vROPS appliance.
8. After a reboot of the appliance, the IP connectivity should be working.

Screenshot(s):

The screenshots below are taken from the Virtual Machine console and gives you basic directions.

Final word:

As a result of inserting a prefix in the OVF deployment screen, the network card configuration failed. A test with a subnet mask notation did not result in these problems. The problem is caused by a network configuration script that sets the network card configuration in the Operating System. VMware please fix this problem… it’s possibly a small code change or the prefix/subnet mask detection is not working correctly.

Update 04-11-2017: Today I received a notification from an ITQ college that the vRealize Log Insight (vRLI) deployment also is suffering from the same problem (vRLI link).