Building The Virtual Staging Platform for IT Pre-Production Testing

Posted May 27th, 2008 by Dennis Powell

dilbertvirtualization Building a virtualized staging environment for IT testing sounds like a pretty good idea, right? We think it is a good idea – if planned properly. Virtualized staging environments for IT testing can save time, effort, and budget. However, when preparing for any new technology, you need to make sure you enter the purchase and deployment decision arena with “eyes wide open”.

Today’s blog offers technical virtualization hints and tips. It’s intended for those of you leaning toward investing in the technology and effort to build a virtualized staging server for IT testing. If you are brand new to the concept of virtualization as a technology, there is a wealth of information on the Internet, such as a primer by Datamation, and broader coverage available from SearchServerVirtualization.com. I also recommend you review an article by Rob Latimer, Principal Consultant for Glasshouse Technologies, entitled Guidelines for virtualization preparedness to help you evaluate virtualization from a clear-headed perspective.

A number of the organizations with whom we speak have already invested in server virtualization for consolidation reasons. Many of these organizations are looking to utilize virtualization for change and release management, as well as other second-generation virtualization uses. However, fewer organizations have deployed virtual staging environments for IT testing – in large part because they are still deciding how and where virtualization will benefit their staging and testing process.

That is why we have developed a ‘starter’ set of technical guidelines to consider when planning to use full virtualization to stage, change, test and analyze the impact of change to your software infrastructure. Full virtualization in this case is characterized by one or more virtual machines (VM) running on a single hypervisor on a physical machine.

First, you will want to set expectations with management. They will likely ask “why should we utilize virtualization for your staging platform for IT testing?” Look back at numerous StackSafe blogs for help in identifying how virtual staging and testing can improve your testing maturity.

In general, a virtualized staging server can help you address some common problems faced by IT Operations teams:

Production faults, performance problems and/or downtime caused by change
Production changes that result in problems
Changes that require roll back from production
Testing at least 90% of the changes that are deployed to production
Testing changes across the entire infrastructure from end-to-end
Excessive time and/or resources to build, maintain, and synchronize staging and testing environments to represent the production environment
Painful and costly business application downtime
The need for quicker turnaround on changes to production in order to maintain competitiveness

Next, consider the basic ‘pieces’ of a virtualized staging server, which are offered by multiple vendors.

The virtualization platform. This platform features a hypervisor that hosts ‘guest’ VM operating systems. The hypervisor lets VM OSes share the physical machine memory, CPU, and other bare metal services. This virtualization platform can be used to host virtual staging and testing, virtual production, virtual disaster recovery backups, or any other virtual environment.
P2V (physical-to-virtual) import technology. This is required to copy physical machines onto the virtual platform as VMs (think server consolidation). By capturing the software image of the production server, P2V creates VMs that more closely represent the physical environment than building representative VMs.

Finally, you will want to follow certain planning steps when building a virtualized staging server:

Locate a server with CPU that supports virtualization for your virtualized staging server. Nearly all CPUs support virtualization these days, but make sure.
Determine where you want the virtualized staging server to reside. If you have a test lab, you will likely want to supplement the existing staging and testing environment. This placement provides you with access to testing tools and existing staging servers that you may want to virtualize.
Decide on how the virtualized staging serverwill be networked. This will require answering questions like: where will itreside or which networks should it be able to access? P2V may require network access between the physical machinesand the virtualized staging server. Security and system ownership issues will also dictate some of these decisions.
Determine what type of VM you expect to run on the virtualized staging server. This includes the base OS and hypervisor, and all of the VMs that are expected to be running simultaneously on the system. For example, if you plan to make and test change to five 2 CPU/core VMs w/ 1GB of memory, the system will require approximately 12 CPU/cores and 6GB of memory.
Scope the virtualized staging server to run multiple VMs, bearing in mind that each VM can require different levels of system resources.

One other suggestion: Manage your import process according to your testing requirements. If you perform redundant testing of the same system components (for example quarterly failover testing), it should be relatively easy to import your baseline configuration and maintain this ‘gold master’. If on the other hand you expect to perform a variety of tests against a variety of system configurations, pay close attention to the virtualization staging server resource load to ensure that you aren’t introducing stress to the system that may be incorrectly blamed on the change/s made to the imported VMs.

There are other virtualized staging server-related concepts to consider that we will cover in future blogs, including the types of tests and analysis IT may want to perform, and a review of the change and release management activities that don’t adapt well to a virtualized staging server.