Introduction

Over the course of the past couple of months, the AnandTech IT team has been putting a lot of time into mapping out and clarifying the inner workings of several interesting forms of virtualization. The purpose of these articles was not primarily to cover "news" (however current the topic might be), but to create a sort of knowledge base on this subject at AnandTech, as we find many people interested in learning more about virtualization are met with a large amount of misinformation. Secondly, we believe a better knowledge on the subject will empower the people in control of their company's IT infrastructure and help them make the correct decisions for the job.

There's no denying that virtualization is changing company's server rooms all over the world. It is promoting both innovation and the preservation of aged applications that would otherwise not survive a migration to modern hardware platforms. Virtualization is completely redefining the rules of what can and cannot be done in a server environment, adding a versatility to it that is increasing with every new release. We believe that when making big changes to any existing system, the more information that is available to the people given that task, the better.

But what about desktop users?

While the above should make it clear why businesses are extremely interested in this technology, and why we have been digging so deep into its inner workings, we are also noticing an increased interest from the rest of our reader base, and have been flooded with questions about the how and why of all these different kinds of virtualization. Since we don't want to leave any interested people out in the cold, and the in-depth articles may seem a bit daunting to anyone looking to get an introduction, here is another article in our "virtualization series". In it, we will attempt to guide our readers through the different technologies and their actual uses, along with some interesting tidbits for regular desktop users.

"New" Virtualization vs. "Old" Virtualization

The recent buzz around the word "virtualization" may give anyone the impression that it is something relatively new. Nothing is further from the truth however, since virtualization has been an integral part of server and personal computing, almost from the very beginning. To keep using the single term "virtualization" for each of its countless branches and sprouted technologies does end up being quite confusing, so we'll try to shed some light on those.

How to Define Virtualization

To define it in a general sense, we could state that virtualization encompasses any technology - either software or hardware - that adds an extra layer of isolation or extra flexibility to a standard system. Typically, while increasing the amount of steps a job takes to complete, the slowdown is made up for with increased simplicity or flexibility for the part of the system affected. To clarify, the overall system complexity increases, in turn allowing the manipulation of certain subsystems to become a lot easier. In many cases, virtualization has been implemented to make a software developer's job a lot less aggravating.

Most modern day software has become dependent on this, making use of virtual memory for vastly simplified memory management, virtual disks to allow for partitioning and RAID arrays, sometimes even using pre-installed "virtual machines" (think of Java and .net) to allow for better software portability. In a sense, the entire point of an Operating System is to allow software a foolproof use of the computer's hardware, taking control of almost every bit of communication with the actual machinery, in an attempt to reduce complexity and increase stability for the software itself.

So if this is the general gist behind virtualization (and we can tell you it has been around for almost 50 years), what is this recent surge in popularity all about?

Baby Steps Leading to World-Class Innovations

Many "little" problems have called for companies like VMware and Microsoft to develop software throughout the years. As technology progresses, several hardware types become defunct and are no longer manufactured or supported. This is true for all hardware classes, from server systems to those old yet glorious video game systems that are collecting dust in the attic. Even though a certain architecture is abandoned by its manufacturers, existing software may still be of great (or perhaps sentimental) value to its owners. For that reason alone, virtualization software is used to emulate the abandoned architecture on a completely different type of machine.

A fairly recent example for this (besides the obvious video game system emulators) is found integrated into Apple's OS X: Rosetta. Using a form of real-time binary translation, it is able to change the behavior of applications written for the PowerPC architecture to match that of an x86-app. This allows a large amount of software that would normally have to be recompiled to survive an otherwise impossible change in hardware platforms, at the cost of some of its performance.

Hardware platforms have not been the only ones to change, however, and the changes in both desktop and server operating systems might force a company to run older versions of the OS (or even a completely different one) to allow the use of software coping with compatibility issues. Likewise, developers have a need for securely isolated environments to be able to test their software, without having to compromise their own system.

The market met these demands with products like Microsoft's Virtual PC and VMware Workstation. Generally, these solutions offer no emulation of a defunct platform, but rather an isolated environment of the same architecture as the host system. However, exceptions do exist (Virtual PC for the Mac OS emulated the x86 architecture on a PowerPC CPU, allowing virtual machines to run Windows).

Putting together the results of these methods has lead to a solution for the problem quietly growing in many a company's server room. While the development of faster and more reliable hardware was kicked up a notch, a lot of the actual server software lagged behind, unable to make proper use of the enormous quantity of resources suddenly available to it. Companies were left with irreplaceable but badly aging hardware, or brand new servers that suffered from a very inefficient resource-usage.

A new question emerged: Would it be possible to consolidate multiple servers onto a single powerful hardware system? The industry's collective answer: "Yes it is, and ours is the best way to do it."

Slightly Differing Answers to Slightly Differing Questions

So let's have another look at the kinds of virtualization that are currently expanding quite rapidly. To make the distinction of each clear, we'll be working from a basic system model. In the image below, we can see a system consisting of three basic layers: the physical hardware layer, the OS layer that is fully in control of this hardware, and the application layer resting snugly on top.

The way we distinguish forms of virtualization is by acknowledging which layer they affect, and what problem they intend to solve. A basic explanation will be given for each form we discuss, along with a list of products and their potential uses. It must be noted that, though we're used to employing a certain consistent terminology at our lab, readers might find other terms denoting the same technologies scattered throughout the internet. This is one of the reasons we feel a thorough explanation of each technology is needed. There's confusion as to which product offers which form of virtualization that can be avoided.

Without further ado, let's get on with the show.

Hypervisors - the How and Why

We'll start at what is easily the most publicized - and at the same time least commonly understood - technology of them all: hypervisor-based virtualization. Technologies that fall into this category can be divided into two basic types: "bare metal" hypervisors (which are situated between the hardware and the OS layer) and the "software" hypervisors that act as a standalone application.

Our Hardware Virtualization article discusses the bare metal hypervisors in-depth, but essentially both kinds perform the same basic functions. A bare metal hypervisor passes instructions on to the actual hardware, while a software hypervisor passes them on to the host OS. It should be obvious which of the two provides us with the least overhead for the guest OS, but both technologies have very distinct uses.

Bare metal hypervisors are at this point the ultimate solution for running multiple virtual machines while retaining the highest level of isolation and flexibility possible. They minimize overhead by cutting out the middleman (a bulky pre-installed OS) and act as a kind of miniature OS themselves, right on top of the hardware. There are currently three main techniques applied in hypervisor technology.

One is based on Binary Translation, a technique used by VMware to fully translate every single call a virtual machine (VM) makes into one that is safe and non-intrusive on other VM's using the hardware. This requires the hypervisor to do the bulk of the work, but allows any OS to run next to any other OS in an unaltered state.

A second solution for virtualization comes straight out of Intel's and AMD's research labs, and is something we refer to as Hardware Virtualization. While Binary Translation (BT) is able to run quite well on a "conventional" hardware system, as virtualization spread throughout the IT landscape it was felt necessary to adapt hardware systems to better accommodate this rather drastic change in system layout. Both Intel and AMD have made changes to their products (Intel VT-x and AMD-V might ring a bell) to allow for a system that is able to run multiple VMs more naturally. It is not possible to use both hardware virtualization and BT at the same time, but there is another technology that allows improvements for both.

This technology is known as paravirtualization, and it relies on an OS that is altered to be "aware" of its virtualized state. These slightly changed VMs reduce the amount of work a hypervisor needs to do, by simply firing off only "safe" calls, so no translation is necessary. The fact that this form of virtualization requires actual changes to be made to the source code of an OS used to greatly limit its use, but since Microsoft has picked it up (and made it possible to use with Windows Server 2008), it has been getting a lot more attention. The technology can be used in conjunction with either BT or HW virtualization, but is also able to stand on its own, without the use of either.

Again, more in-depth explanations of each of the above technologies can be found in our Hardware Virtualization article.

Examples of popular bare metal hypervisors are VMware's ESX, Microsoft's Hyper-V and various Xen-based products implemented by several companies (among others, Novell and Citrix). Software like VirtualBox, Microsoft VirtualPC and VMware Server and Workstation can be classified as software hypervisors.

When Are Hypervisors a Good Solution?

As much as these companies' publicity campaigns might be trying to sell their products off as the only solution you'll ever need, we are here to give you an objective view of where they are useful.

Hypervisors are a great solution for situations where hardware vastly outperforms the software's needs. Using a "bare metal" hypervisor, every VM is able to make use of the hardware, without being influenced by the others. For a company looking to consolidate a number of varying servers (mixing for example Windows systems with Linux-based systems), using a hypervisor would be the logical step. The big downside of this technology is that each virtual machine needs to run a full operating system to support itself, making the collective resources spent on running these operating systems a rather large bite out of the hardware's total pool.

This also seems to be the main problem when using a software-based hypervisor. While this platform does succeed perfectly in offering most of the VM's guest OS functionality, in performance-based environments the cost of running an extra OS on top of an existing one can make the entire solution a bit bloated for constant use. Nonetheless, the ability to run a completely sand-boxed environment has caused many developers to use hypervisors as their software's playgrounds. Much in the same way, since Apple made the switch to Intel-based hardware, software hypervisors have allowed users of OS X to virtualize a Windows system without actually having to set up a multi-boot system. This goes a long way in proving that they are a very solid solution when actual functionality is more important than raw performance.

How Are Containers Different?

Discussed in-depth in our recent article on OpenVZ, containers offer a different take on virtualization. These solutions are not as easily categorized as the hypervisors, since they tend to be much more varied, as each is based on a specific OS.

Containers are able to "partition" an existing operating system, in order to provide multiple isolated environments to its users. The isolation of resources is attained by implementing several changes into an existing kernel, allowing for a more controlled resource management. Essentially, the adapted kernel takes on the role of "hypervisor and base kernel in one", naturally handling the isolation of each separate container.

The methods used for doing so vary from one solution to the next, but the fundamentals remain the same. Each container is locked into its own part of the host's file system, has its own users and processes, its own network address, and is practically fully customizable software-wise. To the actual user, it is for all intents and purposes a completely separate system.

Cutting out the kernel allows a virtual environment to have a much smaller footprint, since there is no need for a separate kernel supporting it, making it essentially just a separate group of processes on the host OS. Logically, we could state that in a comparison of a hypervisor solution and a container solution on the exact same hardware, the container solution is likely to provide a larger amount of separate systems. Nonetheless, nothing prevents users from combining the best of two worlds, as a container-supporting kernel will still run perfectly well on top of a hypervisor-solution, making systems even more flexible.

More information on how containers actually work can be found in our article on the subject, where we dig deep into the inner workings of the adapted OpenVZ kernel.

Examples of popular container-based solutions are Solaris Containers, OpenVZ, Parallels Virtuozzo, and Linux VServer.

When Should We User Containers?

Considering their limitation to a single kernel, containers are not an ideal solution for pure server consolidation. It might be well deployed in an environment that requires a very large number of similar servers consolidated onto a single platform, but we find that this is often not the case. However, what containers are ideal for is the rapid deployment of large amounts of accessible "servers" - i.e. for seminars or classrooms. Hosting companies have been employing this technology for years, providing their customers with fully functional and customizable "private servers", and the relatively low resource footprints of containers allow the system to be used on servers and workstations alike.

An interesting example of this is what we encountered in our very own lab recently. From time to time, we are asked to perform stress tests on existing web applications, using our in-house developed software, vApus. Quite often, these web servers are already serving people, so it is impossible for us to request our clients to change their system layout to best suit our testing. One particular client required us to test from several IP addresses at the same time, since he had a Network Load Balancing system in place to redirect every request coming from a certain IP to one and the same web server, while there were six web servers present. Instead of going out of our way to set up six separate systems, we simply got a very powerful testing client set up with containers, and used six of them to perform the necessary tests.

While we wouldn't recommend containers as the best solution for actual server consolidation, we are definitely excited about its ability to transparently divide an OS to serve a very large number of isolated virtual environments. Furthermore, it is our opinion that containers are an incredible solution for Virtual Desktop Infrastructures, considering their more than adequate usability and high deployment rates. Given a little more development time, we are convinced that containers will find a solid place in server rooms, sporting many impressive features that will make the virtualized platform as a whole even more interesting.

Desktop Virtualization - What It Is, and What It Isn't

Now that the two main forms of virtualization offering complete systems have been explained, it might be interesting to talk about desktop virtualization. We have noticed a lot of confusion surrounding this term, and wanted to clarify this technology for those who are affected by it.

A common misconception amongst people unfamiliar with desktop virtualization is that it's actually another range of changes in a standard system, which somehow allows users to make use of a "virtual desktop" on their otherwise perfectly normal system. Confusion tends to arise when thinking about what exactly needs virtualizing about something as basic as a desktop, and what purposes it would serve, so let's get this misunderstanding out of the way from the start: desktop virtualization is not as simple as isolating your desktop from the rest of your computer system. In fact, the term "desktop virtualization" is a bit confusing altogether when put next to hypervisors and containers.

Instead, we can think of it as a way to "consolidate desktops" onto a centrally managed system, much in the spirit of terminal services, in an attempt to reduce workstation sprawl on a company network. Desktop virtualization, or VDI as it is commonly referred to, is in fact a combination of technologies that make it possible for people to log in on their private virtual machines (be they hypervisor- or container-based) from some other place on the network. This prevents company data from spreading outside of the IT administrator's influence, and makes the act of troubleshooting a specific problem a lot more convenient than having to run around half the building to find the culprit.

Generally, the system employs a protocol much like Microsoft's Remote Desktop to be able to work freely on their virtual machine, without ever having to interact with the actual hardware directly. Security and authentication systems may be in place, ensuring the right people get assigned to the right virtual machines, and taking care of possible break-ins. The actual system used to log in remotely might be anything, ranging from a thin PC to its bloated cousin, the regular workstation.

Companies that are currently working hard on improving their desktop virtualization solutions are VMware and Citrix.

Application Virtualization - the Odd Man Out?

Now here's a technology that is completely unlike the ones mentioned above... or is it? Application Virtualization (or AV in short - not to be mistaken with "Antivirus" software) is the collective name for software that is focused on isolating single applications, usually by providing a sort of wrapper around these application's working components. They provide the application with a sort of sandboxed environment, protecting the operating system (most notably the file system and registry) from being affected by it in any way.

This isolation requires the wrapper software to "fool" the software in question into believing the file system and registry it is presented with are the ones it needs, while in fact they are simply simulated and all the software's data is safely kept away from the actual OS. A nifty byproduct of this is that, as long as the wrapper software keeps simulating the same computer state, a "wrapped" piece of software is technically able to run on any computer, fully installed, which greatly simplifies the distribution of software across networks.

You might see links to the Java Virtual Machine or the Flash Player at this point, as both allow software to be distributed regardless of platform. Wherever the player is installed, the software will run, and the comparison does stand quite strong. However, the technology we are talking about is aimed at taking on any piece of software, regardless of the language that was used to develop it.

In companies, AV software will often include a possibility of software streaming, allowing the software packages to reside somewhere else entirely rather than on the actual user's computer. This allows a company total control over who is able to use each piece of software, since they can require their employees to access the company network to be able to work, or configure the wrapper software in a way that will deny access to the software when certain conditions aren't met.

Application virtualization solutions, and the types of virtualization discussed in previous pages, are a prime example of the business IT market moving towards a more centralized management of company resources. As each technology matures, we expect them to spread even more than they already have. As you might remember, we believe a firm base knowledge about each of them will go a long way for anyone bound to encounter them.

More information on Application Virtualization and a line-up of the products available can be found in our article on the subject.

Some Fun Virtualization Feats for Desktop Users

Now, to say that virtualization only has its place in server rooms is not entirely correct, since it has certainly left a stamp on desktop environments as well. We'll definitely be diving into this subject more in future research, but we still want to give you a taste of it.

While not immediately important to Windows users, a rather large group of people would like to be able to enjoy some of the same luxuries with regards to gaming: Mac OS X and Linux-users. At this point, we are looking into three different technologies that make it possible for Windows games to be played on different systems. Two of them are integrated into host-based hypervisor solutions for OS X: Parallels Desktop and VMware Fusion. The last of them uses a completely different approach, utilizing a dynamic translation layer to translate a game's calls directly into something handled by the host OS.

To get some first impressions on these technologies, we tested the same game on each of these pieces of software: Half-Life 2, a personal favorite, and not quite old enough to be considered completely unimportant yet. Now, to be fair, our expectations were never too high. The overhead created by an actual host-based hypervisor can sometimes be high enough to make some relatively simple tasks too tedious to undertake, so something as intensive as gaming could easily be too heavy. As it turns out, we were quite surprised by the results!

We started our experiments on Parallels Desktop, running on the only Mac system available to us: a two year old MacBook Pro outfitted with a 2.33 GHz Merom, 2GB of RAM and an ATI Radeon X1600. We assigned the VM 1.25GB of RAM in an attempt to make it run as smoothly as possible without choking our host system too much. When setting up Steam and attempting to start the game, we were met with the following dialogue.

Brave as we are, we decided to push on anyway, and we met with some surprising results! The game turned out to be quite playable, chugging away at a less than stellar frame rate, but relatively stable and playable nonetheless.

The recommended settings for our little setup were not quite at the minimum yet, but sadly we were unable to make any changes to them and experiment, as every single change in the display panel caused the game to crash. [Ed: Normally HL2 stores the game settings in the Windows registry; you might try modifying that directly.] Apart from some small graphical glitches, however, we found the game surprisingly playable, despite its absence from Parallels' compatibility list.

With our interest piqued, we decided to try it next on VMware Fusion, in an attempt to make a little comparison. Alas, VMware Fusion appears to deem the world of Half-Life 2 too far gone to warrant saving, and as such, we are unable to move past the actual menu screen. Seeing what it looks like, however, makes us inclined to agree...

The fact that these solutions differ so much makes us wonder about the differences in implementation of 3D acceleration, and our readers can expect us to look deeper into this later on. It is clear VMware Fusion and Parallels Desktop both take a very different approach, and once again it is our goal to figure out why they've decided to take a certain route.

A third solution tested for gaming purposes is Crossover by Codeweavers. This software is closely related to the WINE project, which aims to make software written for Windows usable on any Unix platform. WINE is a recursive acronym, standing for "WINE Is Not an Emulator", meaning the software doesn't actually provide the software with a suitable environment to run in, but rather dynamically changes the way the software interacts with the system, much like what happens with Binary Translation.

As with the other solutions, we ran Half-Life 2 in Crossover, which is by and large a supported implementation of WINE for both Mac and Linux systems. To our great surprise, we were able to play the game at pretty much the highest settings (barring AA), with a surprisingly strong frame rate, holding up at a solid ~30 FPS in open areas. Since FRAPS wouldn't work for us in Crossover, however, we were forced to use the built-in console functionality to display the frame rate and OS X's screen capturing tool to get our screenshots (which apparently caused a large dip in frame rate every time we attempted it).

Generally, when played the game felt as smooth as it should be and didn't give us even the slightest hiccup performance-wise. However, one thing did strike us as familiar. Some of the (minor) graphical glitches encountered remind us of what we experienced while testing Parallels Desktop. Could it be that these two pieces of software are using related techniques for their 3D acceleration? Stay tuned, as we will definitely be looking into this in further research!

Conclusion

Virtualization should never be seen as a simple solution to a specific problem; that is the main idea we have been trying to convey. It is a principle, a technology that is applicable in a very large range of different solutions. It is also a buzzword to get cash flowing nowadays, and is heralded by a lot of companies as "the next best thing in IT".

The purpose of this article is to make clear that we believe the current wave of virtualization will in fact make very big changes in datacenters as we know them, but also that it is not some new "holy grail of IT" and has always been a part of it in some way. It's important not to get carried away by all the recent hype surrounding the subject, but to understand each technology's purpose and how to make use of them in the most efficient way possible.

We hope our series of articles has helped or will help those readers who are looking into really understanding what virtualization is all about, giving them a solid base to fall back on in future decisions. It has certainly been a very interesting couple of months at our lab - learning and teaching about virtualization - and we don't doubt many more interesting virtualization technologies will grab our interest. Having spent quite some time focusing on the business side of virtualization, though, it will be interesting to check out the ways it is applicable in desktop situations, so look forward to either some blogs or an article on that in the future!