There's no question: The biggest single source of security vulnerabilities in enterprise IT is unpatched or out-of-date software. While social networking, phishing attacks and social engineering all get more attention in the press these days, simple, unglamorous patch-management failures leave doors to the heart of the enterprise wide open for attackers to enter. While there's no question that patch management for a large fleet of virtual servers or virtual desktops can be managed more efficiently than the same process on multiple physical devices, fine-tuning the process can lead to complications for the IT team in charge.
One of the complicating factors, especially in operating system patches, is precisely where the patch is to be applied. Should it, for example, be applied to the host server (the server on which the hypervisor and all the virtual servers actually run), the virtual servers, or both? If the answer is "both," then in which order should it be applied? That doesn't begin to address the questions that arise when it comes to unintended consequences and interactions.
The nice thing about virtual servers is that they can be created and torn down quickly and with little spill-over to other virtual servers. If internal customers are depending on the applications running on one of those virtual servers, though, the consequences of a patch that breaks existing applications can be huge. Many organizations want to "sand box" patches before rolling them out to the production environment. The proliferation of applications that can run on virtual servers may make this a more difficult process as IT engineers try to account for all the different software combinations that may exist.
Such combinations become even more an issue with virtual desktop implementations, because there are generally more hardware platforms — ranging from smartphones to tablets to traditional laptop computers — that can support the virtualized desktop; more local clients used to accept the virtual desktop on the various hardware platforms; and many more network links that must be traversed in the virtual desktop's implementation. In general, though, there is less sand-box testing required on the desktop side, because a single-instance failure will tend to affect one user at a time rather than the hundreds or thousands that may be hit by a server failure.
With all the complications involved in patch management in a virtualized environment, it's worth remembering that there are significant advantages, as well. Critical updates can be applied to a single "master instance" of the virtualized environment and applied to every copy of that environment with a simple reboot of the instances that are in operation. In addition, the IT staff has a much better idea of precisely when patches are being applied, because they can be triggered from a central location rather than waiting for users to shut down or bring laptop computers to a central location.
In a final note about complexity, it's important for administrators to remember that the hypervisors themselves are software components that must be maintained and patched in the same way that operating systems and applications are maintained. Obviously, the patch and maintenance cycles of a hypervisor instance responsible for hundreds or thousands of server or desktop OS instances must be carefully scheduled, but the enhanced security, improved reliability and more complete regulatory compliance that comes from proper patch policies and procedures are too valuable to ignore, no matter how complex the patch management becomes.
For more information, see:
Server Consolidation With Virtualization
Storage Virtualization
Desktop Virtualization
        | 
 |
