I recently changed the IP schema of my network from 192.168.x.x to 172.x.x.x due to addressing conflicts. I'm using this in a home environment for personal use, but I also support remote sites for work and I kept having issues with my home network clashing with work site IPs. Ever since this transition, I am only able to open VM consoles if I log in using the FQDN, but not is I log in via IP.
ESXI old IP - 192.168.1.20
ESXi new IP - 172.16.1.20
ESXI FQDN - esxi.kurort (DNS resolution works perfectly and resolves to the new IP)
VM1 old ip - 192.168.1.31
VM1 new IP - 172.16.1.31
ESXi and all VMs get their IPs via DHCP using reservations. They pick up the correct IPs, and they are all accessible perfectly fine both via IP and their specific FQDNs.
If I log into ESXi using the IP address (172.16.1.20), the little console preview just spins and never loads a screenshot, and VRMC times out and then errors with:
"Failed to connect to 192.168.1.20: Invalid or expired session ticket"
Note that the user account seems to be "stuck" with the old IP as well.
If I log into ESXi using the FQDN (esxi.kurort) I have no problem using the consoles, and both browser and VRMC consoles work fine.
How can this be fixed?
"Did you restart management agents since making the change?"
Yes, I have, and rebooted ESXi completely as well.
"I know you corrected the DNS A Record but do you also corrected the PTR record?
Make sure you only have on PTR record pointing to that name."
172.16.1.20 is the correct IP for the ESXi web interface. I've also changed the router and DNS servers since the IP change, and the new DNS server was set up with the new IP schema from the beginning. (The pihole is just there for basic ad filtering - the authoritative DNS for my LAN is running on the router itself upstream of the pihole, and I've cleared the DNS caches on the pihole.) This issue has actually persisted for a couple months, but I just now got around to being able to address this, what with covid insanity at work.
This is how it looks when I log in via domain name. When I log in this way, the consoles work perfectly.:
Could it be that the certificate you are currently using on the ESXi has the old IP on it?
If you open the DCUI do you see the new IP reflected?
Also check the /etc/hosts file inside the ESXi, maybe the old IP is also referred there.
DCUI is showing the correct hostname (esxi) and the correct IP: 172.16.1.20 (DHCP)
I never generated a cert for it, since I'm using it at home. The cert shows that it is signed for "localhost", and I've been ignoring the warnings ever since I've installed it.
Curiously, the hosts file in esxi has a single line that isn't commented out:
172.16.1.20 esxi.kurort esxi
This must have been automatically generated because I didn't put that there. In any case, that's the right IP address anyway.
I appreciate the suggestions! Thank you.
The system has a reserved address in DHCP. I have several devices, such as a couple printers, servers/software that I and my family interact with regularly, and other supporting scripts and servers that to refer to each other by FQDN without having to actually maintain hosts files everywhere or create or manage entries manually in the DNS server. Leveraging DHCP with reservations allows for the DNS to "read" the DHCP leases and the DNS lookups work fine and update if I change the IP reservations. I can change the IP addresses easily in one central location and not have ot worry about remembering where all of the static IPs are. It really only breaks a couple scripts that can't use FQDN and ESXi - everything else works fine. It makes using certs easier, even if I don't use one for ESXi.
I can't believe that I'm the only one using DHCP reservations with ESXi.
Setting the IP statically and restarting the management service does not resolve the problem. It behaves exactly like it did with DHCP with a reservation. I reset it back to DHCP.
I just did exactly the same as you did in my Lab but with ESXi 6.5 and it worked without any issues. I connected to the ESXi using the IP and it was reflected there even without restarting the management agents. This could be a bug in the version that you are running (my thought).
I do not know your environment and is it possible to do it but did you try the "Reset System Configuration" or are least try the "Restore Network" options. Maybe some got stuck in the process of changing the IP and this could be the solution without breaking your head too hard.
Both of these options could be find accessing the DCUI directly using IPMI or with SSH and run "dcui" (If you choose the last option you will lose management and connecitvity from the ESXi as it will restart)
Thank you, Lalegre. I'll give that a shot the coming weekend if it's not too drastic and won't require too much re-configuration. I'll have to read up on what the resets actually do.
Did you try changing the IP of the server? If you change the IP, does it retain the prior one or does it track with the change?
I installed ESXi 5.5 several years back, and this installation has actually been the same one just with 4-5 updates in the interim to get to ESXi 6.7. I changed the IP after the upgrade to 6.7. It's not inconceivable that some setting that was set back in 5.5 or 6.0 is "stuck" due to some deprecated setting somewhere and 6.7 can't change the IP address properly. It's an irritating issue.
Actually i did the change of the IP from the DCUI and it tracked with the change immediately.
On the network restore option you will have to configure most of the networking part again and on the reset system it will wipe the configurations so you will have a new ESXi image.
Please before doing try to trigger this command: /sbin/auto-backup.sh. This re-applies the configurations on the ESXi and writes everything again on the state.tgz that is read at the boot. I am not sure that is going to work as you rebooted the host but just give it a try.
Hope it works for you!