My VMware Test Environment

So I thought I’d share with you some background on the test environment I’m building, as I’ll be posting the scripts I’m developing to make it all happen… so a bit of context will hopefully help you.

My organization is currently going through a phase of massive expansion and as a result we’ve been given a little freedom to explore new technology and increase our knowledge and experience with VMware. To experiment with the new products and also to test changes to VM’s, we decided to build a small 2-node VMware cluster mimicking prod as closely as possible.

This environment will allow us to clone any given VM into the test environment, whilst maintaining layer 3 (and possibly layer 2) information, perform a change, do some testing, then remove the VM. It will also allow us to test cluster/host/vCenter changes in an isolated environment before making changes on the Prod virtualization infrastructure.

I’ll be scripting the clone, migration and deletion of VM’s, possibly with service-desk integration.

What makes this all possible is an isolated, replica version of the prod VLAN structure on the Test environment. Because the PortGroup information remains the same in the test environment, ANY VM that is running in prod can be clone’d into the test environment. We’ve chosen to implement a physically separate layer3 cisco switch, so if any routing weirdness occurs: we can physically isolate the environment easily.

The diagram below shows the basic network layout. The diagram is highly simplified, as there are actually over 30 production VLANs trunked to Prod… all will be available in test.
Test Environment Logical Design

Test Environment Physical Design

Test Environment vCenter Overview

Storage is actually somewhat more simple than the network. We’ve chosen to expose a “Transfer” LUN to both Prod and Test environments, VM’s will be cloned here in the prod environment, then migrated to dedicated Test LUNs (matching the tier of storage in Prod). Its possible this step could be done using the storage controllers, but for the purposes of simplicity, I’ve chosen this method to start with.

Hopefully that gives a little background for my future script posts and may also be helpful to others. Let me know what you think.
-Doug

8 Responses to “My VMware Test Environment”

  • […] 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 […]

  • jvdpol:

    Hi Doug. Very good article! Could you give me some more background information of your setup? We’re preparing a similar setup, and looking for best practices in setup.

    • Hi jvdpol,

      I don’t know if Im qualified to give “best practice” advice… but what background info would you like?

      -Doug

      • jvdpol:

        Hi,

        Could you give some information about the isolation of your test and production environment and maintaining the layer info?
        Our goal is to create an easy to maintain and deploy test environment isolated from our production systems.

        Thanks in advance!

        • Righto… I forget that some people arent as full bottle on hte networking side… I came from a cisco background, so networking stuff is pretty much easy for me :)

          The way I’m keeping the test environment seperate is to mask what VLANs are allowed to traverse the link between the test environment switch and prod network. I’ve then recreated the prod vlans on the test-env with the gateway for each subnet configured there as vlan interfaces.

          As the diagrams partially explain, the ESX service console and vcenter are configured on the only vlan that is allowed through the trunk.

          Effectively what Im doing is intentionally creating a segmented network. This completely isolates the VM’s hosted in the test environment… so they can have identical network configuration as their prod equivalents….. however because they are isolated, all their dependencies will also have to be present in the test environment (DNS, DC’s, DHCP, etc).

          How’s that? I might actually write up a follow up post since there’s some interest… but right now I just got out of hospital, so I’ll leave it at that for tonight.

          Perhaps if you would like to discuss further, we can do so on skype or msn? Drop me an email doug_at_pump_dot_fm and we’ll work something out.

          -Doug

        • Also…

          We chose to not use the same VLAN numbers inside the test network. Instead we prepended all prod VLAN’s with 3… so for instance if we have VLAN320 in prod, we will call it 3320 in test. The subnet information will be the same on bothe networks, but the test environment is not externally routable.

          The key here is that the PORTGROUP NAME remains IDENTICAL between the two environment, this is what allows VM’s to be cloned over easily, without modification.

          I should point out, this type of test network is purpose built for short term testing. Longer term testing (in my opinion/experience) would usually require the OS to be managed properly (Patches etc) and as such isnt the best use of particular design.

          -Doug

  • Thanks for the feedback.

    The only article that I can think to reference at this stage is Maish’s vCenter Migration script. http://technodrone.blogspot.com/2010/01/vcenter-powercli-migration-script.html

    I will be using components of this to help me move cloned servers around. I’ll post up my high level designs for the scripts today and hopefully have a beta of the scripts upo by the end of the week.

    Enjoy,
    Doug

  • Hi there this post is nice and interesting. I’ll use it for my blog :). Can you say to me some related articles I could use too?

Leave a Reply for cnidus

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.