eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.