Subnet migration best practices
-
I have to migrate a whole vmware-based environment (vcenter, mani esxi hosts) with AD domain that also host DNS and dhcp to a new and bigger subnet. Today everything is on 192.168.0.0/24 (old consumer router bad habit), I want to move all to something like 10.45.1.0/22 (so, over 1k usable IPs). I can put the whole environment down for a couple of hours at maximum. It's mainly windows-based and everything authenticate through AD.
There's also a VMware Horizon (ex View) client pool, with two connection servers.Now, I have some doubts on the best practices to follow regarding this migration, for example, how to change the vCenter subnet without losing the Horizon functionality? Should I reconfigure everything in a DNS-based fashion? What about the DCs (there are two in production)?
-
Moving the DCs is pretty easy. The biggest question is "How much of your environment is under DHCP?" If everything is handled by DHCP, then you are in great shape. This is quick and easy. If lots of stuff is static, you have quite a chore ahead of you.
-
I agree with you in general terms; but, for example, what about the ESXi hosts? If I add them to the vCenter using FQDN, I will completely rely on the DNS servers, that are both running in Windows VM that rely… on the ESXi hosts! In case of complete reboot or full power loss of the infrastructure, they will have to wait the DNS to come before being added to the vCenter. There is something that does not convince me…
-
@Francesco-Provino said in Subnet migration best practices:
I agree with you in general terms; but, for example, what about the ESXi hosts? If I add them to the vCenter using FQDN, I will completely rely on the DNS servers, that are both running in Windows VM that rely… on the ESXi hosts! In case of complete reboot or full power loss of the infrastructure, they will have to wait the DNS to come before being added to the vCenter. There is something that does not convince me…
That has nothing to do with a subnet migration. You have that same problem right now. The mitigation for that of course is to have your two DC's on different hosts so that one of them is always available.
-
@Francesco-Provino said in Subnet migration best practices:
I agree with you in general terms; but, for example, what about the ESXi hosts? If I add them to the vCenter using FQDN, I will completely rely on the DNS servers, that are both running in Windows VM that rely… on the ESXi hosts! In case of complete reboot or full power loss of the infrastructure, they will have to wait the DNS to come before being added to the vCenter. There is something that does not convince me…
But the start running before they are in vCenter. vCenter is just for your access, not for the systems to come online. That's just a normal delay in a full system restart.
-
@scottalanmiller @JaredBusch I think you're both right.
I think I will go with an additional static vmkernel interface in case of a disaster (so no DC and no DHCP-DNS of course). -
Changing the IP scope used is a hard down scenario. It is really not all that difficult to handle, but it is certainly a hard down setup.
Changing the IP scope is quite easy, but like anything, you have to pay attention to the details.
Before you begin, document
- your edge router/firewall
- all the devices with static IP addresses
- your DHCP scope
The process
- Most routers can have multiple IP addresses on an interface, so you can simply add the new address to the current LAN interface and things will just work.
- For your devices with statically assigned IP's, you will have to be prepared to change all of these devices at once.
- With your DHCP scope, if it is a Windows DHCP server, you can export the entire scope to a text file, hand modify it to change everything to the new scope and then reimport it. I like this method personally. Some other prefer to simply add a second scope to the DHCP server. I have always had more problems with that than simply export/delete/import.
It is much better, IMO, to plan a two to four hour outage for this instead of trying to work with a minimal downtime window.
Start by modifying the firewall, then the static devices and then the DHCP scope.
You need zero access to vCenter for anything.
- Just shut down all the VM's that get DHCP assigned IP addresses
- Change the DHCP server to have the new scope (but leave the DHCP service stopped)
- Change the VM's with static IP's and then shut them down.
- Change the ESXi hosts to the new static IP range.
- Reboot the ESXi hosts. Everything will come back up on the new IP block, including the once that get reserved DHCP addresses.
By the way, this is why almost all of my server VM's have DHCP reservations. Unless it is a DC or something truly critical to the business, they are all DHCP reservations.
-
@JaredBusch Thank you, very helpful tips!
