10 Myths of Virtualization – Busted
I’ve been taking a close look at some virtualization technologies both on the client and server side. Here are a few pointers to understanding what’s happening out there – presented as 10 myths.
1. Virtualization is a ground breaking technology
Well, not really. First of all virtualization, as a technique, has been around since the 1960s. There are three major uses of virtualization:
- OS virtualization, as with VMware, which separates the OS from the hardware. IBM was doing this in the 1970s but VMware had the neat idea of making this available on the commodity Intel platform. As a consequence OS virtualization is now de rigeur, so everyone and his dog offers OS virtualization. Note that desktop virtualization is just OS virtualization but the associated technical arrangements can be complex.
- Resource virtualization means making one resource emulate and substitute for another. So virtual memory is disk pretending to be memory. RAID disks make a collection of disks appear to be one big disk resource. Network virtualization turns physical wires (or fiber) into multiple channels with variable bandwidth.
- Application virtualization means abstracting an individual app from its native environment so it can run anywhere. There are many ways to do this and many complexities, but most application are now written in a language that’s portable (C, C++, Java and just about every kind of scripting language). That makes life a little easier, because very little application code is going to be hardware or platform specific.
What happened that made a big difference is that technology just keeps getting faster and it makes virtualization a sensible thing to do in many environments. By about 2004 most commodity Intel servers were running at maybe 6% efficiency or even worse. Virtualization could raise that level of efficiency. When power consumption became a data center problem there was suddenly a huge incentive to use virtualization for server consolidation.
2. OS Virtualization optimizes the server infrastructure.
OS virtualization doesn’t optimize anything. It makes use of unused resources, and it is a powerful capability for doing that, but it doesn’t necessarily make the best use of such resources. The point here is that virtualization itself needs to be co-ordinated within an optimization framework – which will need to be at least partly automated and will make use of performance measurements. Such a framework will naturally use virtual machines where sensible and it will carry out the optimization because it has the information to do that.
3. OS Virtualization optimizes the use of an individual server (or server blade).
Again virtualization doesn’t optimize anything. The point is that running anything extra on an underutilized server makes better use of the server. The simple truth is that many servers have been deployed running only one application. Under Windows particularly, but also under Linux, it is possible for one application to interfere with another, if you run them under a single OS. By running applications under separate OSes, even if you are running on the same machine, you achieve a kind of “shared nothing” software environment. So, if an application fails, then it will not be because another clashed with it.
But if VMs were a really good idea, we’d have been running them since Bill Gates was a boy. There is a very real overhead to running multiple virtual machines on a single server – it means you have to run multiple operating systems and each of these presents an overhead. You can end up with the situation where most of the work being done by the server is in running the hypervisor and running the operating systems. If you weren’t doing anything with the resource anyway, then it doesn’t matter if this arrangement isn’t maximally efficient, because you’re running more applications on the server than you were before.
Let’s be realistic. Server virtualization can certainly take you to somewhere in the region of 60% utilization without causing resource clashes and even if half of this usage is the hypervisor and the OS, you are still getting 30% real work from the server where previously it may have been below 6%.
4. If you are going to partition a server you have to run virtual machines in each partition.
Virtualization is about partitioning resources between competing needs in order to make better use of resources. You don’t have to do this by setting up virtual machines. There’s a company called Trigence which takes a different approach. Instead of deploying virtual machines it deploys “virtual applications.” Here’s how it works:
It has a hypervisor that runs all the applications, but it packages the applications up so that all the components of the OS that the applications need are kept with the application. In this way it can run Windows apps under Linux, simply by holding and executing all the Windows components (DLLs etc.) in a single partition. The advantage is that it is likely to be more efficient than running whole OSes, but it is still a shared-nothing environment.
5. Server virtualization should involve the dynamic provisioning of VMs.
Dynamic provisioning is a great idea. You monitor the network as a whole and all the applications that are running and you predict traffic (based on current trends and previous patterns) then you dynamically allocate all the resources needed to meet the service levels of all the business processes involved – neatly adding new resources if any device anywhere fails.
This is the same idea that the IT industry had decades ago when it was trying to squeeze as much as possible from very expensive mainframe computers. As computers fell in price most IT users ceased to care about optimization. If you wanted more power you just bought another cheap computer and clipped it in. Optimizing a single mainframe was not a cake-walk and optimizing a network of hundreds or thousands of servers is not a cake walk either. Doing it dynamically (in a way that’s effective) is beyond the capabilities of current technology.
So dynamic provisioning of VMs doesn’t make sense right now, because we are only just learning how to provision VMs effectively in a manual way. Also there’s a gotcha here – anyone who’s in charge of a large data center would probably not allow automated dynamic provisioning, just in case it just happened to screw everything up. The closest we can get right now is to have software that can suggest specific provisioning actions, which someone can choose to do if the suggestion seems sensible. There are many issues that make dynamic provisioning complex, from fail-over requirements on the technical side to licensing complications on the business side. But most of all, right now it’s simply not an imperative, because there’s no guarantee that it will deliver more than can be achieved using manual intervention.
6. Virtualization reduces the problem of managing servers.
This is not really true. All that server OS virtualization does is reduce the number of physical servers. Doing this may create some unexpected hardware effects – like for example changing traffic loading on the network and hence requiring network reconfiguration or maybe even upgrade. In physical terms the “net net” is likely to be very positive – especially in terms of power consumption. However, in software terms you are still managing the number of servers that you were before and the situation is likely to be more complex because you no longer know exactly what is running where. So that means you now have to track the location of all software in real-time, so you can fix an application properly if it breaks.
And that, of course, is why VMware has a great business in providing the management software for managing virtual machines.
7. Virtual environments are more secure because no intruder will know where software is running.
If a talented intruder gets into your network he/she can find out where things are running very easily by listening to the packet traffic on the network. That’s what dynamic discovery software does and hackers can use such software too. Virtual environments are less likely to be secure rather than more likely because, right now, there is no simple way to map the dependencies between security software and the applications it protects. If the virtualized environment gets complicated then unintended security holes could open up.
The fundamental problem here is that the security software is not build into applications. Instead it tries to surround them to protect them. But if you move applications about regularly, it’s entirely possible that you just might move one of them “outside the castle walls”. Until security dependencies are explicit and mapped, inadvertent vulnerabilities are bound to occur. This, by the way is another problem with dynamic virtualization – it needs to keep track of, and enforce, security.
8. You can virtualize all the PCs and desktop computers in the organization.
It may be possible, but probably not. In general it’s possible to virtualize “standard desktops” – say about 80% of the typical desktop population. It’s the high-end machines that are difficult to virtualize. Even some of these can be virtualized (HP has particularly good technology for this), but it’s unlikely that you can do them all.
And just in case you think this is just like server consolidation, it isn’t. Desktop virtualization is complex for quite a few reasons, but the important point to understand is that you are not virtualizing the PC specifically. You are virtualizing the access capability, so that the user’s capabilities live in the network and can be used from different access points (maybe a thin client, or laptop, or desktop PC).
9. A virtualized PC is cheaper than a real PC.
You’ll find that it isn’t (at the moment) because there’s a very definite start-up cost. You need a thin client and a portion of a server and broking software and the Microsoft license doesn’t vanish and the virtualization software doesn’t cost nothing either. However, the cost of ownership of the virtualized PC is going to be much lower in almost all cases.
10. Eventually every environment, access point or server, will be virtualized and we’ll run everything from a browser.
It’s a beguiling idea and if we were to freeze the user interface, it definitely would be true, because eventually we’ll split applications in a AJAX-like way, with the interface running wholly on the client and everything else on the server. This actually could transpire in the corporate environment in some areas of usage given time.
However the trends tell me that computing has been driven by the user interface ever since the first user was invented. Interfaces cause obsolescence and thus are the heart and soul of consumer computing. They’ll be selling us better interfaces in 50 years time, I’m sure. And as employees we’ll encourage our organizations to adopt such interfaces too – for the sake of “productivity.”
The IT vendors need to sell us hardware in order to sell us the interface, so they’ll develop teh Interface on the front-end device for as long as they can.
This is a posting in the Virtualization Focus Series. Click here to see an index of such postings.















Great post, Robin, very interesting. Your comment that, “computing has been driven by the user interface ever since the first user was invented,” struck me as quite profound.
With regard to your sixth myth — reducing the problem of managing servers — Managed Objects couldn’t agree more. Our CTO argued in part, that a service or dependency model is perhaps a prerequisite to server virtualization for this very reason. His article can be found here: http://www.gridtoday.com/grid/2199895.html
“VMware had the neat idea of making this available on the commodity Intel platform…”
To be fair, this wasn’t just a neat idea. It was a pretty brilliant hack on Mendel’s part. People had always assumed x86 couldn’t be virtualized because it wasn’t Popek Goldberg compliant. Mendel’s insight was that the conditions in which the sensitive-but-not-privileged instructions executed were actually finite, and could be handled in software workarounds. Kudos to him!
Thanks for the contribution. This was a technical nuance I was unaware of.