On Virtualizing Your World

I'm not big on buzzwords. They rub me the wrong way. If you need to use buzzwords, then chances are pretty good that I can dismantle your supposed "technology" in a paragraph or less. It's what I do. Virtualization is an interesting thing, in that it's a buzzword where half the time I can dismantle the crap in two sentences, and the other half is split between wondering why people are mislabeling and wondering why people are so rabid about it.

That said, let's get down to the bare metal here. What is virtualization in reality? The no marketing, no lying version.
Virtualization is taking a fixed set of resources, and using them to create an entire "false" hardware environment. In other words, VMWare ESX is virtualization. However, POWER LPARs are not virtualization while WPARs are virtualization. Let's break it down in a list format.

Actually Virtualization

• VMWare ESX, ESXi, Server, and Workstation
• IBM AIX WPARs
• IBM POWER series Virtual I/O Servers
• HP-UX 11iv3 Secure Resource Partitions (SRP)
• HP-UX 11iv3 vPars
• Solaris 10 Containers
• Microsoft Hyper-V
• FreeBSD jails

Actually NOT Virtualization

• IBM POWER series LPAR, DLPAR and microLPAR.
• HP-UX nPars
• Solaris Domains and LDOMs

This obviously presents the question of "where do we draw the line?" The simplest way to explain it is that for something to actually be virtualization, there needs to be a full operating environment interdicting between hardware. In other words, the "virtualized" environments have no direct access to hardware. This is why LPARs are not truly virtualization; an LPAR requires specific hardware resources which are allocated exclusively to it, which it has direct access to. Even when sharing CPUs and memory, you have "minimum" values, which are dedicated hardware allocations. That's why Logical Partitions are Partitions and not virtualization, but Workload Partitions are actually Virtualization and not Partitions. Why is a Virtual I/O Server (VIOs) virtualization? Because it provides hardware interdiction for specific resources - network and storage - for other environments.
In a nutshell; it's not virtualization if the environment has direct access to hardware.

So now that we've established what is and isn't virtualization, let's talk about the obsession with virtualizing everything. I mean absolutely everything. I have seen shops asking if they can virtualize their physical network switches. (No. You can't.) What virtualization ultimately comes down to is a single core principle: turning computing hardware into a flexible resource.
In a traditional data center environment, this server runs this application, and that's all it does. The fact is that this model is expensive by all metrics. You then need to roughly buy everything twice, for fault tolerance. An example in a traditional buildout would be to have a Sun V1280 for your mission critical Oracle databases, and a second V1280 for failover. This means buying two systems, getting the same support contract twice, licensing Veritas Foundation Suite and Cluster for two systems, etcetera. (I will get into various implementations as we go along, so be patient.)

At it's core, virtualization proposes to solve this problem by changing multiple divergent systems into a pool of computing resources and increasing utilization. Instead of two systems with 24 cores and 96GB, you have 48 cores and 192GB. The problem is, that's not how it works. The cold hard reality is that you still have two systems with 24 cores and 96GB, period. The difference is that virtualization lets you say that system A can now run multiple independent, isolated operating environments running different applications which might have different software requirements. In our V1280 example, we might use virtualization to run Oracle and VCS on 12 cores with prctl, then run Apache on 4 cores, then share the remainder between old Solaris 9 applications and environments. So instead of having the system sitting 50% idle, you have the system at 20% idle or less.
This is not a replacement for a situation that people continually attempt to apply improperly. Let's say your V1280 (which frankly, is ancient and slower than molasses in January) is sitting at 5% idle when you're lucky. Your load averages resemble speeding tickets. Virtualization will not help you. Get a bigger system or move databases. People assume that virtualization is a magic wand, and that by virtualizing the Oracle environment, they magically gain resources. You don't. You actually lose resources - anywhere from 3-30% of CPU and memory - to virtualization itself.

Stay tuned, as I go over the various implementations (and non-implementations!) of virtualization, and what they really offer - and really cost.