Related to KB article: 'DataCenter 8 GUI requires Command Server DNS Address (host name) to connect'.
The host names of the machines involved in the backup must be resolvable to IPv4 address. In basic terms, the host names of all client nodes involved in backup need to be resolvable to an IP address from the Command Server, otherwise backups and connectivity tests will not work properly. This requirement exists whether the node is a basic client node or a client node which is enabled as a backup server. This requirement did not exist in earlier versions of the DataCenter product, it started in version 8. This would apply to any client node which you have added to the Nodes Management area of the Command Server GUI, whereby the Default Address property of the node is assigned by IP address. This could be because the host name does not exist in a DNS server utilized by the Command Server machine, possibly because these nodes are located at a remote site and they were originally added by IP (which earlier versions of DataCenter allowed to work), or a Linux machine which often cannot resolve by host name and is connectable only via IP. To test this go to Nodes Management and note the values shown in the 'Default Address' column of each node, if the value of the 'Default Address' for a node uses the IP address format then those nodes will need to be edited to make their Default Address equal to their host name. To test this out, from the Command Server machine, for each node that is using an IP address for its 'Default Address' please ping the value in the 'Host Name' property of each node to see if it can resolve the host name to the correct IP address. If the Command Server is not able to resolve each node's host name to the correct IP address then those node entries will need to have two things done, either add them to your DNS server in the local environment which the Command Server utilizes as a DNS server, or add them to the Windows hosts file on the Command Server machine directly, so that they can resolve by host name to correct IP address (instructions as a how come later in this article). The last thing to do is to edit the properties of that node by right-clicking that node in Nodes Management and performing an 'Edit Node' > Configure Address > Manage Addresses function, to change the 'Default Address' to equal the host name, by copying the value from the Host Name field and pasting it in to the 'Default Address' field and then place the same host name value into the "Display Name" field if it contains an IP address presently.
We often see cases where versions DataCenter older than DataCenter 8 contain a mix of nodes, usually some nodes exist that are located on remote sites, and those nodes that were located on the remote sites were added based on their IP address, and not host name (DNS name). Those remote nodes were added to the Command Server using an IP address for the 'Default Address' property of the node, this is the primary example where those nodes won't be able to perform backups or connectivity tests, just because the Default Address property is based on IP address and NOT host name. There usually is not an issue upgrading those legacy nodes (when it comes to DataCenter 8, a legacy node is simply a node that is not yet running version 8), so the DataCenter 8 Command Server can normally perform the upgrade via the Update Nodes function to get that legacy client upgraded to 8, and it can complete that node update. Even if it does update the node to DataCenter 8 it still requires resolving the host name based on the 'Default Address' property, so if that is not changed it will fail backups and connectivity tests.
From the Command Server machine you would need to be able to ping the host name of all clients and have it to resolve to the IP address which is specified as the "Default Address" property of the node. This differs from versions of DataCenter prior to version 8, where it did not require host name resolution for nodes involved in backup. You will either need to add a DNS "Host A" record entry on your DNS server(s) for each client node, which contains the host name and the IP address that the Default Address property is set to when viewing the node's properties, or you can simply add a hosts file entry to map a host name to an IP address in the Windows hosts file on the Command Server machine only.
This would apply to any client node where the Default Address property for the node is using an IP address. Alternatively, the Windows hosts file on the Command Server can be used for host name mapping and that also works equally as well. The need to do this appears to be less of an issue if the Windows OS is more modern (at that point the client node host name is being read and resolved via NetBIOS from the Command Server properly). If you have an issue with Connectivity Test, or a backup log that shows "Failure: failure" for the contents, where it appears the data mover process is working to backup selected files, an .SV file (backup file) is created in the target disk pool, but in the end no Restore entry exists for that failed backup, take a look on the Command Server to see if you can resolve the host name (DNS name), via 'ping hostname'. If the host name cannot resolve to the IP address that was specified in the Default Address property of the client node, then that is likely why this failure is occurring. On the Command Server machine you can try to perform a "ipconfig /flushdns" and then "ipconfig /registerdns" via an Admin Command Prompt, and then try that same ping command again. The host name will need to resolve to the IP address that was utilized as the Default Address if using an IP address (and not a DNS address) there.
There should be nothing necessary to change on the client node machines, but to confirm, you should attempt to resolve the host name of the Command Server from each of your client nodes, to make sure that each client node can communicate to the Command Server by way of the Command Server's DNS address. This would be more important if the Windows machine was in a WORKGROUP or it were a Linux machine that does not utilize NetBIOS for host name translation (a hosts entry in /etc/hosts file in Linux could be created in that case to map the Command Server's IP to DNS address, the format of the hosts file entry is the same regardless of Windows or Linux). So example 'ping commandserver', where commandserver is the host name of the Command Server. That needs to resolve and show you a valid IP address and ping response that correlates to the Command Server.
Example node properties for our Linux node, as seen when initially adding the node via Nodes Management, showing the Linux node being searched for by IP address at the top, after clicking "Fetch" button, in this case we change nothing about the Node Info after it is fetched when we add the node:
Example node properties for our Linux node, as seen when editing the node only to view the address properties in "Configure Address" via Nodes Management, showing the "Default Address" property at the top which contains the IP address of the Linux client node:
Example ping command from the example Linux node:
PING commandserver.sv.novastor.local (192.168.0.123) 56(84) bytes of data.
64 bytes from commandserver.sv.novastor.local (192.168.0.123): icmp_seq=1 ttl=128 time=0.318 ms
64 bytes from commandserver.sv.novastor.local (192.168.0.123): icmp_seq=2 ttl=128 time=0.303 ms
The client nodes should all be able to resolve the host name of the Command Server machine. If they cannot then something is either incorrect in DNS or other methods of name resolution, and either the DNS entry needs to be corrected on the DNS server, or a hosts file entry will need to be added to the respective hosts file on each client node machine. Both Windows and Linux can utilize a local hosts file, and details on how to do that follow.
How-to Instructions / Steps:
You will need to create a DNS "Host A" record on the primary DNS server which your Command Server and client nodes utilize as a DNS server. Alternatively you can create a Windows hosts file on the Command Server itself, and add an entry for each client node, to map the host name to the IP address (the IP address there would be what is specified in the Default Address property for the node) of the node, and that will work as well. How to do this is detailed below.
On your Windows Command Server machine, backup the C:\WINDOWS\System32\Drivers\etc\hosts file as hosts_backup. Then edit C:\WINDOWS\System32\Drivers\etc\hosts in notepad or in NotePad++ (better), and then add a static hosts entry per client node. For a Linux Command Server machine, the hosts file is /etc/hosts. The format is the same for both Windows and Linux for the hosts file. Note: Make sure that after making your changes, that the file actually saves, so edit it twice, the second time to verify the contents, and if it is saved you can test it by pinging the host name now from the Command Server to see that take affect instantly. Some good third party tutorials on understanding and using the hosts file are here, and here. An example hosts file that contains some host entries discussed in this article is here:
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
192.168.0.111 vm1-srv2019
192.168.0.112 vm2-srv2019
192.168.0.126 jf-ubuntu2004lts
For a Linux client node you are doing the same thing except that you will likely also need to create a Linux hosts file entry for your Command Server node (as it's likely your Linux client machine does not have NetBIOS capability like your Windows machines do to resolve host names, like your Windows machines are able to, unless every Linux machine in your environment is able to resolve via DNS to talk to the Windows machines and vice-versa). You can test that out by pinging your Command Server node by its host name, in our example that host name is "commandserver". The Linux client node will need to be able to resolve the host name of the Command Server to the correct IPv4 address, otherwise you may find that both the Connectivity Test function and backups will fail. This can be done by editing the /etc/hosts file on the Linux client node(s) to map the IP and host name of the Command Server node as a new hosts entry there. This is the Linux example:
The first portion of the Windows or Linux hosts file entry is the IPv4 address of the client node, which is the preferred IP to communicate with the node, as configured in the Default Address portion of the node in Nodes Management:Edit Node. The second portion is the computer name, which is what is displayed as the "Host Name" value in Nodes Management:Edit Node. The host name is the computer's name, without the DNS suffix added. Add every client node that you are using that technique with (where the Default Address = an IP address and not DNS address) as a static Windows hosts file entry on the Command Server in question.
After saving the hosts file entry to the Windows hosts file, go back into the Admin Command Prompt session on the Command Server and perform an "ipconfig /flushdns" and then "ipconfig /registerdns" via an Admin Command Prompt. Now to attempt to resolve the client node host names again via 'ping hostname' command, so 'ping vm1-srv2019' and 'ping vm2-srv2019'. If not, go back and verify the contents of that host record either in the DNS entry on the DNS server that it exists at, or the Windows hosts file on the Command Server. You should be ready now to test perform a connectivity test and run the backup job. Here is an example step-by-step operation performed on the Command Server machine via an Admin Command Prompt. In this case we do not have a DNS entry on any of our local DNS servers for the example Linux client node to be able to ping it by host name from the Command Server, so it fails the first time:
