Mirage takes an unusual
approach to desktop virtualization that is likely more suited to organizations
that are wedded to their current desktop fleet and yet want to have a centrally
managed virtual desktop environment. Wanova Mirage 3.0, released Nov. 8,
attempts to ease the process by centralizing desktop workloads in the data
center while offloading processing to a user’s device. The Mirage components
create the illusion that the desktop is running as an independent system by
transferring data back and forth.
This latest version of Mirage includes a newly minted file access portal along
with the separation of driver files from the operating system so that images
are hardware-agnostic and feature a raft of configuration improvements.
While Mirage is mainly a virtual desktop infrastructure platform, it also
verges into traditional Windows desktop operating system deployment and
maintenance functions. Operating system deployment on physical endpoints is a
fussy, fragile affair. Mirage simplifies endpoint deployment by stripping
drivers from the Windows operating system base layer and adding in hardware-specific
drivers as needed by the user system. For the most part, user systems are only
imaged when first added to the Mirage system. From then on, incremental
changes, if permitted, are transferred to the data center.
Wanova Mirage 3.0 costs $200 per desktop.
How I Tested
I tested Wanova Mirage in a VMware vSphere 5.0 test environment and also using
a Mirage server provided by Wanova and running as an instance at Amazon Web
Service’s EC2 public cloud. IT managers who want to get up and running quickly
with a proof-of-concept installation might want to ask about the AWS option,
although I found it too constraining for anything more than looking at basic
features since it was hard to integrate into my test domain. Most Mirage
functionality depends on the system being incorporated into Windows Active
Directory structure.
The Mirage product is made up of a Mirage Management Server, a Mirage Server
and Mirage clients, which are installed on the managed end points. The Mirage
system depends on using at least a 64-bit installation of Microsoft SQL Server
2008 R2 Express Edition. Both the Mirage components and the database were
installed on Windows Server 2008 R2 Datacenter virtual machines. The Mirage
Server (not to be confused with the Mirage Management Server) needs to be a
fairly beefy system and at a minimum requires 16GB RAM, 2-quad core processors, and at least 146GB of disk space and
2-Gigabit Ethernet NICs (network interface card). It’s worth noting that the
test system provided by Wanova, which worked fine in my small scale test, did
not meet these minimums. The system I ran in at eWEEK Labs met the minimum specifications.
I used several different machines configured only with the basic Windows XP SP3
OS and Windows 7 SP1 OS as reference systems. I also used a system configured
with an OEM volume license version of Windows XP SP3 to see how well the system
worked with a desktop system fully configured for a standard knowledge worker,
including Microsoft productivity tools and other applications.
Self-Service
This version of Mirage separates the base operating system image from
hardware-specific drivers. While this isn’t a new technique, it was effective
and did help reduce the number of base images that I needed to create. In my
small test environment composed mainly of Lenovo and HP laptops, and HP desktop
and workstation endpoints, I was able to create just one Windows 7 and one
Windows XP base layer, or image.
I downloaded the display, network and other drivers needed for each of my
endpoint devices, including a Lenovo ThinkPad Edge laptop, an HP Z600 and Z800
Workstations and several HP dm2000 desktops. After meticulously creating a
directory structure that keeps the drivers for each hardware model separate, I
imported the driver library into the Mirage Server.
Getting a working collection of operating systems, drivers, applications and
user settings to work on the dizzying array of deployed hardware seen in most
organizations requires an absolutely fussy, detail-oriented approach to imaging
setup. The Mirage 3.0 system enables this type of “Madame Librarian” approach
to organizing, but make no mistake, the Mirage system is as finicky as
competitors when it comes to keeping files in order. IT managers will spend a
fair amount of time creating and configuring CVDs (Centralized Virtual
Desktops).
In addition to creating the CVDs, there are a host of rules and process
settings that must be configured to keep users’ systems up-to-date. Besides
creating the initial base layer (what might be thought of as a type of “golden
image”) I needed to update the base layer and ensure that all driver files were
assigned to the right endpoint systems. And there’s a lot of tweaking that can
be done to include and exclude files from the base layer. Making changes anywhere
in Mirage requires at least some testing on a guinea pig system to ensure that
what users get will work. This is similar to competitive systems.
This version of Mirage allows users read-only, no download access to files when
the user is not on the endpoint device that normally runs the workload. To be
sure, there was a fair amount of configuration needed to make this happen,
including the fact that the user must be able to log in using domain
credentials to access the files. The usefulness of this feature is somewhat
diminished because the file can’t be downloaded.
Changes
New in this version of Mirage is support for Windows endpoint systems that are
using a Windows OEM license. I was able to centralize a Windows XP system that
was using a Windows XP OEM volume license with no problem. I was also able to
deploy a workload and apply a corporate volume license to a device as easily as
any other system in Mirage.
My base layer library changed a fair amount during the two weeks that I tested
Mirage. After the first few attempts, I got a system routine that made it easy
to incorporate the modifications into the base layer. Once the new base layer
of the operating system was in place and tested, it wasn’t a problem to deploy
that to user systems. Although I did not test the branch office “reflector,”
there is a mechanism in Mirage 3.0 to send major changes once to a branch
office and then have local systems pick up the change from the reflector and
thereby avoid taxing slower WAN links.
 |
/ 3 
Virtualization Technology News & Reviews 
