Cloning and running a duplicate vCenter instance on the same network – process and gotchas

Recently I needed to clone a vSphere environment (vCenter 5.0.0) for testing purposes. This environment needed to be cloned to have an exact replica of the vCenter server and SQL database server for various tests/upgrades to be performed on it. As for ESXi hosts, a few were being split off the original environment and added to the duplicate vSphere environment.   All the Windows configuration and SQL server configuration needed to be retained, so my high-level plan was as follows:

  • Deploy a new Windows domain (it had to be the same domain functional level and the DC needed to run the same OS as the original)
  • Hot cloned the existing production vCenter and SQL servers
  • Split off the few ESXi physical hosts that were going to be added to the newly cloned environment later on (removed from prod clusters)
  • The new machines needed to run on the same VLAN and IP ranges as the originals too, which made things even more complex, so I made sure to keep the vNICs in the SQL and vCenter cloned VMs disconnected, and disconnected on start up too.
  • Re-IP the cloned VMs after powering them up on one of the split off ESXi hosts (logged in to vSphere client using root credentials) I also re-named their host names and removed from the old domain in, rejoining to the new domain at the same time.
  • Created new service accounts on the newly deployed domain, and reconfigured vCenter services to use these on the cloned machines
  • On the vCenter server there were some changes needed in vCenter config files. This post details most of what needed to be changed:
  • The main change for me though, was I couldn’t see (or didn’t know) how an existing vCenter SQL database would re-act when starting the cloned vCenter on the same VLAN and IP range! There was a strong possibility that this cloned instance could start interfering with the production vCenter and performing operations cross environment. Therefore I decided to create a new SQL vCenter DB. I logged into the cloned vCenter and deleted the old SQL System DSN pointing to the production SQL DB, and created a new SQL database on the cloned SQL box. I then created a new DSN pointing to this, and made sure I searched around for all configuration files on the vCenter server that pointed to the old DSN/SQL server. (I recall there being some references in registry and possibly the vpxd.conf file).
  • Re-creating the right SQL database structure was a bit of a task though. I needed to re-create the structure of the DB without doing an install of course, as I was using the cloned SQL and vCenter machines – with an existing installation on. I followed this KB article, but found a couple of errors/typos in the SQL queries: //pubs.vmware.com/vsphere-50/index.jsp#com.vmware.vsphere.install.doc_50/GUID-F953497E-2170-4168-806F-6FF0EA6497A7.html by looking at the errors returned in SQL Management studio, you can start to determine where any issues come up and fix the typos. Unfortunately I did not document them myself as I sorted through!
  • Once I was finished with the renaming and IP changes for the cloned machines, I re-connected their vNICs to the relevant networks – happy that they were sufficiently changed!
  • My last issue I came to was that the schema I deployed was one version higher than the vCenter Server build version I was using. I found this out by looking at the vpxd.log file when vCenter failed to start up after deploying the new database schema and content. I fixed this by fudging the version in the database – essentially hard coding the version it wanted into the newly created schema – my thought was that the schema wouldn’t have changed anything old, but rather added new features, so it should be OK. I was right – vCenter started up just fine after this, but I wasn’t happy, so I stopped the services again, deleted the DB, and started again, this time using the right scripts (the scripts referenced in the article link above are located on the vSphere vCenter ISO / media). I had used an ISO with a build increment one higher than the vCenter build I was working with on the cloned VC!) So make sure you use the correct media for your vCenter install here. (I had a vCenter 5.0.0 install, but had deployed schema for 5.0.1!)

 

Hopefully that gives some ideas as to the tasks required when attempting to clone / duplicate an existing vCenter installation, whilst keeping

2 Comments

  1. Hi, came across your post as and wanted your feedback as i was doing something similar.

    We have a vCenter server (VM) with it’s DB that resides on server 2008r2 box with SQL 2008r2 ENT. Our environment is currently on ESXi 5.1 and i’m planning to perform an upgrade to 5.5. In order to perform a flawless/hassle-free upgrade i’m setting up a test environment in which i’ll be simulating the upgrade. My setup in the test lab would be like this:

    •New vCenter 5.1 server (with SSO) (lets call this server test-VC)
    •New test SQL server (lets call it test-SQL)
    ◦Attach a COPY of the Production vCenter database to the NEW test SQL server
    •Make a ODBC connection from test-VC to the DB on test-SQL server (that will have a COPY of the production vcenter DB)

    Here are my questions:
    •Will this work given that production vCenter server and DB will be live – there will be 2 databases concurrently running!
    •Will this impact the production vCenter server or the production DB?

    I’m curious how the enviornment can get managed as there will be 2 vcenter servers and 2 DBs that will be fully populated w/ hosts, VMs, switches etc.. which vcenter gets to manage them?

  2. Hi mujurip,

    In my case I also thought about this problem but decided I would be “safe” as I was firstly taking the cloned SQL database offline first, then creating a new SQL database on the same DB server, pointing the cloned VC’s ODBC connection to this new database and then starting up vCenter services. After that, I removed hosts from an existing “production” cluster, created a new cluster on the cloned VC, and added those hosts into that cluster.

    Essentially my testing ommitted the actual VC database content – I was starting fresh with a new one – this was specifically to avoid this kind of scenario you talk about (as I also had a feeling that there might be issues as to which VC controls which bits!) I’m sure there would be issues unless you were able to completely separate the two environments at the network/VLAN level, however even if you did, I think vCenter would complain about all these resources suddenly not being able to be contacted once you started up the network separated cloned version. Again, it was for these reasons I decided to rather setup a clean database and test the upgrade process using the actual Windows installations, and other installed vSphere components, but not the actual database itself.

    Hope that helps clarify things a bit for you.

    Sean

Leave a Reply

Your email address will not be published. Required fields are marked *

ERROR: si-captcha.php plugin: GD image support not detected in PHP!

Contact your web host and ask them to enable GD image support for PHP.

ERROR: si-captcha.php plugin: imagepng function not detected in PHP!

Contact your web host and ask them to enable imagepng for PHP.