Emulation, paravirtualization, and pass-through: what you need to know for client hypervisors

Since desktop virtualization is fairly new, no one's really started out their careers from scratch focusing on this space. Instead, people start in another area of IT and kind of "fall into" (or are forced into) desktop virtualization after they've been working awhile.

Since desktop virtualization is fairly new, no one's really started out their careers from scratch focusing on this space. Instead, people start in another area of IT and kind of "fall into" (or are forced into) desktop virtualization after they've been working awhile. And those people typically come into desktop virtualization from one of two areas: either they're historic "desktop people" (who probably have a history with Citrix or SMS), or they're "server virtualization" people with a history with VMware in the datacenter. Each path to desktop virtualization has its advantages and disadvantages. Legacy desktop people know more about all the little things that make managing desktops hard, like user profiles and application conflicts. Legacy server virtualization people are better equipped to scale and run server-class hardware, and they understand more about the nuances of hypervisors and hardware virtualization in general.

Even though the two groups are coming at desktop virtualization from two different perspectives, the "client hypervisor" is probably the perfect place for them to meet. I've written quite a bit about client hypervisors over the past few years. Most people reading this are probably familiar with startup companies Neocleus and Virtual Computer who are both shipping Xen-based client hypervisor-based desktop management products today. And most of you probably also know that both VMware and Citrix are working on client hypervisor implementations of their own, and that they both have eluded to releasing products before the end of the year.

My point is that even if you don't know too much about client hypervisors today, you're going to hear a lot more about them in the coming months. So I thought it'd be important to take a look at some of the various virtualization techniques a hypervisor can leverage. These can most easily be broken down into three groups:

  • Emulation
  • Paravirtualization
  • Hardware pass-through

Legacy desktop people have probably heard of one (or more) of these virtualization techniques, but it's easy to not really pay attention since virtualization has typically been a "server thing" that hasn't affected us desktop people too much. But now that client hypervisors are immanent, we desktop people actually have to pay attention to the differences between emulation, paravirtualization, and hardware pass-through virtualization techniques.


Emulation is probably the virtualization technique that most of us think about when we think about hardware virtualization. As its name implies, emulation is where the hypervisor emulates a certain piece of hardware that it presents to the guest VM, regardless of what the actual physical hardware is. When emulation is used, you get the classic benefit of "VM portability," meaning that any VM can run on any hardware. (And this makes sense, since the guest VM only sees the emulated hardware, not the actual physical hypervisor.

So emulation has great and broad portability, but at the expense of performance. The problem is that the hypervisor has to pick the "lowest common denominator" when deciding how to deal with a broad variety of physical hardware. So this is where you get that generic VGA graphics card inside your VM even if you have a physical badass GPU. And if the guest VM only sees a generic VGA card, then that's all it can use. You won't be able to run cool graphics or Aero or anything if your hypervisor is only emulating something generic.

Emulation is also responsible for the biggest "performance penalty" when virtualizing. This makes sense if you think about it, because the hypervisor needs to receive the instructions for the fake hardware it's emulating and then translate those to whatever the real hardware needs.

Advantages of Emulation

  • Widest hardware compatibility
  • More portable images

Disadvantages of Emulation

  • Worst user experience
  • Worst performance


Paravirtualization is a technique where the hypervisor exposes a modified version of the physical hardware interface to the guest VM. The idea is that since emulation "wastes" a lot of computational time doing those translations, a paravirtualization setup will let the guest VM have special access to certain aspects of the physical hardware.

In theory, paravirtualization is really great. You get good performance and some portability. The downside is that it's a new way for the guest to access the physical hardware through the hypervisor, so you need hardware, a hypervisor, and a guest OS that are all in agreement on what can be paravirtualized. In the real world this means that your paravirtualization hypervisor will only support certain hardware in certain configurations. You also need to have a guest OS that's been "enlightened" to understand that it should use the paravirtualized hooks into the hardware instead of the "real" hardware. So that requires cooperation between your OS vendor, your hypervisor vendor, and probably your hardware vendor.

Advantages of Paravirtualization

  • Good image portability
  • Direct hardware access is possible

Disadvantages of Paravirtualization

  • Complex driver architecture
  • Compatibility is limited by the vendors

Hardware pass-through

As the name implies, hardware pass-through means that the guest VM has direct access to the physical hardware. The hypervisor literally lets it "pass through" to the hardware. Hardware pass-through is the best possible performance for the guest VM since it's essentially the same speed as if their was no hypervisor at all.

Sounds great, eh? Not so fast… Of course there are downsides with hardware pass-through too, namely, that you need to have the proper drivers for the real physical hardware that's being passed through to your VM. This means that you lose VM portability across hardware of different types.

Hardware pass-through also gets complicated with certain versions of the CPU and chipsets. As you can probably imagine, Intel and AMD are constantly looking for reasons for people to buy new processors. (This is where you get all that V-Pro and VT-x and stuff.) So one of the features of VT-x is that it can allow multiple VMs to access the same hardware via pass-through at the same time. (So your hypervisor could pass through the physical GPU, and you could have two VMs running Aero glass at the same time.)

The other cool thing about hardware pass-through is that you can continue to use all of the little apps that ship with your laptop... I'm talking about the Dell-branded network utility and battery meter and thumbprint reader. Since you're using native drivers with a pass-through hypervisor, all this stuff appears to the guest exactly as it would as physical hardware.

Advantages of hardware pass-through

  • Best user experience
  • Native performance

Disadvantages of hardware pass-through

  • Hardware-specific images

Putting it all together

Now that we've looked at the three flavors of virtualization available to the client hypervisor vendors, let's try to put it all together.

First of all, it's important to point out that a single client hypervisor product can leverage more than one kind of virtualization. Maybe a product will provide pass-through GPU access with paravirtualized network and an emulated disk drive?

Second, there's no reason the client hypervisor can't support more than one type of virtualization for the same part of a computer? Maybe they include the most common drivers for ATI, NVIDIA, and Intel GPUs, so if the VM finds one of those, you get good graphics via pass-through, and if the GPU is not recognized then you just get a generic emulated VGA adapter? You could take that a step further by tossing the CPU and chipset into the mix. Assuming the GPU is recognized, maybe you get pass-through in all VMs if you have Intel VT-x, but if not then you just get GPU pass-through for one VM while the others use emulated generic VGA adapters?

Next steps

The client hypervisor space is so immature it's *almost* not worth thinking about yet. The two products on the market today seem to be updated every few weeks, and the big players don't even have betas out. (And the elephant in the room, Microsoft, hasn't even announced what they'll do in this space?) So most people are sort of holding off another year or so to see how everything shakes out.

That said, client hypervisors are going to be huge, and it's vital that we as desktop nerds understand them.

Dig Deeper on Virtual desktop infrastructure and architecture

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

For Citrix, I wonder where in the xendesktop stack this will sit in regard to licensing of the management component? If you were going to go xendesktop now you wouldn’t want to get stung later by getting the wrong edition. Will it be available a separate offering? hmm.


Good summary Brian. Great progress is being made on the client hypervisor right now. The next thing we have to sort out is how we manage client virtualization. Clearly we want it to be as similar to managing a hosted virtual desktop as possible but clients are very different - limited network connectivity is just one such difference.

I figure we have time while the client hypervisors are maturing to decide how we do this.

Martin Ingram (AppSense)


In thinking about what a "client hypervisor smackdown" would be considering in a couple of years, there are so many things that you will need to talk about in future posts!  

Clearly, we want to measure the performance of those products, probably on different hardware.  The driver aspects you mention will be part of the equation, but how shared resource management on the box  (CPU, Memory, etc) will also be important.

Additionally, all hypervisors and guest OSs will probably want to morpf further due to performance.  For example, a single hypervisor based file-memory cache might be much more efficient than one in each OS.  Then there are the OS things done today that stop making as much sense in a VM - such as spinlocks (but we arer only beginning to understand those impacts).

Our concept of portability will expand also.  For example, if something in a VM gets paravirtualized, that means that the kernel is modified.  Is this done in a way that can be really removed if you port the VM to a situation where it is no longer needed? (Yes, you can "uninstall" enlightenments but that doesn't mean it is all restored).

All fodder for more posts in the future, Brian!


Great summary of the various techniques used in client virtualization Brian.  From a market momentum perspective, though, we are seeing huge demand for the technolpogy right now and have customers rolling it out to solve their gnarly client management and security isses.  This technology is being received by customers at a far faster pace than application virtualization was in the early days (circa 2002/2003) and my experience tells me that there is even more upside.  


Moka5 TODAY providea the best in class management stack for Client Hypervisors. Yes today it is only for Type 2 but there is no reason they can't port it to Type 1 one once those technologies are mature.

There is myth our there about security and Type 2. Yes there is a very samll chance that you may get a rootkit on a hostile host running a Type 2 etc and get infected, I bet most people don't give a crap, just look at the number of people that still allow admin rights on their "Secure" PCs. If you guest is say a corporate asset with a secure build and that is as secure as you want it to be. Well then stick Moka 5 on top of it and improve the user experience with all the management and policy that you need. Don't think ACE unless you are a moron, it's does not even come close in terms of management, it's years behind.

Also you can enable this on MAC today, and of course those 110% secure and never have security issues :-) Greater point being decision makers will think MAC is cool.

Don't forget that hardware refresh cycles to support Type 1, driver compat issues as Brian points out above, immmature mgmt and policy for Type 1 will take YEARS (at least 5 years) to sort out. Netbooks are CHEAP and getting more powerful, yet a tiny % are capable of running Type 1, they will also be around for years.

So why waste time waiting for Type 1. I agree it will happen in a long time from now. Type 2 done securely is possible now with advanced mgmt on a broad set of hardware including MAC. The problem with the bloggers and the community is that they have drunk the vendor Type 1 cool aide and are missing the real value. That is reduce management costs of your mobile fleet now in a secure manner with rich policy.


@appdetective - While I generally agree with most (if not all you've said), I need to disagree here.  I'm in complete agreement that Type-1 is immature.  I also think that Moka5 is quite mature in it's offering.  Where I take issue with your comments is where you're bringing up usage of a managed Type-2 (like Moka5) in conjunction with the use of Netbooks.  Have you actually tried this?  Running two OSs on top of most Netbooks is a HORRIBLE user experience.  Most Netbooks lack the power to run their single OS well let alone a secondary OS.  Sure I could purchase one of the higher end netbooks for close to 1k, but then why buy a netbook at all?  I don't think that's sound advice.



By the way, I should have clarified in my prior post that I am the CMO at Neocleus, one of the vendors mentioned by Brian.  I don't like to "hide" anonymously when making comments and posts to these forums.  


Bill Corrigan




@Shawn,yes I have tried it and for more light weight offline use it's fine on the medium powered at least 2G netbooks with a decent CPU. Mostly the exception here, but adds a decent capability to a cheap device that is mostly used when connected and avoids me having to buy a $$$ Laptop fo everybody. I can even create a pool of cheap netbooks that folks cn borrow for quick light weight access with occasional offline stuff.

Also this is good for home users, who want to connect and use offline from their personal machines.

For the Laptop use case, my build is like a type 1, I can make that build thinner now so easier to manage and less frequent and add Type 2 on top to add rich functionailty for users with all the poilcy and management there. In my case I also allow personal computers for classes of users in Finanacial services and it's been fine to date due to the policy plus they love MAC.

I can and do this now and am ramping my my efforts. The question will be how well Moka 5 scales etc. So far so good, and a cool use case for my users.


It's my opinion that most people at these early stages should really determine what the problem is they are trying to solve before diving into the "nuts and bolts".

Too often in this space technology/products/vendors get a bad name because us IT folk have a solution and then go searching for the problem.

just my $0.02


Appdetective sounds like you work for Moka lol.

If you have access I would suggest that you run Windows Fundamentals as your host OS if you want a very small footprint.


@rahvintzu. Na, don't work for Moka 5 just come across good products. WinFLP, is the right idea. Perhaps use that as your Type 1 easy to manage thin Laptop build with Moka 5 on top for flexibility. Now I have something to try :-)


If you want to go even more hardcore.

You can try two paritions, first parition WinFLP then see if Windows Steady State will install on WinFLP (not officially supported). Then have your Moka install to the second partition.

Then hide this second partition to end clients.

Lock down firewall and you have a tough build.


Bill, I have actually been trying to get a copy of Neocleus' client hyper visor... I have not been able to get anyone to contact regarding this issue...

I recently talked to Virtual Computer and they decided not to include 3-d capabilities in their shipped version of NxTop...

The other thing I was not sold on is the fact that you cannot treat these hyper visors as true standalone clients.  In the Nxtop case they require a server to manage guest machine (VM) deployment to the client.

I am hoping that Neocleus has an option for a true standalone client hypervisor.  This concept would seem to open the market up a bit more to the end users who have outrageous hardware highly underused by current OS's.

In my case I would love to have a true type 1 that can manage itself.  So I can take my desktop or laptop and have multiple OS installs that do not require a central management server.