How DNS works in EVO:RAIL
One of the big differences in how vSphere works as deployed by EVO:RAIL is with DNS. As you might know vSphere has many requirements for name resolution, and often various vSphere features will not function or setup correctly without DNS being available. A classic example is simply opening a Remote Console window on a VM. Although that request might be triggered from a vCenter session, it’s actually the VMware ESXi host that handles the redirection of the video, and allows for Keyboard, Mouse and Screen (KMS) functionality. Remote Console sessions require name resolution to the VMware ESXI host to work. I could go on at length with other examples but you get the picture.
The good news is the EVO:RAIL Appliance takes care of all these requirements. In fact EVO:RAIL has its own built in DNS service. This means that there are no service dependencies required to setup the appliance at a green-field location. That’s right, the EVO:RAIL appliance will configure itself – even if there’s no DNS, DHCP or Active Directory.
This does mean that the way name resolution is achieved is different from standard vSphere as deployed manually by customers. With vSphere the path of the name resolution from the VMware ESXi host is via its management network. For example after installing VMware ESXi the customer assign a static IP address and configures the VMware ESXI host for its Primary and Secondary DNS, as well as its domain suffix, using something like the Direct Console User Interface.
In this case the VMware ESXI host queries the corporate DNS server directly. With EVO:RAIL this behaviour is similar, but different. The EVO:RAIL Configuration Engine will set static IP addresses for the ESXi management network and also set the preferred DNS settings – however, what is queried is the built-in DNS Server of the EVO:RAIL.
So in this case the DNS query takes this path:
ESX Host >> vCenter Server Appliance DNS Service >> If not internally resolved forward it is forwarded on to the corporate DNS server.
You can tell that a DNS service is running with the vCenter Server Appliance using the command “netstat –natlp | grep ‘:53’. As you might know all DNS queries are responded to by listening on TCP port 53. This will show that there is a “dnsmasq” service running.
The dnsmasq service holds hostname records in a text file on the vCenter Server Appliance /var/lib/vmware-marvin/dnsmasq/hosts. Usually, this will contain at least the four VMware ESXI hosts that make up the EVO:RAIL Appliance together with the IP address and FQDNs for the vCenter Server Appliance. In the new release of EVO:RAIL we will have a dedicated virtual appliance for managing the physical appliance that we are calling the “EVO:RAIL Orchestration Appliance”. You can see it listed in the screen grab as evo04-evorail.vsphere.local.
If you add a second appliance to double your compute and storage resources the hosts file would be updated to include those FQDNs for the new ESXI hosts. In the example above, no corporate DNS server was specified, so the EVO:RAIL dnsmasq service is the source for all queries. It’s rare to actually need to modify this file, although one situation could happen is if you decide to change the management IP or FQDN of the servers listed here.
As for the forwarding of queries for systems not listed in the hosts file – that’s held in file dedicated to the dnsmasq configuration. So its not the usual /etc/resolv.conf file that usually holds the DNS Primary/Secondary IPs for Linux. The file used is called /etc/dnsmasq.conf held within the server= setting. We do have KB Article 2107249 (http://kb.vmware.com/kb/2107249) which describes the file and how to edit it. For instance you may wish to change the corporate DNS server entry if the IP address for the DNS service has changed or if you have fat-fingered the setting.
So to summarize. EVO:RAIL has its own DNS service that allows us to meet the requirements of vSphere for DNS. That’s ideal for greenfield deployments because we have no dependency on DNS, DHCP or Microsoft Active Directory. You can, of course point the EVO:RAIL DNS service to an ‘external’ or corporate DNS server for all other queries.