Virtualization – Under the Hood (Part I)

Sometimes we take long pauses thinking about something someone said. We are not discarding what is being said, but we are not acknowledging it either. Sometimes, the person repeats the same sentence again, maybe in different tone or structure. And we may continue to pause, although we may shift our eyes to the speaker’s eyes to express a less formal way of saying: I heard you, but I am still thinking about it! It may take some time before we let the first word out of our lips, just to start the conversation.

Virtualization is not a new concept by any means. It started in the 1960s as a form to virtualize memory to trick system applications into thinking there is more memory to play with than there actually is.  This evolved into the concept of time-sharing on mainframes where individual applications were made to believe they have all the resources they need, although shared and restricted in time.  I am going to skip a few generations to talk about today’s virtualization to avoid duplicating what could be obtained from well-maintained definitions and history lessons on virtualization all over the Internet. However, the exhibition of long pauses over the concept of virtualization and its potential extended over generations rather than a few seconds before we realized what we really have at hand.

VMware is certainly the leader in the market today through its vSphere offerings, with Microsoft’s HyperV behind but making long strides to catch up. There are many other virtualization suites offered by Cisco (mainly around unified communication services), Citrix (mainly around virtual desktops), and open source hypervisors such as xenapps.

We hear a lot about virtualization. But, it is like one of those topics that you “know” but you don’t really “know”.  We all know why objects fall towards the center of the Earth, but we don’t really know “why” objects fall towards the center of the Earth (we know gravity, but we don’t understand why negative and positive charges attract). We always hear about virtualization. It is a catchy word in an industry with a long list of names, acronyms and abbreviations.  But, do we all know the basics of how it works? What it is? How it can answer some of the main enterprise questions that haunt administrators during their sleep? How it can actually add its own set of issues that make an administrator’s nightmare not so … virtual? I explored some of those questions and decided to take a few minutes from my sleep (that is the only way my hypervisor can lend me those valuable resources) to share them here. I will address those in the form of questions and answers, simply because that is the easiest way to get to the point without dancing around it.

Q: Is virtualization a software or a hardware technology?

Short Answer: Both.

Long Answer: There are two types of hypervisors (Type 1: runs directly on the hardware, and Type 2: runs on a host OS). Type 1 is a hardware virtualization solution simply because that plays well with our definition of hardware (we define hardware to be anything below the supervisor code in an OS, and since hypervisors are below the supervisor code, then it is a hardware solution). However, there is another type of hypervisors, type 2, where the hypervisor runs on top of the host OS as another application. This is not very common for a lot of reasons including the requirement to modify the OS to accommodate virtualization, OR settling for a major overhead by the hypervisor to do the translation to host OS terms and not being able to optimize drivers. The conversation is too deep for this post, but there are many types of hardware virtualization (hardware-assisted virtualization, paravirtualization, partial virtualization, etc.) where you have a mix of hardware-assisted virtualization added to software-ful hypervisors.

Q: Why virtualize?

Short Answer: To get the most out of our idle resources today.

Long Answer: How much time do you have? There are a lot of reasons to virtualize your OS and its applications. Here is a short list:

1. Most applications today utilize around 10-15% CPU. With virtualization, that utilization increases. “Virtualization is extraordinarily expensive if the number of VMs fall below 10 on a physical machine” (Mike Rubesch – Purdue University Director of IT infrastructure systems.) You also have to think about the overhead to run the hypervisor which will take a few CPU cycles as well.

2. Less physical space. If you combine 10+ applications on the same physical host, you could potentially decrease the number of your servers by a factor of 10+.

3. Quick turn-around. It is much faster to create a VM from a VM template than to build a machine.

4. Introduces leaner process. The concept of leasing VMs and expiring them enables IT administrators to build VMs for a pre-determined length of time. In traditional systems, such a machine may go unused after a certain period of time, adding more overhead and headache.

5. Easy to handle disaster recovery (DR), high availability (HA), and fail-over (FA) as most of virtualization suites include tools to easily manage those concerns (such as vSphere’s and HyperV’s HA and FA products, enabled by vMotion and Live Migration).

6. And many other reasons that I don’t want to talk about here including: one stop security management, lower energy cost, self-contained infrastructure requirements, portability of machines, etc.

Q: What are applications that are best kept un-virtualized?

Short Answer: Applications that require fastest possible responses or CPU-bound.

Long Answer: You can virtualize everything, but you cannot offer more bandwidth throughput than your server can physically handle. All applications requiring heavy I/O such as databases and other applications that write to disk, may be tremendously slowed by virtualization. I have come across a few companies that refuse to virtualize their database servers. Furthermore, since virtualization is an overhead (an additional layer between the application and hardware that does more management and work across all VMs on the same physical machine), you can actually see slowness in running your application. Although the worst of those were no more than 20% decline in performance, nowadays, you rarely see such high declination levels, but overhead is definitely above 0%. So, if your application queries the hardware clock for nanoseconds, then maybe it is not a good idea to run it on a virtualized machine.

More to come…


One Response to “Virtualization – Under the Hood (Part I)”

  1. Virtualization – Under the Hood (Part II) « Moe's Blog Says:

    […] Moe's Blog Random thoughts… « Virtualization – Under the Hood (Part I) […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: