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.
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.
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.
Here’s a quick checklist on what we’ll need to do:
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.
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!