One Big Thing We ‘Got Right’ With Hardware Compatibility

In my last post, I got on a bit of roll about how the various industry players are approaching client hypervisor hardware compatibility (or not as the case may be).  Now that I have that out of my system, I thought I would begin to describe some of the things I believe we did right with our approach for NxTop.  I’ll start with a big one:

NxTop is compatible with, but does not require, Intel vPro and VT-d.

Several of the other client hypervisor products in works are being centered on Intel vPro.  This makes sense on one level, since vPro is at its core a management and control point that is independent of the operating system. A client hypervisor is a very logical extension of that. The rub is that there are many corporate PCs with years of life remaining in them that are not vPro enabled.  There are also many enterprises ordering large volumes of PCs who do not want to pay a premium for vPro-enabled PCs for all classes of users.  When you are dealing with hundreds of thousands of PCs, any incremental cost per unit adds up very quickly, so this is a real consideration in today’s budget conscious times.

One of the major stumbling blocks of server-based desktop virtualization is that while it offers significant management and security benefits, it can generally only be deployed for a subset of an organization’s users.  Limiting client hypervisor compatibility to the highest end of the corporate PC market and not providing backwards compatibility with existing business class PCs would impose the same limitations on the adoption of client-side virtualization.  For obvious reasons, we did not want to see that happen.

The primary aspect of vPro that is relevant to client virtualization is Intel Virtualization Technology for Directed I/O (VT-d).  VT-d extends the base Intel virtualization extensions for the x86 architecture that exist in most business class machines today (VT-x) to include an input/output memory management unit (IOMMU).  The IOMMU makes it possible to securely assign physical hardware components directly to specific virtual machines.  This has many practical uses (particularly in overcoming performance challenges in areas such as graphics), but it has some major downside in that it requires hardware-specific drivers in each virtual machine and makes supporting the full array of graphics cards quite challenging.  Stay tuned for more on this in a future post.

With NxTop, we have achieved a very high level of performance without reliance on IOMMU.  This enables NxTop Engine to run on any platform with VT-x.  So when we go into an enterprise where they are currently buying the latest Dell E-series PCs but they have a bunch of older D630s (usually with a mix of Intel and NVIDIA graphics chips), it’s never a problem to get started.  We are not talking to the client about a utopian management model in the future when all of their current PCs are in the graveyard.  We are saying, “Hey, let’s gets started—TODAY.”

With this as a backdrop, I do not in any way want to leave the impression that we don’t see value in both vPro and VT-d/IOMMU functionality.  Continuing innovation from the processor manufacturers will only expand the set of management and performance features we can offer as part of NxTop, and we are embracing this innovation with open arms.  However, we don’t think client virtualization can take off without support for a wide range of PC platforms both new and existing.