Before there was concern over VM stall, there was that of VM sprawl.
VM sprawl had organizations worrying that so many virtual machines would be spun up (thanks to the ease of deploying them) that not only would management become an issue, but so, too, would performance, security, and IT staffing.
On the opposite end of the spectrum is VM stall. It’s the tendency for virtualization deployments to come to a standstill once the non-production, low-risk systems have been converted (typically around 20 to 30 percent of servers). It’s that wall (in terms of further VM deployment and ROI) that organizations hit when trying to keep virtualization projects localized and confined to certain parts of the physical network. It’s that wall they hit when they decide to try to secure everything after the fact. And it’s that wall they could avoid if they’d only choose to deploy upfront purpose-built virtualization security that enables a highly dynamic virtualized network without ever sacrificing security.
VMware CEO Paul Maritz has often spoken of the phases of virtualization. Getting beyond VM stall is like breaking through the second phase of virtualization. It’s pushing virtualization beyond the low-hanging fruit and on to the mission-critical elements of data centers. And what’s great is that there are solutions available today that can help organizations surmount the “wall” of VM stall by dissolving fears of losing control or degrading performance. By not hobbling the progression through the phases of virtualization, organizations can realize the ROI of it.
So how about a quick refresh of that ROI. Far beyond the benefit of carbon footprint reduction is the enormous opportunity virtualization provides for fast “server” provisioning, management, and scale. To gain the most, organizations must virtualize large portions of their data centers and enable functionalities such as vMotion, Distributed Resource Scheduler (DRS), and self or departmental VM provisioning.
Sure, it’s understandable that organizations may be hesitant to allow non-administrators to spin up or non-security pros to maintain VMs. Case in point is the very popular Amazon Web Services (AWS) cloud and its security vulnerabilities or, more correctly, those which AWS users and customers themselves create through misconfiguration. What’s also important for organizations to understand is that Amazon gives guidelines for securing Amazon Machine Images (AMIs), but ultimately it’s up to customers to follow them. Or is it? In fact, service providers and enterprises deploying clouds can implement security technology that automatically secures and locks down new VMs, enforcing proper hardening and sharing while limiting risk. This option does remove some customer control in the VM provisioning process, but still enables self-service.
Solutions implementing this VM image enforcement technology exist today and these same solutions also allow customers to turn on VMotion, mix workloads, and get higher VM-to-host compression ratios without risk because they continually maintain VM security.
Virtualization-specific security not only helps overcome the security barrier to VM stall, but it mitigates the ROI argument as well.
Let’s look at a practical example of the impact that virtualization-specific security can have on ROI. Say a customer has three VM hosts and 30 VMs. Ten of those VMs host business applications (e.g., mission critical application that belong to two departments); and 20 are tier-two VMs (e.g., file servers). Let’s also assume that the max capacity for each host is 20 VMs. In the first case, the customer will protect and limit access to the critical VMs using VLANs. So five VMs to host A (department A), five VMs to host B (department B), and 20 VMs to host C (mixed-mode environment that spans departments and criticality). Now, host C is maxed out so if the customer needs to add more non-critical VMs, he'll need to deploy additional VM hosts, as A and B are physically isolated. This is despite the fact that hosts A and B are not maxed out. Again, the logic here is that security is achieved by not mixing workloads and physically cordoning off critical VMs to a VLAN. However, this is all at the expense of ROI. No wonder there is stall.
In a second case, let’s say a customer has deployed granular security per VM (purpose-built virtualization firewall), so he can mix workloads on hosts and achieve departmental isolation and security without restricting the number of VMs on the host. The result is that he can load 10 VMs on each host and have headroom for another 30 VMs spread across the existing hosts. That is where the power and ROI of server virtualization comes into view.
So is purpose-built virtualization security the cure to VM stall? Well, it certainly helps allay the security and ROI concerns that are part of the reticence to deploy. The key is to ensure you’re evaluating security packages that have the right mix of features so that you get the granular isolation and automated security that is required. There are a few things to consider when searching for a solution:
1. Layered defenses – includes firewall, IDS, and antivirus for all VMs
2. vCenter integration – makes the security solution aware of virtual network change
3. VM Introspection – gives an xray-like view of what is installed on each VM
4. Compliance enforcement – can alert and quarantine VMs that fail compliance checks
5. Auto-VM security for new VMs – automatically applies security policy for a given VM type
6. VM image enforcement – monitors each VM image for compliance with a “gold” or ideal configuration
The list above is by no means all inclusive, but can serve as a starting guideline to finding the right solution.