Upgrading vCenter 8 to vCenter 9: Fixing a Stage 2 Precheck DNS Resolution Error

The real issue was a hostname validation failure inside the upgrade framework:

socket.gaierror: [Errno -5] No address associated with hostname

What made this annoying is that from the target VCSA 9 appliance, the hostname appeared to resolve when I tested it manually.

Here’s how I found the real error and the quick fix that got Stage 2 moving again.

The actual error is in the upgrade runner log

On the target VCSA 9 (the appliance deployed in Stage 1), the most useful log was:

/var/log/vmware/upgrade/requirements-upgrade-runner.log

To quickly pull the important lines:

grep -nEi "error|exception|traceback|fatal" /var/log/vmware/upgrade/requirements-upgrade-runner.log | head -n 80

Example output (this is what blocked Stage 2 for me):

25:2026-01-08T06:24:56.5Z ERROR networking_utils Could not validate host nuc.virtuallywired.io: [Errno -5] No address associated with hostname
26:2026-01-08T06:24:56.5Z ERROR UpgradeRunner Upgrade Runner has encountered an exception
27:Traceback (most recent call last):
...
40:socket.gaierror: [Errno -5] No address associated with hostname

Later runs showed the call path that fails (canonical hostname validation):

2026-01-08T06:44:14.513Z ERROR networking_utils Could not validate host nuc.virtuallywired.io: [Errno -5] No address associated with hostname
Traceback (most recent call last):
  ...
  File ".../networking_utils.py", line 143, in getCanonicalHostname
    info = socket.getaddrinfo(host, None, 0, 0, 0, socket.AI_CANONNAME)
  ...
socket.gaierror: [Errno -5] No address associated with hostname

At this point, the UI error makes sense: Stage 2 prechecks can’t proceed if the upgrade framework can’t validate the target host name.

“But it resolves” (manual checks looked fine)

From the same target VCSA 9 appliance, basic resolution looked OK:

getent hosts nuc.virtuallywired.io
nslookup nuc.virtuallywired.io

Example output:

172.18.9.190    nuc.virtuallywired.io
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   nuc.virtuallywired.io
Address: 172.18.9.190

I also tested the same Python resolver call used by the upgrade runner:

python3 -c "import socket; print(socket.getaddrinfo('nuc.virtuallywired.io', 443))"

Example output:

[(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('172.18.9.190', 443)),
 (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, '', ('172.18.9.190', 443)),
 (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_RAW: 3>, 0, '', ('172.18.9.190', 443))]

So why did the precheck still fail?

In my case, name resolution was effectively not deterministic enough for the upgrade framework. Even if it resolves in an interactive shell, the precheck can still fail if the resolver chain returns inconsistent results at the moment the upgrade runner does its canonical hostname validation.

The quick lab fix: Pin the hostname in /etc/hosts

To remove DNS from the equation during the upgrade, I added a static mapping on the target VCSA 9:

echo "172.18.9.190 nuc.virtuallywired.io nuc" >> /etc/hosts

Then I confirmed the resolver order checks local files first:

grep -n '^hosts:' /etc/nsswitch.conf

*Example output:

7:hosts: files resolve dns

With that in place, both resolution paths became consistent:

getent hosts nuc.virtuallywired.io
python3 -c "import socket; print(socket.getaddrinfo('nuc.virtuallywired.io', 443, 0, 0, 0, socket.AI_CANONNAME))"

*Example output: 172.18.9.190 nuc.virtuallywired.io nuc [(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, ‘nuc.virtuallywired.io’, (‘172.18.9.190’, 443)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, ‘’, (‘172.18.9.190’, 443)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_RAW: 3>, 0, ‘’, (‘172.18.9.190’, 443))]

**After that, I reran Stage 2 prechecks and the upgrade continued normally.**

Conclusion

If you see:

• Could not validate host ... No address associated with hostname
• socket.getaddrinfo(... AI_CANONNAME)

…then forcing deterministic name resolution via /etc/hosts on the target VCSA 9 can be a fast lab workaround to get through Stage 2.

(For production, I’d fix the underlying DNS inconsistency rather than relying on /etc/hosts long-term.)