Blog

Sometimes it happens, for some reason, you need to move your VMWare hosts to a new subnet. Let’s talk about what you might want to consider and how to make the process as smooth as possible.

What to Consider Before you Begin

A big reason I’m putting this blog together is because I learned that some backup software (Veeam is one) utilizes VM IDs to track backup jobs. You can identify your VM ID by managing a VM from vCenter’s vSphere Client and looking at the URL in your browser. In the example below, the ID is “vm-204”.

It’s true that you could just remove the host from vCenter and add it back in without too much impact to your VM’s, but if you do that, you’ll be unable to use vCenter’s HA or DRS along with some other great benefits until it’s re-added. Additionally, the VM’s on the host will receive new VM IDs which might require you to recreate all backup jobs and take another first full backup before taking advantage of differential backups and deduplication. With a little preparation on your IP change, hopefully you can avoid this. It might be a good idea to spot check a couple VM’s and note down their VM ID’s to check again after the change.

One other consideration is how your hosts were added to vCenter. Was it by IP address or FQDN? You can find that out in the inventory view in the vSphere Client.

Preparations

To prepare for the change, first make sure the networking is ready. If you’re moving to a new VLAN, you should check the switch port(s) your host(s) are connected to upstream to verify it’s configured as a trunk port with all VLANs that will be used for management, storage, and VMs. If you separate out a physical connection for management, you’ll only need to focus on that one for this exercise. Next, make sure the IP address(es) you plan to use aren’t already in use (I do the trifecta check – ping, http/s, ssh). If only I had a nickel for every time I got a response from an IP address that wasn’t supposed to be in use, I’d have at least a dollar!

If your hosts were added by FQDN, be sure you have access to your DNS server(s) and a good understanding of which DNS servers will be used by your hosts and vCenter.

Let’s Change Some IP Addresses

Here’s a quick checklist on what we’ll need to do:

1. Disable DRS and any monitoring you may have
   
   
2. Migrate all running VM's off a single host
   
   
3. Put that host in maintenance mode
   
   
4. Change Internal DNS for host to new IP (if added via FQDN)
   
   
5. Change IP address from console (like KVM from host out-of-band management)
   A. Change VLAN if necessary
   B. Change IP Address
   C. Change Default Gateway
   
   
6. Flush DNS from vCenter by running the following commands from host CLI (if added by FQDN)
   A. service dnsmasq restart
   B. systemctl restart systemd-resolved
   
   
7. Connectivity tests (name lookups only required if added by FQDN)
   A. Verify IP ping from host to vCenter and vice versa
   B. DNS lookup of host from vCenter CLI [ nslookup hostfqdn.dom.ain ]
   C. DNS lookup of host from DNS servers
        i. You can get vCenter’s DNS servers from CLI with [ esxcli network ip dns server ]
        ii. Go into nslookup with [ nslookup ]
        iii. Change to each server from the nslookup prompt with [ server ser.ver.ipa.ddy ]
        iv. With each server specified, look up the host [ nslookup hostfqdn.dom.ain ]
   
   
8. Take host out of maintenance mode

              NOTE: At this point when I used vCenter 8, host showed disconnected in the vSphere Client until I clicked "Connection->Connect" on the host, then it disconnected for 10-15 minutes and reconnected again on its own. I can only assume that vCenter had some kind of cached server connection (maybe name resolution related) that takes that long to clear out.

9. Migrate one test VM to the host and verify connectivity
   
   
10. Return to step 2 until all hosts have had IP addresses changed
    
    
11. Enable DRS
    
    
12. Perform a health check on cluster and each host
    
    
13. Update IP addresses in any monitoring and documentation

It’s a fairly straightforward process, but like so many other things we do, the devil is in the details. I hope going through this guide helps you develop and find confidence in your plan and maybe even helps you to think about something you may not have thought of otherwise.

LookingPoint offers multiple IT services if you’re interested. Want more information, give us a call! Please reach out to us at sales@lookingpoint.com and we’ll be happy to help!