Can you really deploy the vCenter Server Appliance (VCSA) without DNS and NTP?

The simple answer is Yes. Now, you might be wondering why anyone would want to put themselves through the pain without setting up proper DNS and NTP?

Well, not all environments have the luxury of having either outbound connectivity and/or access to basic infrastructure services like DNS and NTP. This may come as a surprise to some, but there are customers out there that need to operate in very unique and constrained environments. One such example of this is typically from customers that need to deploy vSphere in a "dark site" where local infrastructure services like DNS and NTP are not available.

I recently re-validated this deployment model using the latest vSphere 7.0 Update 3 release running on an Intel NUC 11 which had no outbound connectivity and it was only connected to my laptop, which also had no outbound connectivity or access to DNS or NTP. Since this question recently came up from a customer who was looking to automate this, so I ran through the deployment workflow using the VCSA CLI Installer but this should also be possible with VCSA UI Installer as the same options are supported.

OK, so how do you make this work?

NTP

Lets cover the easy one first. If you do not have an NTP server, you can simply configure the VCSA to sync with the underlying ESXi host which is a capability that is provided by VMware Tools, which the VCSA will be running. When using the VCSA UI Installer, you can specify the option as part of the Stage 2 configuration which occurs after the initial VCSA OVA is deployed. When using the VCSA CLI Installer, you simply remove ntp_servers entry and add the configuration setting time_tools_sync with value of true. If you plan on deploying an NTP server after your VCSA has been configured, you can always login to the Virtual Machine Management Interface (VAMI) of the VCSA and change the NTP configuration to sync to an external NTP server.

DNS

When it comes to DNS for the VCSA, there are two diffrent things to consider:

• DNS resolution of the VCSA itself
• DNS resolution of external systems and services

The first pertains to whether your VCSA will have a DNS entry in your DNS server that will allow you to resolve it by a fully qualified domain name (FQDN) rather than just an IP Address. Assuming you do not have a DNS server that will be used to configure an FQDN for your VCSA, then you can simply use an IP Address. This has been possible since the inception of the VCSA and when it asks for the system name also known as the Primary Network Identifier (PNID), you simply provide the IP Address. This is something I have used personally in my homelab for many years without any issues. If you decide to use an arbitrary FQDN which is not in your local DNS, then the VCSA will fail to load as the PNID is used throughout the VCSA configuration. One way that folks have workaround this issue when connecting to the VCSA from their workstation is to simply add an entry into their hosts file that maps the FQDN to IP Address. If you only have a single VCSA and you do not want to remember the IP Address, this can be helpful but I normally just remember the IP Address I use for VCSA 🙂

The second part deals with the DNS server that the VCSA will used for various DNS resolution such as how to reach VMware.com for patches, ESXi hosts connectivity if they were deployed with DNS entries and other services including its own DNS resolution. This is important because, you may not have your own DNS server that can resolve your infrastructure systems like the VCSA and ESXi hosts but you still can reach a DNS server like your local ISP or even Google's DNS (8.8.8.8), then you would use those addresses since the DNS server configuration is a required setting. Now, since we are talking about a dark site where none of this infrastructure exists, what value do you use here? Historically, I would normally use the network gateway as you need to provide an address that is reachable via ICMP. Since my setup was completely isolated and there is no real gateway, I decided to use the localhost address (127.0.0.1) which also works. In VCSA UI Installer, simply use 127.0.0.1 for DNS server and for VCSA CLI Installer, just update dns_servers setting.

If you look at what is actually needed to deploy a VCSA without a DNS and NTP server, it is pretty basic and in my opinion, pretty straight forward. I also know a number of customers who have been doing this for quite some time now. For those that have ran into issues, what I have seen in my experience is that incorrect values were used for either the PNID field and/or DNS server field which then caused an undesired behavior where VCSA is attempting to perform a lookup and of course, DNS is not available and fails the deployment.

For completeness sake, here is fully functional example of the JSON configuration that I had used to deploy my VCSA without DNS and NTP servers.

{
    "__version": "2.13.0",
    "__comments": "Sample template to deploy a vCenter Server Appliance to an ESXi host without a DNS and NTP server",
    "new_vcsa": {
        "esxi": {
            "hostname": "172.30.0.10",
            "username": "root",
            "password": "VMware1!",
            "deployment_network": "VM Network",
            "datastore": "datastore1"
        },
        "appliance": {
            "thin_disk_mode": true,
            "deployment_option": "tiny",
            "name": "VCSA-70u3"
        },
        "network": {
            "ip_family": "ipv4",
            "mode": "static",
            "system_name": "172.30.0.100",
            "ip": "172.30.0.100",
            "prefix": "24",
            "gateway": "172.30.0.1",
            "dns_servers": [
                "127.0.0.1"
            ]
        },
        "os": {
            "password": "VMware1!",
            "time_tools_sync": true,
            "ssh_enable": true
        },
        "sso": {
            "password": "VMware1!",
            "domain_name": "vsphere.local"
        }
    },
    "ceip": {
        "settings": {
            "ceip_enabled": false
        }
    }
}