Server Virtualization Project Risks

by Jenn Cano on March 5, 2012

Organizationally, the ability to “go virtual” brings increased productivity and opportunity.  Clearly, more and more of the world we live in is turning virtual.  But, virtualization can be problematic and, as with any project, server virtualization projects have inherent risks associated with them that are no different.  Server virtualization project risks range anywhere from management to security to implementation. 

Implementing virtual servers can be a management nightmare.  Typically, virtual servers host multiple applications and therefore their failures have a much larger impact across an organization than a non-virtual server would.  This can be mitigated by exploiting VM (Virtual Machine) mobility.  This ensures that when a server fails it triggers the automatic live migration of hosted VMs to another server so that there is no disruption. 

But, with VMs comes the need to require strong control processes to be put in place in order to limit the number of virtual machines that can be created and who can create them.  Otherwise you may have users creating their own VM on their local PC’s with unauthorized operating systems and a lack of security patches on those VM’s. 

Consumer IT, including easily downloaded Web applications, will not go away anytime soon. IT departments can set policies banning specific apps of course, but now users have another tool at their disposal. It's not unusual to find business and IT staffers using VMs to run and disguise unauthorized applications.

Not only can it be a nightmare in terms of controlling unauthorized VM’s with virtualization servers comes a new set of products and technologies that the admiration staff has less experience on.  There will be a learning curve involved in running the virtual servers now software layer, the Virtual Machine Monitor.

The introduction of virtualization does not affect only the server administration team, but the network and storage administration teams as well. This is a step forward in the process started with the introduction of blade servers. Blades chassis, like IBM BladeCenter are not simply enclosures hosting servers, they are actually the consolidation of an entire server farm. Indeed they contain management devices, networking devices and storage devices. The introduction of blade servers mandates better integration and cooperation among administration teams.

Virtualization requires administrators to go a step further. The fact that you can create virtual adapters, virtual switches, etc. makes it necessary to share the virtual server among multiple administration teams.  As with anything, the more hands in the pot the more chances for something to go a-rye.   It’s important to plan ahead and think about implementation process beforehand.  For example, logical naming process, production environment borders, administration authorization processes, etc.  You don’t want to end up with pre-production VMs (say for application development work, or software upgrade preparation) and production VMs running at the same time in the same environment!

Topics: virtual servers, virtualization, IBM servers, IBM Bladecenter, blade servers

Recent Posts

Topic Cloud

Popular Posts

!-- jQuery 3 -->