DNS resolution fails in VMware Live Recovery Appliance

Products

• VMware Live Recovery

Issue/Introduction

Newly deployed VMware Live Recovery Appliance or Protection and Recovery Appliance may experience a significant delay (approximately 15 minutes) during the initial boot sequence before networking becomes available. Once the appliance is accessible, DNS resolution fails completely, and the /etc/resolv.conf file may appear empty or point to a local stub listener (127.0.0.53).

Symptoms:

• The VAMI displays the correct DNS server configurations.

• The /etc/resolv.conf file appears empty or does not contain the configured DNS servers.

  cat /etc/resolv.conf
  This is /run/systemd/resolve/stub-resolv. conf managed by man:systemd-resolved (8).
  Do not edit.
  
  This file might be symlinked as /etc/resolv.conf. If you're looking at
  /etc/resolv.conf and seeing this text, you have followed the symlink.
  
  This is a dynamic resolv.conf file for connecting local clients to the
  internal DNS stub resolver of systemd-resolved. This file lists all
  configured search domains.
  
  Run "resolvectl status" to see details about the uplink DNS servers
  currently in use.
  
  Third party programs should typically not access this file directly, but only
  through the symlink at /etc/resolv. conf. To manage man:resolv. conf (5) in a
  different way, replace this symlink by a static file or a different symlink.
  
  See man : systemd-resolved. service (8) for details about the supported modes of
  operation for /etc/resolv. conf.
  
  nameserver 127.0.0.53
  options edns0 trust-ad
  search

• Manual edits to /etc/resolv.conf are lost immediately after a reboot or a restart of the systemd-networkd service.

• VMWare Live Recovery plan task also fails with error "Failed to connect to NFC service: Temporary failure in name resolution".
  
  
• nslookup fails for destination hosts even when network connectivity exists.
  

  nslookup 10.#.#.#
  server can't find #.#.#.10. ####: NXDOMAIN

Environment

• VMware Live Recovery 9.0.4, 9.0.5
• Protection and Recovery 9.1

Cause

The issue is caused by a configuration conflict between the OS-level systemd-resolved service and the symbolic link for /etc/resolv.conf.

By default, the appliance points to /run/systemd/resolve/stub-resolv.conf. In certain deployment scenarios, this stub file fails to populate with the DNS metadata provided by the VAMI/network configuration. Because the OS attempts to reach network resources during boot, the lack of DNS leads to a 15-minute timeout before the timeout threshold is reached and the boot process continues.

Resolution

To resolve this issue, the symbolic link for /etc/resolv.conf must be redirected to the static resolv.conf file, which bypasses the local DNS stub listener.

1. Log into the VMware Live Recovery Appliance via console or SSH as a user with root privileges.

2. Remove the existing problematic symbolic link:

   unlink /etc/resolv.conf
   

3. Create a new symbolic link pointing to the correct systemd-managed resolution file:

   ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
   

4. Restart the networking services or reboot the appliance to verify the fix:

   systemctl restart systemd-networkd

Additional Information

Persistence: This change ensures that DNS settings remain persistent across reboots, as the OS will now pull directly from the configuration managed by the system rather than the dynamic stub resolver.

Verification: After applying the fix, run cat /etc/resolv.conf to ensure your DNS servers are correctly listed.

For assistance with log retrieval, see Collecting logs for VMware Live Recovery.

To speak with a representative, see Contact Support.