Sooo… It’s Friday the 13th and you need to restore your vCenter server

I think it’s a safe bet to say that most of vCenter servers out there are virtualized nowadays. In the end if you trust Vmware to virtualize your mission critical business applications why not run vCenter in a virtual machine, especially that vCenter itself is not a critical component of vSphere infrastructure (unless you’re hosting/cloud provider using functionality like Chargeback etc).
So you’ve got your vCenter virtual, secured by Vmware HA and just to be on the safe side you create backup clone(s) of this server on regular basis.
Cloning vCenter for backup purposes is fully supported, about one year ago Artur posted a PowerCLI script to automate this task.

But then the Friday 13th comes, something bad happens, you can not get your vCenter running and you don’t want to leave your infrastructure “unmanaged” over the weekend, so you decide to use that backup clone and restore your vCenter.
You “power on” the cloned vm just to recognize that (if your vCenter is Windows – and I think large part of vCenter servers still is) your IP configuration inside Windows is gone :S.

This is because cloned vm receives new MAC address(es) for each virtual nic and subsequently Windows detects these vnics as new, unconfigured hardware (which makes some sense tbh).

Then you need to manually configure the IP settings of your vCenter, which is really annoying if you planned to go home early this Friday.

What about we extend the functionality of the script that creates the clone to also save IP configuration somewhere in a form that can be used to restore this settings by another script?
The only place to safely store this IP configuration file is of course vCenter itself, we assume no networking connectivity during restore, so it can not be network share of any kind and if we save this configuration file before making the clone it will be copied with the whole server, right?

Artur’s script after modification should look like this:

The IP configuration is exported to vcenter_nics_ipconfig.xml file (I assume you run this script from vCenter itself, as a Windows Scheduled Task probably) just before connecting vCenter to create the clone.

The restoring of this IP configuration can be somewhat tricky, mainly because Windows not only detects vnics as a new hardware but also (if you have more than one vnic in your vCenter) there is no easy way to detect the order in which they are connected (at least I couldn’t figure out anything workable, probably it can be done if you save also PCI IDs of your vnics along with IP configuration).

In general – there is no problem with vCenter that has one vnic only (obviously), when there are two vnics (like I usually have) the solution (or workaround to the problem) is fairly easy, you just try one order of configuration, test the connectivity (ping the default gateway probably – and there should be only one default gateway, right?) if it doesn’t work – just try the reverse order (and the script below does all of that for you)

The script is a bit interactive – it requires you to confirm you want to apply IP configuration stored in .xml file, I just don’t trust myself enough to let it run in fully automated mode (especially on Friday the 13th 😉 ).

It will probably not work (unless you’re lucky) with 3 and more vnics in vCenter – there is simply more than 2 possible permutations of vnics order, but why would you need more than 2 vnics in vCenter anyways? 😉

Also note that it doesn’t configure things like DNS search suffixes or persistent routes (if you have any), but it can be easily extended to do so.

I actually had “real life” opportunity to see this script working and it did it’s job – restored vCenter connectivity to the point where I could go home for the weekend and finish minor things (like these DNS suffixes) on Monday.

I hope you find this script useful, any comments are welcome!

Sebastian Baryło

Successfully jumping to conclusions since 2001.