(Sidebar to Winning with enterprise-wide virtualization)

Beyond such complexity, there also are problems implementing virtualization in an environment in which not all layers are virtualization ready. This is especially true for security, which Antonopolous calls a virtualization laggard.

“Virtualized servers rely on security resources that are usually tied very absolutely to the physical through the IP address, thereby creating problems,” he says. “If you have a firewall that says IP address A can talk to IP address B, but both of those IP addresses are virtualized and both of the servers behind them are virtualized, yet that firewall still assumes a static association, it makes it difficult to move resources around. It makes it harder to manage the infrastructure.”

This is especially problematic when users look to virtualize a typical three-tier architecture consisting of a Web server, application server and database server. In traditional environments, the Web server might be on the DMZ, separated from the application server and database server on the internal network by firewalls. But once the servers are virtualized and consolidated onto one large blade server, for example, the idea of the physical DMZ and perimeter goes away.

“You should have firewalls between the servers, but you can’t physically put a firewall there, because they’re all running on the same blade frame,” Antonopolous says. “You should be able to logically put a firewall between them, but you don’t have security virtualization software to do that.”

Baptist Healthcare’s Taylor has run into this issue as well. “We wanted to virtualize some of the servers and services in our DMZ, so I proposed that we take an ESX Server and dedicate a couple of the network cards on it to the DMZ, leaving the rest of the network cards VLAN-ed to our private network,” he says. “In theory, they’d be separate, because we’d have virtually separated the two even though they’d be riding on the same server.”

The hospital’s network and security groups nixed the idea, however. “They said that if we wanted to virtualize those services, then that ESX Server had to be fully in the DMZ and could not have any ties to the private network except through the firewall. It’s a huge limitation.”

Technologies such as federated ID and digital certificates are heading in the right direction, as are recent moves by Cisco and others to add more security within switches and routers, Antonopolous says. But more interesting would be placing the security in the server virtualization itself, within the hypervisor.

“That has a significant advantage, because it’s software and can be moved around. And it can be provided to all virtual machines residing on that hypervisor, which provides flexibility,” he explains. “In fact, it can even enforce policies for how those machines communicate with each other within that hypervisor.” Malware designed to attack the operating system would not be able to reach it.

VMware has indicated it will be adding security to its hypervisor over time, and Antonopolous says other vendors are sure to follow.