The NxTop platform uses open-source, bare metal hypervisor technology on desktop and laptop systems to implement virtual Windows-based user systems. The effect of hosting the virtual machine locally enables NxTop users to work untethered to the data center.
While the NxTop platform, which consists of a variety of server and user components, is easy to install, IT managers should anticipate substantial planning time to ensure that NxTop virtual machine policies and workloads are correctly instantiated. In this sense, NxTop shares with other virtual desktop products the special planning burden that individual user customization imposes on machines that are intended to be mass deployed.
NxTop 3.1 will start shipping April 19 and costs $150 per user. The main NxTop Center, a server component that interacts with the Microsoft Windows Server 2008 that is running the Hyper-V role, is included in the user license cost. Additional Remote NxTop servers that may be needed for wide-scale deployment cost $2,000.
Unlike most virtual desktop products, NxTop, made by Virtual Computer, uses a bare metal hypervisor that is installed directly on the user hardware. My tests showed that right away, IT managers will need to assess whether local hard drives have enough disk space, either directly available or that can be made available using disk-partitioning tools, to support the NxTop Engine. All of my test systems needed to be repartitioned to free up the 10GB minimum space needed for the NxTop hypervisor. On new systems, I simply installed the NxTop Engine and allowed it to take over the entire disk.
Parts and Pieces
To enable local desktop execution of the centrally created and managed virtual desktops takes a number of software components. My test implementation consisted of the NxTop Center monitoring and management console that was installed on an HP Z800 workstation that was running Windows Server 2008 R2 Server SP1 with the Hyper-V role enabled. NxTop Center requires at least one Hyper-V-enabled server. VMware vSphere is not supported.
The NxTop Center is designed for use in an open-minded Microsoft shop. The NxTop Center uses a database to track users and machines and requires either Microsoft SQL Express or SQL Server. The NxTop Center needs to be integrated with Active Directory and uses the directory data to provision users and groups. At the same time, the NxTop platform is a heavy user of open-source technology. The platform installs an Apache Tomcat Web server to provide the administrative console and the user-client components use Linux open-source products to provide basic services.
Thus, the NxTop Engine is a Linux-based, bare metal hypervisor. I installed the NxTop Engine on several Dell, HP and Lenovo (and older IBM) laptops as well as an HP dc7700p desktop system. The NxTop Engine hosts the centrally created and managed virtual desktops on the local hardware. The NxTop engine also provides underlying management services such as policy-based check-in with the NxTop Center. The NxTop Engine also provides a basic virtual desktop called the NxTop Connect which included a Google Chrome Web browser, a Skype client and a small assortment of other simple applications. Administrators can use policy to exclude the Connect desktop from being presented to users.
There is a one-time connection process between the Engine and the Center that was a little tricky. Users had to enter user credentials and a server name. Once the registration process was completed, I was pleasantly surprised by the polished user interface, which presented the virtual desktop systems that were published to my account.
How NxTop Works
NxTop provisions centrally created and managed virtual desktops to user systems based on user and group credentials. My test virtual desktops ran Windows XP SP2 and Windows 7 SP1, although NxTop can also deploy Linux-based virtual desktops.
After installing the NxTop Engine on a desktop or laptop system and making a connection to the NxTop Center, the virtual machine and applications appropriate to my user credentials was hosted on my local system. My user experience was nearly identical to using a similar desktop as if it were installed on the local hardware. Using the central policy engine, I mandated that AES 256 full-disk encryption be used for the “local” hard drive, which added a further layer of protection in case the hardware on which the NxTop virtual machine was running was lost or stolen.
Using the policy component of the NxTop Center, I was able to specify how often NxTop systems were backed up, when they expired, when they would be locked out, how often to check for an operating system profile change and what USB use would be permitted. These policies also enabled remote wipe and kill that allowed me to disable NxTops when they reconnected to the NxTop Center. IT managers will need to spend some time mastering these policy settings to control the NxTop desktop life cycle. The policy engine is straightforward and IT managers should have little trouble implementing policy changes that customize NxTop operations.