Top ten reasons to say no to virtualisation

Cesare Garlati, VP of mobile security at Trend Micro, agrees. At the recent RSA Conference 2012 in London, he suggested ten different situations when the right thing to do is turn your back on your hypervisors and run applications as nature intended — on good old-fashioned physical server iron:

1. If going wrong is not an option. In other words, if you have something that works and needs to keep working, then what's the point in introducing the complexity and unknowns of server virtualization – and thereby risking downtime?

2. When licenses don't allow it. Some applications' licenses simply don't allow them to be run in virtual machines. You don't want to be doing anything that contravenes the licenses your company agreed to (you did read the license before opening the packaging, didn't you?), so that means server virtualization is out of the question in these cases.

3. with high I/O apps, specialist hardware or dongles. Some applications with high I/O characteristics like databases (or anything that requires tuning to work with the underlying server hardware), grid or distributed SMP applications that need high speed interconnects, graphics intensive apps, or applications that require hardware cards or dongles are a no-no when it comes to virtualization. Don't even think about it.

4. When time synchronization is critical. Virtual machines run their own clocks, and that means the time they keep will diverge from the host server's clock over time. If very small divergences are critical — as may be the case with financial real-time trading or some industrial control systems — then stick to physical systems.

5. When you don't have the budget to do it right. Server virtualization may save money, but to do it properly takes some money, too. That means there's no point going in to a virtualization project half-cocked: if you can't pay for the tools and management systems required to support virtualization technology then you are better off leaving it alone.

6. When capacity is limited. Despite the improvements made in recent months and years, there's no denying that a VM running on top of a hypervisor is not going to perform as fast as a physical machine running the same OS and applications directly.

So if your servers are currently running at pretty much full capacity then there's certainly little point in adding a hypervisor to the equation. You could always buy more servers to run hypervisors on — but virtualization is meant to enable you to cut down on your physical servers, not force you to buy more.

7. When you need to manage encryption keys. Key management is easy on physical servers, but the same systems won't work with virtual workloads that move from physical machine to physical machine. There are solutions and workarounds, but you'll have to investigate them before you can carry out secure key management on VMs.

8. When high availability is baked in to the application. Virtualization platforms like VMware's offer high availability services of one kind or another for VMs. So far so good. But older mission-critical apps may have HA (High Availability) built in, and that may not work when virtualized.

For example, Microsoft Cluster Service with a shared disk will break in environments that allow VMs to move around automatically. The upshot, concludes Garlati, is that if your VM platform provides HA then you better make sure that your apps don't — and vice versa.

9. To save money on VDI. This is a simple one really. Garlati insists that despite the fact that there are plenty of benefits to VDI – better security, for example – you shouldn't expect it to save you money. If that's your primary objective, don't virtualize your desktop.

10. When there's a risk of a virtualization loop. If you try to virtualize the components of your virtualization platform, you could end up in trouble. For example, if your virtualization platform and hypervisors rely on AD (Active Directory) and DNS, and your AD and DNS servers are virtualized, then your hypervisors won't start as they are its waiting for AD, and AD won't start as it's waiting for the hypervisor. It's a viscous circle you should avoid at all costs.