We talk about client hypervisors quite a bit, but everyone seems focused on Citrix and VMware. The problem is, VMware has all but canceled its Type 1 client hypervisor,
News on Citrix acquisition of Virtual Computer
Citrix acquires Virtual Computer for NxTop
Citrix integrates NxTop and XenClient
Virtual Computer has been around since the dawn of the client hypervisors, which is to say ... 2008. NxTop is not a full virtual desktop infrastructure (VDI) solution because it does very little that involves hypervisors in the data center or remote display protocols. The product does, however, provide the ability to connect to existing VDI and server-based computing environments.
Last year, Virtual Computer announced a partnership with Quest Software that resulted in the ability to share a single image (when using Hyper-V) between Quest's vWorkspace desktop virtualization offering and Virtual Computer NxTop.
This means that a user could access his desktop via a thin client in the office, then "check out" that image for local use on an NxTop-enabled laptop. The laptop would then synchronize any changes back to the data center so that they are waiting when the user returns to the office and turns on the thin client. This is the ultimate scenario for a lot of companies, and only two products today use a Type 1 client hypervisor for this capability. (The other is Virtual Bridges' Verde Leaf.)
The NxTop Center management console is fairly straightforward to install and configure. But note that it imports users and groups from Active Directory rather than plugging directly in, so you must know where your users, desktops and groups live in the directory ahead of time. Within a couple hours, you should be able to deploy a desktop to test the product on your own.
NxTop Center runs on Hyper-V, which is required because the NxTop Engine that runs on the client uses Xen as its hypervisor. Hyper-V and Xen are feature-compatible, so you can build an image on Hyper-V and load it in Xen with little effort.
Since this is a client hypervisor system, the only parts that run on Hyper-V are the source virtual machines (VMs) and any forks you might have with different configurations. You could wind up with many VMs on a Hyper-V server if you choose to go with persistent virtual machines, but even then, the only time they actually run on Hyper-V is during any changes that you make. The bottom line is that you need Hyper-V, but it only has to be installed on a commodity server.
The client side
On the client side, the NxTop engine is a quick install from DVD (725 MB ... so close!). After that, you are booted into the NxTop Launcher. From there, you can enter NxTop Connect, which is a very lightweight operating system that contains the Google Chrome browser (with Flash), Skype and a Remote Desktop Protocol client. You can also add Quest vWorkspace and Citrix XenApp clients to the NxTop Connect screen.
From the NxTop Launcher, you can also register with the NxTop Center. Upon doing this, all the desktops that are configured to use are downloaded to the client. It's wise to do this via a LAN for the sake of speed, but it's also possible to download VMs over a WAN connection.
In addition, a user can create his own NxTop VM on the endpoint that is isolated from the corporate desktop to use as a development or personal desktop.
Downloading images and updates is only part of the solution, though, and NxTop can be configured to take backups and upload them to the server at regular intervals. That's where the integration with Quest becomes really cool, since those changes can be available in a more traditional VDI environment when the user isn't using NxTop. Users can also take a manual backup. All of this can be done offline, and the backups will by uploaded when the machine is online again.
SearchVirtualDesktop.com editor Bridget Botelho recently wrote about how Virtual Computer has chosen to support more hardware than Citrix XenClient does by not requiring Intel vPro chipsets. In fact, NxTop runs on Intel and AMD hardware as long as it contains virtualization extensions (either Intel VT or AMD-V). This is a bonus to organizations that don't want to refresh their hardware just to run a client hypervisor. There are tradeoffs, however.
One tradeoff is that all the hardware components in a NxTop VM are virtualized, so there is no direct access to hardware devices such as graphics accelerators. This means that there is no Aero Glass or 3-D acceleration. This is not a big deal for some use cases, but for others, it's something to be aware of.
Still, the user experience on the client side is good if not excellent. If you need only a browser or a remote desktop client, the NxTop Connect interface should be perfect. When running Windows XP, Vista or 7, it "feels" local because it is. Skype, Office and YouTube all behave as you would expect from a locally-installed OS.
My client was running on battery power through most of this test. At one point when playing around with Windows 7, NxTop notified me of a low battery charge, reminding me of one other thing that NxTop does very well: interface with the hardware.
One of the major challenges of client hypervisors that their big-iron cousins don't have to deal with is the breadth of hardware and features that must be supported. XenServer, Hyper-V and ESX don't need to worry about laptop lid closures or batteries running out of power. They don't need to worry about webcams, caps lock, volume controls, scrolling track pads or crazy USB rocket launchers, either. (They all work in my NxTop VM, except for the rocket launcher which, sadly, I don't have). Perhaps this is why we only have three Type 1 client hypervisors rather than the five or six that we were originally tracking in this space.
Virtual Computer hangs its hat on the management and security of its product, and it has no equal in the world of Type 1 client hypervisors. From the NxTop Center management interface, administrators can configure policies such as allowed devices, supported platforms, how often a NxTop should "check in" with the server before being locked out, bandwidth requirements for updates and backups, and VM expiration.
The System Workbench feature allows you to configure exactly which aspects of the virtual desktop the user is allowed to customize based on application whitelists. It also gives administrators the ability to map files and folders to different layers of the virtual desktop -- core OS disk and user data disk, for instance. This gives admins more control over what data can be changed or backed up, as opposed to letting everything to flow in both directions.
The management feature is even more powerful when combined with application virtualization, and NxTop can deploy streamed or packaged applications via Altiris and Xenocode built in. (Xenocode is now Spoon, so ongoing support is up in the air at the moment.) This means that the same policy engine can be used to deploy apps to your users via the NxTop management console.
This is a lot of information, but it barely scratches the technical surface of how NxTop works. The point is that if you're putting projects on hold while you wait for Citrix XenClient to mature, you're missing out on a robust solution that might have everything you need already. Virtual Computer is nothing if not approachable, so grab the evaluation version from its website and put it through a few tests in your environment.
Also, we have a commenting feature here on SearchVirtualDesktop.com now, so if the mood strikes you, let us know what you think about Virtual Computer NxTop and other client-hypervisor technologies.
ABOUT THE AUTHOR:
Gabe Knuth is an independent industry analyst and blogger, known throughout the world as "the other guy" at BrianMadden.com. He has been in the application delivery space for over 12 years and has seen the industry evolve from the one-trick pony of terminal services to the application and desktop virtualization of today. Gabe's focus tends to lean more toward practical, real-world technology in the industry, essentially boiling off the hype and reducing solutions to their usefulness in today's corporate environments.
This was first published in February 2011