In-Depth
Provisioning and Managing Virtual Labs
Simplified virtual lab management software allows even users to create their own testing environments.
About 10 years ago, I walked away from my corporate job so that I could be a full-time, freelance technical writer. As I made the transition, it quickly became apparent that I needed two separate networks -- a production network and a lab network.
At the time, I already had a production network in place. I had a few desktops and laptops, a couple of domain controllers, a file server and a proxy server that provided my network with Internet access. While this might seem a little over the top for a home network, it's important to realize that freelance writing is a business, and like any other business, it involves sending and receiving e-mails, maintaining certain financial records and storing copies of various files.
While my production network met my business needs, it really wasn't doing much in the way of helping me produce quality content. While I could use my production servers to capture certain screenshots or to get a feel for how certain tools and software worked, I was limited in what I could do safely.
To give you a better idea of what I mean, consider this: Recently I wrote an article that discussed upgrading from Microsoft Office SharePoint Server 2007 to SharePoint 2010. Without a separate lab, this article would have posed a major problem because I don't run SharePoint on my production network.
But suppose I did have a SharePoint 2007 server on my production network -- I may very well have wanted to upgrade it to SharePoint 2010. However, even if that had been the case, upgrading a production server just so I could write an article would've been foolish. Most of the editors I've worked with over the years tend to give fairly short deadlines. As such, the amount of planning required for a proper upgrade would likely have taken more time than the article's deadline would've allowed, and rushing an upgrade isn't wise.
Another reason why using my production network in my writing isn't practical is because doing so could be a big security risk. Think about the types of information that could be exposed through a screenshot. Depending on what I'm writing about, a screenshot may reveal the IP addresses, SIDs, domain names or account names that I use internally.
Ultimately, I decided there was just no alternative to constructing a lab network. After doing so, my lab network made it a lot more practical for me to write about various enterprise networking technologies. However, it also presented a set of problems all its own.
For the most part, these problems were financial in nature. Server virtualization had just been introduced and it really wasn't practical yet, so I was forced to use physical hardware. As such, I spent an absolutely obscene amount of money on servers, network switches, cabling, software licenses and so on. Even after my lab was fully provisioned, there were ongoing expenses that I hadn't thought about. It seemed that I was constantly spending money on server upgrades and repairs. Additionally, my electric bills began to resemble the national debt. Not only did the servers consume electricity, but they also forced my air conditioner to run a lot harder than it normally would have.
I continued to use physical servers in my lab until about three years ago. At that time, I decided server virtualization had finally matured to the point that it would be reliable enough to meet my needs. I still use some physical servers in my lab, but the vast majority of my lab servers are virtual.
There's no question that using server virtualization has made my life easier. I now spend far less money on server hardware, electricity and repairs than I did before I virtualized my lab. But the story doesn't end there.
Creating a Virtual Lab: Challenges
Like me, there are many other organizations that have discovered having a virtual lab can be beneficial. Such labs are used for everything from software development to testing patches prior to deploying them on the production network. Regardless of what an organization uses its virtual lab for, almost everyone has found that there are certain challenges associated with creating and maintaining a virtual lab.
One of the biggest challenges is the amount of time and effort involved in configuring a virtual lab for a specific task. For example, last year someone asked me to write about Microsoft Office Communications Server (OCS) and how it integrates with Microsoft Exchange Unified Messaging. I write about Unified Messaging on a semi-regular basis, so I already had a Unified Messaging lab deployment in place.
Unfortunately, OCS can't be deployed seamlessly. The installation process makes a lot of changes to Active Directory. There are also certain changes that have to be made to the way that existing Unified Messaging servers are configured. Therefore, I had a choice to make. I could either install OCS onto my existing lab network and have the network configuration permanently changed, or I could create a completely separate lab network.
In the end, I decided I needed to preserve my existing AD configuration, so I created an entirely new set of virtual servers for my OCS deployment. In doing so, I had to create and manually provision a couple of domain controllers, a mailbox server, a Unified Messaging server, a front-end OCS, a mediation server and some workstations. It took me the better part of a week to get the new infrastructure up and running and correctly configured. All of that work took place before I even started writing the article.
Of course, this is just one example of a situation in which I had to create a rather elaborate lab deployment so I could write an article about it. The reality is that I find myself deploying new lab servers on a regular basis. What made this particular situation so difficult was that there were so many different servers involved, and each of those servers had to be configured in a certain way.
VMLogix LabManager
Thankfully, provisioning and managing virtual labs is becoming easier. Various software vendors have begun offering virtual lab management software that's designed to make the process more efficient. One of the leading providers of Web management software is a company called VMLogix Inc.
VMLogix, which is being acquired by Citrix Systems Inc., offers a virtual lab management application appropriately named LabManager. It's important to note that LabManager is not intended to replace an organization's virtualization platform, but rather augment it. LabManager works alongside an organization's existing virtualization platform, but remains hypervisor-agnostic. This means organizations that want to use VMLogix LabManager aren't locked into using a specific virtualization product. It works equally well with VMware VSphere, Citrix XenServer and Microsoft Hyper-V.
Given all the virtualization platforms that I mentioned are mature and fairly comprehensive, you might be wondering what functionality LabManager adds, and how that functionality can make virtual lab management easier.
LabManager is designed to enable the process of building and deploying a virtual lab environment a lot quicker and easier. Interaction with it is done through a Web interface that acts as a front-end to your virtualization host. This interface provides users with templates that they can use to rapidly deploy lab servers.
Of course, most server virtualization products also allow administrators to perform rapid, template-based deployments of virtual machines (VMs). On my own network, for example, I've used Hyper-V to create lab machine templates. That way, whenever I need to deploy a new VM I don't have to worry about starting completely from scratch, because the template already contains a pristine Windows installation.
VMLogix LabManager takes things a step further. While LabManager will certainly allow you to use a template to deploy a virtual server, you also have the option of using a template to deploy an entire lab configuration. If you think back to my OCS lab that I described earlier, you'll recall that building the lab required me to create 10 different VMs. Had I been using LabManager at the time, I could have created and configured all of the required virtual servers through a single administrative action. In doing so, the deployment time could've potentially been reduced from nearly a week to a matter of minutes.
Such rapid deployments are possible because LabManager comes with a configuration editor that allows you to define exactly what you need in your virtual lab by using a collection of modular components. Virtual lab configurations consist of VM templates, network settings and policies, as shown in Figure 1. Ultimately, users can provision environments by simply selecting the desired configuration and clicking on a Deploy button.
[Click on image for larger view.] |
| Figure 1. LabManager allows you to deploy multiple servers simultaneously. |
Of course, simplifying the provisioning process would be pointless if the lab management software wasn't flexible enough to meet an organization's ever-changing needs. LabManager allows administrators to customize a server's configuration before the server is even deployed. Suppose, for example, that you needed to create a SQL server as a part of your virtual lab. There's no need to create a Windows Server and then install SQL Server on top of it. Instead, you can simply tell LabManager to install SQL onto the new server. Upon doing so, LabManager will handle the provisioning process without the administrator having to perform any manual configuration.
The same Web interface that allows applications to be added to virtual servers allows for other configuration changes as well. For example, you can change a server's environment variables or add an additional NIC to the server, all before the server is even created.
Network Isolation
Earlier I mentioned that I've created some templates of pristine Windows deployments that I can use whenever I need to create a new VM. The problem with creating such templates is that there are some Windows components that must be unique. Each server on a Windows network requires its own IP address, MAC address, NetBIOS name and SID. This simple fact can make cloning virtual servers a bit problematic.
Normally, if you want to clone a Windows deployment you must run the Sysprep utility against the virtual server. Sysprep removes anything that uniquely identifies the VM so that it won't conflict with other servers on your network. Even though Sysprep sounds like an ideal solution, it really isn't.
One of the things that Sysprep removes is the server's computer name. Because the computer name is required in order for a server to be a domain member, cloned servers must be manually joined to a domain. Furthermore, many server applications require the server to be a domain member. This means you can't install such applications ahead of time.
In many ways, a Sysprep image is a lot like a brand-new Windows deployment (although some types of customizations can be included in the image). In fact, the first time you boot a server that was cloned from a Sysprep image, you're required to run a mini Windows Setup.
My point here is that cloning VMs in the traditional manner is inefficient. However, the issues that affect the cloning process don't come into play when LabManager is being used. LabManager uses network isolation to ensure that VMs don't conflict with each other, even if they're running completely identical configurations.
User Management
Because lab management software makes virtual lab deployment so much easier, some organizations are finding that virtual labs can be beneficial to departments other than IT. For instance, a company's sales department might use a virtual lab as a way of demonstrating a product to a client. Likewise, organizations may choose to use virtual labs for user training or to train the help-desk staff. There's really no limit to what a virtual lab can be used for.
Fortunately, VMLogix realized that once users begin to discover all of the potential uses for virtual labs, the IT department could be overwhelmed by user requests for virtual labs. Therefore, the company equipped LabManager with a self-service portal that users can use to create their own virtual lab configurations, though whether or not users will be allowed to deploy their own virtual labs is ultimately up to the administrator (see Figure 2). VMLogix LabManager allows administrators to apply a set of permissions to each configuration so that end users will only be able to deploy virtual lab configurations for which they've been authorized.
[Click on image for larger view.] |
| Figure 2. The administrator has the ability to approve user requests. |
Combating VM Sprawl
Although the primary purpose of LabManager is to facilitate the rapid deployment of lab environments, it's also designed to solve another problem that's common in lab environments -- VM sprawl. This is an important consideration because, without a mechanism in place to prevent sprawl, the excessive creation of virtual servers can quickly deplete the available hardware resources. This is especially true if an organization chooses to allow end users to provision and deploy their own virtual labs.
As I explained earlier, I tend to deploy additional lab servers every time I have to write about something new. Because creating a lab deployment without the aid of lab management software can involve so much work, I usually don't delete the newly created VMs when I finish the article. After all, I never know when an editor might have a question or might need a screen capture, and I really don't want to have to completely rebuild the entire lab if that happens. Besides, I never know when I might be asked to write about a topic that would require a similar configuration.
Last summer I began running out of disk space on one of my host servers, so I decided to see if there were any VMs that I could get rid of. As I looked through the server's contents, I realized that I had dozens of unnecessary VMs. I couldn't even remember what some of the VMs had been used for. Being that I operate a one-man shop, you can only imagine how quickly lab servers could get out of hand in a larger organization.
LabManager helps with VM sprawl by retaining ownership of any virtual labs that are created. When a user creates a virtual lab, he doesn't own the lab servers. Instead, LabManager leases the virtual lab to the user for a finite amount of time. When the lease nears its expiration date, LabManager alerts the user, and gives him the option of extending the lease if the virtual lab is still being used. If the user allows the lease to expire, then LabManager will automatically delete the virtual lab.
Administrators also have the option of imposing quotas on end users as a way of preventing them from creating an excessive number of lab servers. At any time, administrators can run a quota report similar to the one shown in Figure 3. That way, they can see how many VMs each user is using, as well as the amount of host server resources being consumed.
[Click on image for larger view.] |
| Figure 3. Administrators can run a virtual lab quota report. |
Not Just for IT Pros
Because of their cost and complexity, virtual labs were once used solely by IT professionals and software developers. Today, though, virtual lab management software has simplified the creation of virtual labs to the point that even end users are able to create them. This has allowed virtual labs to be used for numerous creative purposes such as sales demos, product training and even help-desk functions. Perhaps the greatest benefit to virtual lab management software, however, is that it greatly reduces the time and effort required in building virtual lab environments.