In my previous column, I discussed some of the initial challenges you're likely to face in piloting an early virtualization project. In this column, I want to discuss the longer-term issues you'll be confronting as you accord virtualization a great presence in the data center.

Virtualization is a technology that delivers very significant savings on energy costs and hardware bills by simulating hardware in software. The greatest savings comes from creating these so-called virtual machines (VMs) and loading them with applications that are scattered around the enterprise on dedicated servers. These VMs are hosted on a single host system (thereby providing the consolidation) that uses far less power than the total of the scattered servers it replaces, while delivering better -- often significantly better -- performance.

However, like all technologies that solve one problem, virtualization introduces others. By being mindful of them, data center managers can put in place policies that mitigate the risks and costs associated with virtualization.

VM Updates

So, your data center has moved to virtualization and now has, let us say, 150 VMs running on a half dozen host systems. This is a small number but representative of the problem. Let's say the machines are all running Windows XP. Then, you read that Microsoft has just released a critical patch for Windows XP. After consulting with various managers, you agree with Microsoft's assessment: the patch has to be applied. How are you going to apply the patch to the VMs? There are not a lot of tools out there that cater to VM-specific needs. However, a few such as VMware Update Manager, are helpful. While you apply a patch to a VM the same way you do to a PC, the VM-specific issues are:

• You don't want to update all the VMs on a host simultaneously. The process and I/O of stopping and starting numerous VMs at once will bring the host system to its knees. Ideally, you want to stagger the patching. In addition, the usual IT issues of how and when to bring down a running system need to be borne in mind with every VM.

• Updating VMs that are not in use. This is a non-trivial task that needs to be done. The only way to patch a VM is to load it onto the host, start it up, apply the patch, bring it down, and store it away. It's time-consuming. While it might seem that this is less time-consuming than updating physical servers that are turned off, there is another aspect, which I discuss shortly, namely: VM proliferation. You're likely to have many VMs (often hundreds) not currently in use that should be updated. I'll come back to this in a second. There is one benefit to updating VMs: You can easily make a snapshot of the VM before you update it. Then if something goes wrong with the update (it interferes unexpectedly with an application), you can revert the machine back to the snapshot until you figure out what's wrong with the patch and how to fix it.

VM Proliferation

The proliferation of VMs is probably the biggest headaches for IT managers arising from the adoption of virtualization. VMs are easy to copy. And IT staff, as well as end users, will frequently make numerous copies of VMs. There are many reasons for this. The primary ones are:

• Creating multiple new VMs at project start because of an expectation that, say, 10 machines will be needed. Later, only three are used, but the remaining seven are not deleted.

• Copying a VM as a backup mechanism. VMs should be backed in the same way as regular PCs -- not at the VM level, but at their internal file levels. Most deployments of VMs keep the data in a remote storage fabric, so there should be little to back up in a VM: application files and some small amount of local data. Use standard backup software for this.

• Capturing the state of a VM as a safety mechanism. I mentioned this previously in connection with taking a snapshot of a VM before applying a patch, as a fail-safe mechanism if the patch does not work. You do want to capture the entire VM, so you can simply swap the two VMs if problems occur. To manage this cause of proliferation, keep a tight inventory on these copies and give them a deadline, after which they will be backed up to optical data and removed from the system. And then deadline the optical media as well. Some IT organizations are more paranoid than others and so they create failsafe copies frequently. The more paranoid the IT shop, the more rigorously deadlines and inventory have to be enforced.

Conclusion

Last month, I said I'd complete the discussion of virtualization challenges in this column and then resume examining hardware for its green-ness. It appears, however, that I need one more column to discuss a few more challenges and then provide some guidelines that will be helpful. I'll see you next month and wrap up this topic.