Clone-to-test: Part 1

Well it’s taken me a while, but I’ve just completed the first part of my test environment migration process. So I thought I’d post up the design and architecture diagrams.

The idea is to provide a repeatable process for cloning batches of VM’s from the production network into my organization’s isolated vm-test environment. The cited use cases for this environment include Virtualization infrastructure change testing, VI development, VI product evaluation and Virtual Machine change test/verification. This series of scripts addresses the last requirement in an automated manner.

This post gives shows the high-level designs for the process and how it all fits together. Figure 1a shows the dataflows into the test environment and how the two main scripts interact.
Figure 1a: Test Environment Dataflow

The basic premise of the test environment is to remain logically isolated from production, therefore all workloads must run on storage LUNs, ESX hosts and networks not utilized by prod. This creates an issue for the transfer into the environment. I have chosen to implement a transfer LUN that is accessible to both Prod and Test environments. In my case, we use EMC arrays that utilize the first 5 disks for array firmware etc. It is recommended not to run production loads on this LUN, so we have used it for transfer functionality.

I have also chosen to have a completely isolated vCenter instance for the test environment. This allows for testing of changes to vCenter itself, amongst other things. It is for this reason that the script is in two parts, one runs against the source Prod vCenter and performs the clone, the other adds the cloned instance into the test environment and moves it to the appropriate place.

Now onto the phases of a clone process.

Phase 1: Create VM List
As the title implies, the first step is to create a list of machines that need to be cloned into the test environment. This is a manual process that the virtual administrator will perform. I have opted to use the csv file format, as that seems best suited. The format is simply “Source_VMName, retention_Period“. An example file is posted below.
Process design for Phase 1

Phase 2: Clone VM’s to Transfer Location (VI_clone-TestVMs.ps1)
In this phase, the VM’s listed in the input csv file are cloned to the transfer LUN and folder. Additionally, extra source information is stored in an XML file that allows reconfiguration of the VM after being migrated to the test infrastructure. Specifically, this is the MAC address, Datastore, notes/custom attributes and folder. In my environment, these operations are performed as a scheduled task on the vCenter server and also target the production vCenter. The final step is to remove the cloned VM’s from the source vCenter, ready for the next phase.

Phase 3: Migrate VM’s from Transfer Location (VI_migrate-TestVMs.ps1)
Once the VM’s have been cloned, they can now be added into the test environment and move to an appropriate place. The process is basically the reverse of Phase 2, except instead of cloning, the VM is moved to the correct location (Cold Storage vMotion).

Phase 4: Remove Test VM’s (VI_removeTestVMs.ps1)
Since all testing in this environment is designed to be relatively short-lifecycle, each VM is scheduled for automated deletion at the time of migration. This is done to prevent lingering Test VMs.

I hope this gives sufficient background into the design of this system. Watch this space for Part 2, where I post and explain VI_clone-TestVMs.ps1…. I’m just doing some performance and sanity testing on it now before posting.

Any feedback would be very much appreciated.
-Doug

One Response to “Clone-to-test: Part 1”

Leave a Reply for Clone-to-test: Part 2

The opinions expressed on this site are my own and not necessarily those of my employer.

All code, documentation etc is my own work and is licensed under Creative Commons and you are free to use it, at your own risk.

I assume no liability for code posted here, use it at your own risk and always sanity-check it in your environment.