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.