Within this article I will share some of the challenges faced while implementing a VMware Auto Deploy environment with DHCP for the Management Network.
The environment uses an Infoblox DHCP/DNS appliance but contains some good-to-know things that are not Infoblox specific, so keep on reading.
DHCP is configured to use mac-address reservations to ensure that each ESXi Host receives a static IP address. After starting ESXi from PXE Boot you will get the well-known ESXi Boot Screen:
This boot screen contains the ESXi Hostname, IPv4 and IPv6 address.
In our case we had some challenges regarding to the DNS Hostname which was displayed as http://dhcp-x.x.x.x/. The IP address however was correct to the mac-address reservation within DHCP.
Troubleshooting indicated the following facts:
- The dhcp-x.x.x.x hostname wasn’t resolvable by DNS;
- The correct hostname was resolvable by DNS (but wasn’t listed within ESXi);
- Reversed DNS lookup was also correct.
Use nslookup <ip address> to see if reversed DNS lookup is working correctly. This should give you the hostname if the DNS Pointer (PTR) record is created successfully . The PTR record is mandatory to let ESXi discover it’s Hostname
Whenever the ESXi Host boots or when the Management Network gets restarted the /var/log/dhclient.log clearly shows that, as part of the DHCP process, a Reversed DNS lookup is done to get the systems Hostname. (“dns: Resolving PTR for x.x.x.x . . . succeeded”)
The outcome of the successful “Resolving PTR for …..”-action is also shown in the /var/log/vmkernel as shown in the next screenshot.
Mind the fact that the Hostname at first was “localhost” (Old value) and has been changed to “textpxe” due to the successful reversed DNS lookup.
So how can it be that our ESXi Hosts within Infoblox were constantly named “dhcp-x.x.x.x” while reversed DNS is working correctly?
Our specific /var/log/dhclient.log revealed something interesting when the ESXi Host gets rebooted (or when the Management Network gets restarted). It’s doesn’t show any entry about resolving a PTR record and instantly sets the hostname to dhcp-x.x.x.x
Further investigation shows that the /etc/dhclient-vmk0.leases (since we are using vmk0 as Management Network) is containing the DHCP option “host-name” as shown in the screenshot below.
Basically the ESXi Host, as part of the DHCP process, isn’t doing a Reversed DNS lookup since it already got the DHCP Option “host-name”. This behavior makes sense: why try to resolve the Hostname when it’s already defined.
It appears that within the Infoblox configuration (as property of the subnet) you can select an option called “Generate Hostname”. This option generates a Hostname if this isn’t sent by the client as shown on the screenshot below.
Since we want Infoblox (DHCP/DNS) to be in charge of the Hostname definition we disabled the “Generate Hostname” option which ensured that the DHCP Option “host-name” isn’t send anymore. Consequently this solved the problem since the ESXi Host is started doing a Reversed DNS lookup again at boot (or when the Management Network restarts)
