January 21, 2013 | Written by: Chenta Lee
There are so many kinds of hypervisor in the market, including VMware, KVM, Xen, PowerVM, VirtualBox and Hyper-V. At the very beginning, IaaS solutions tended to support only one type of hypervisor, however, the trend has changed. For now, most of the IaaS solutions support more than one type of hypervisor due to two reasons:
- Existing licenses for hypervisor
For example, a customer already spent one million dollars to buy some licenses for hypervisor A but the IaaS solution only supports hypervisor B. Should they throw away those expensive licenses? No, they should keep them and blend them into my IaaS solution. My IaaS solution only adds an additional management layer above the hypervisor, hence, supporting multiple types of hypervisor seems reasonable now.
- Each hypervisor has its unique features
Every hypervisor has their secret ingredient to make it special in different fields. Not surprisingly, the prices are also one of the key factor to alter a customer’s decision. We could treat it as an unique feature for some of the hypervisors, in both good ways and bad ways. In addition, some VMs could only run on a certain type of hypervisor due to the CPU instruction set compatibility and the driver support.
Given the fact that supporting only one hypervisor in your IaaS solution will shrink your market share directly, it is the same to the security solution in the cloud. As a security solution provider, we just could not tell the customer that only half of their virtual machines will be protected and the others are on their own. No one will buy the solution like that.
Assuming that your security solution needs to install an agent on all the virtual machines, the first issue you will have is the footprint overhead. How many virtual CPUs are running the same binary code and how much virtual memory is loaded with the same content? Imaging that all of your VMs are downloading the same virus pattern at the same time, every VM is basically doing the same thing, how silly is it? The second issue is about agents management. How do you know if the agents are really running on VMs? How would you make your agent run on every operating system? A user could easily turn off the agent or re-install their VM with other operating systems to bypass the check.
With the agentless approach, we could do the resource intensive task in one place. Plus, there is no way to escape from our protection because it is provided by the hypervisor. Using an agentless approach is the only way to provide transparent and robust protection in the cloud.
How many IPS would you purchase for your server room? Ten is a huge number already. How about the security product for your hypervisors? It is common that there are more than one hundred servers in the server room to build the cloud in your infrastructure. One hundred servers is actually a small number in the cloud, hence, without automatic deployment in your security solution, the administrators need to set up each server one by one and it will definitely ruin their day. One of the necessary features which must be included in the automatic deployment is the minimum configuration effort. When a new VM is added to the inventory, the security administrator should only see an event popping up; any other steps are unnecessary and annoying. In some of the work flow designs, the hypervisor will keep provisioning new virtual machines to handle the excessive requests from clients then delete them when the loading became normal. If the above scenario requires human interactions to provide security on newly created VMs, the response time will be unacceptable.
To sum up, heterogeneous hypervisor support could help you to fit in any IaaS solutions. Furthermore, with the agentless design and automatic deployment, your security solution would only add the minimum management overhead. These are the key features to make your solution survive in the cloud.