The dark side of server virtualization

Here's how to deal with network management complications

Server virtualization is a growing reality in data centers. The economics are firmly behind the trend. Server virtualization reduces the total cost of ownership by reducing the number of physical servers, requiring less cooling and less power while increasing flexibility. This is all good for the business and the server group, but what effect does it have on the management of the network? The truth is that it complicates network management.

There are two big network problems associated with server virtualization. The first is configuring virtual LANs. Network managers need to make sure the VLAN used by the virtual machine (VM) is assigned to the same switch port as the physical server running the VM.

[ Doing server virtualization right is not so simple. InfoWorld's expert contributors show you how to get it right in this 24-page "Server Virtualization Deep Dive" PDF guide. ]

One solution is for the server virtualization group to tell network management team every possible server the VM can be started on and preconfigure the switch ports. This is not a perfect solution because it can cause the VLAN to be defined on a very large percentage of the switch ports. It can get even more complicated because the server group may not be aware of all the servers that images can be started on, especially during a recovery situation when they are taking emergency measures.

The second problem is assigning QoS and enforcing network policies, such as access control lists (ACLs). Traditionally this is done in the network switch connected to the server running the application. With server virtualization there's a software switch running under the hypervisor in the physical server -- not the traditional physical network switch that connects to the physical server.

It is still important that policy be enforced in the the software switch. For example, if two VMs running on the server are not allowed to communicate with each other, someone who gained control of VM1 could open connections to VM2 and steal its data. If ACLs are applied by the soft switch in the server then this would be blocked.

Before virtualization, this was prevented because the applications in VM1 and VM2 would run in different servers and the ACLs defined in the network switch would prevent the communication. Having policies applied in the software switch maintains the security. The issue is how to get the software to apply the policies.

Overcoming these two challenges is critical to making server virtualization work smoothly. It would have been nice if the vendor community had created a uniform standard that works with all the different virtualization vendors. As is normally the case with rapidly growing new technology, this did not happen. The industry has implemented four ways to address these problems.