beawolf - Fotolia
To create an effective and efficient virtualized development environment, IT administrators must protect crucial hardware resources and design effective VMs.
Beyond server virtualization, a primary use case for virtualization technology is the creation of virtualized development environments to house VMs for development and testing. With test/dev VMs, admins can test different versions of software, potential product implementations and new features. Admins can then situate these VMs outside of production environments where mistakes won't be as costly. VMware offers VMware Workstation, a product that enables this isolation.
Adventurous admins might also consider breaking taboos and mixing test and production environments. But both paths require the careful creation, deprecation and migration of test/dev VMs.
Virtualized testing environments can be useful assets, so incorporate these tips into test and development workflows to ensure virtual development serves the organization's goals efficiently and doesn't hinder production.
Avoid these mistakes when creating test/dev VMs
There are a multitude of different, context-dependent reasons an organization might want a test/dev VM. For example, organizations might use test/dev VMs as separate virtualized testing environments for application development or as isolated models to test configuration changes before they enter production.
It's tempting to ignore best practices when creating test/dev VMs because their creators rarely intend for them to enter production. Lax test/dev VM creation, however, can lead to unforeseen consequences.
The rise of containers -- especially in development -- has freed organizations to transition containers used for application testing to production without the need for modification. Though it's possible to do the same with VMs, organizations must adjust policies to ensure the VMs that might transition meet the necessary security and compliance requirements.
The same concern exists for licensing. Test/dev VMs might have looser licensing restrictions, but they need to meet those requirements to enter production.
Even if test/dev VMs don't enter production, their unchecked presence can cause trouble. If admins are rapidly creating test/dev VMs that are bound to obsolescence once virtual development is complete, the likelihood of VM sprawl rises. Keep track of who creates test/dev VMs and retire the VMs once they're no longer in use.
Establish lab VM creation policies
Lab VMs are useful to safely test software, but they require careful configuration to protect production environments.
Most admins consider a virtualized development environment safe because it's usually a sandbox lab that isolates testing and experimentation. If admins aren't deliberate during the creation and configuration of lab VMs, however, they can cause problems on the production network.
The ideal lab infrastructure uses dedicated server and storage hardware, which can completely isolate virtualized testing environments from production environments. If this is too expensive, other worthy VM labs can be part of production server environments as long as they have plenty of free capacity or use backup applications that have a virtual lab feature with snapshots based on the production environment.
Beyond infrastructure, admins should establish a series of policies that ensure lab VMs don't affect production, such as limiting the consumption of hardware resources and controlling the virtual switches lab VMs can connect to. Lab VM policies can also help combat VM sprawl because lab environments are especially prone to poor lifecycle management.
With a proper lab infrastructure and its associated policies working in concert, admins can avoid many of the problems that tend to affect carelessly created virtualized development environments.
Build a sandbox with VMware Workstation
Creating a virtualized development environment can be expensive if organizations use primary virtual resources, but VMware Workstation enables the creation of sandbox testing environments that function inside the desktop.
Continuous requests for hardware resources to use for test/dev workloads can prove costly. Testers can instead use VMware Workstation to situate multiple VMs in a personal sandbox. Additionally, testers can nest ESXi products, such that they can run VMware Workstation on a desktop inside an ESXi host.
Of course, running an entire data center from a desktop isn't necessary, but with Workstation, admins can run enough components to create a sandbox useful for virtual development. Admins can then isolate the sandbox and cheaply test new features, products and software versions.
Beyond cost, sandbox testing protects production hardware. If organizations require admins to perform testing in a sandbox, they ensure the relevant personnel are familiar with the technologies before deploying them in production.
Prepare test/dev VMs for migration
Once testing and development are complete, admins can migrate test/dev VMs to production -- as long as they keep a few things in mind.
Due to the separation between virtualized development environments and production environments, a VM's virtual network adapters likely won't automatically connect to the new network. Sometimes, troubleshooting this is as simple as redirecting the adapter to a different virtual switch, but, in other cases, it can require resetting domain name system mappings, assigned IP addresses or application-level bindings.
Before migration, admins also need to ensure that new VMs meet security requirements. If a test/dev VM is on track to enter production, it's best to check that it meets these requirements early. Otherwise, the VM will require additional testing to ensure that compliance changes won't affect its workload.
Admins will also need to check service-level agreements to identify hosts that can run the VM and whether high availability is necessary for migration. To prepare for migration, plan for the added VM's resource requirements. Migrated VMs will likely need additional hardware resources because test/dev VMs don't require as much memory or as many CPU cores.
Consider mixing test and production environments
Traditionally, it has been a best practice to separate test and production environments. This isolation has numerous advantages, but admins should also consider the disadvantages and think about breaking virtual development norms when it is necessary.
If an organization requires a lot of testing, costs can mount when the creation of multiple virtualized testing environments becomes necessary to maintain separation. This cost isn't necessary when VMware and other providers offer tools, such as resource pools, that can limit exposure between environments. Admins can use these tools to control hardware resources and limit VMs -- depending on their roles in the system -- from consuming excessive host resources. These advancements not only make it safe to run VMs on the same host, whether production or test/dev, but they offer advantages to doing so.
Server failure is inevitable, but by mixing test and production environments, admins can mitigate some of the risk. In a separated environment, the loss of a production host will cause numerous production VMs to crash. A mixed environment can spread risk such that server failure affects fewer production VMs because each host contains both production VMs and expendable test VMs. Using Distributed Resource Scheduler rules also makes it so that the allocation results in an environment with a significantly shorter restart queue in the event of a failure.
Beyond server failure, admins can also avoid having to prioritize production VMs when resources start to run out. In a mixed environment, admins can use resources from test servers during outages or usage spikes.