Desktop Virtualization: How do Wanova offer a Mirage?

It has been said before desktop virtualization can be hard. The virtual desktop may have become real, but it is not mainstream. Is this because current virtual desktop deployment models are not mature enough, or the models are flawed?
Desktop management is expensive if it is unmanaged on a LAN: it is most expensive when those unmanaged desktops are distributed (be it across regional offices, or roaming users, or both). Centralisation can reduce these costs, putting you in a position where the IT you manage enables, rather than disables, the business. However, centralisation of desktop services is costly.
Centralisation solutions either focus on solutions that require a large investment in data-centre resources (such as Desktop Virtualization or Presentation Virtualization), or require you to separate management functions and duplicate administrative effort (mix VDI with A.N Other solution).  UniDesk, for example, have looked to re-invent how centralised virtualised desktops are managed; MokaFive and VirtualComputer have enterprise ready options for managing workspace delivery to devices but there is a requirement to deploy and manage a hypervisor on the end device. If your goal is to manage what you have better to reduce your costs – do you have to have hypervisors; do you have to remote your desktop?
Wanova have developed a Distributed Desktop Virtualization (DDV) solution – Mirage – with which they look to solve issues of desktop management with distributed environments, without the need for hypervisors, without the need for expensive data-centre resources and remoting protocols. In this article we’ll take a look at the challenges of desktop delivery, how Mirage works and how can it impact your desktop management.
By definition, a Mirage is a displaced image of distant objects, rather than an hallucination. Can Wanova offer the facility to deliver virtualised desktops to disparate devices – or are they just making it up?

What is a Desktop?
There are a number of different desktop types, each has pros and cons.

• Traditional – your standard PC or laptop. Resources are dedicated to the user and can make full use of the hardware attached. Great for off-line use. Issues with Traditional tend to be around differences in hardware making updates complex, time-to-fix and physically delivering devices can be time consuming – especially in a distributed environment. Traditional devices are susceptible damage,  theft or loss.  Data can be held locally – this is good if you want fast local processing or off-line working, bad if the data is sensitive or updated by many people and time sensitive.
• Hosted in Data Centre (physical):  Blade PCs. Resources are dedicated to the user. Hosting them in the data-centre reduces chance loss (unless its a really big data-centre), improves delivery time of updates and changes. However, they have to be accessed remotely, this can degrade the user experience. Data can be held locally – this is good if you want fast local processing but not for off-line working. That said, given the data is still held “internally”, data can be easily secured.
• Hosted in Data Centre (virtual): Many virtual desktops hosted on a single server or servers – either hosted desktops (each user has access to their own desktop OS instance) or presentation virtualisation (each user has access to a desktop running on a shared server OS). Requires less hardware than Blade-PCs and so can have even faster time for updates and changes to be applied so can be more scalable than Blade PCs – but suffering in the same way that using a remoting protocol this can degrade the user experience. In addition, the shared nature of resources can mean that the user experience may degrade during peak demand. Data can be held locally – but this impacts the scalability of virtual devices and again, is not suitable for off-line working.
• Client-Side Hypervisor: a client-side hypervisor (CsHV) is installed on your standard PC or laptop allowing a centrally managed instance to operate on the end device. Resources are dedicated to the user, with a slight overheard of having to support the hypervisor. Great for off-line use.  Issues are that you either have to remove the existing OS and replace it, or be in a position where the underlying OS is not managed directly: which can be a security and reliability concern. Issues with tend to be around hardware support (i.e. is the device capable of running multiple operating systems), as well as the time to  deliver new images and updates. Data can be held locally – this is good if you want fast local processing and off-line working. Unlike traditional devices, CsHV typically include encryption and backup services – reducing the risk of holding data remotely.

The Desktop Delivery Conundrum Mnemonic
So many delivery types. How do you choose which one is best for your situation? Its a conundrum. To choose,  consider the mnemonic: To Pee Far, Drink I Water.

• Transition: how to transition between “what the user has now, to an improved model”. This is an can be an easy task for those users using a small set of server based applications, but is much more complex for mobile users, users with specific desktop requirements or a great deal of locally stored data and/or unique applications
• Personal Computer. Users have their own computers. Can you, do you, need to harness that local computing power? Do your users need fast and responsive graphics and video? Printing? Access to data off-line? If you need compute resource at the end-point to support your data centre hosted data, how do you manage that end-point?
• Flexibility. Can you separate, do you need to separate “What is Managed by IT”, from “What the User Needs to Do”?
• Your Most Important Asset is Your Data. A goal must be to ensure the security of the data and the recoverability of the data regardless of the deployment type.
• Independence. If your user is tied to a physical device there is a single point of failure. If that device is not available because it is damaged, they lose it, you can’t buy it any more or they aren’t physically able to get to it – that user is unable to work.
• Does the Wheel Need Re-Inventing. Will your solution do away with existing hardware, upgrade it or re-use it? Re-Use is cheapest. If you’ve a replacement type – how much additional hardware do you need because the more you need, the longer your Return on Investment.

Distributed Desktop Virtualization – What Is It?
The question Wanova looked to answer was “Is it possible to utilise desktop virtualization to manage across environments, not only for LAN based users – but for users distributed in remote offices or roaming the road without the ?”
And they found the answer was…Yes.
Mirage is a Distributed Desktop Virtualization (DDV) solution. The DDV model looks to reconcile what is often a conflicting requirement of centralization and user experience. Instead of moving the entire desktop to the data-centre, including the physical compute resources and desktop image, as is the case with server-based Desktop Virtualization solutions; or alternatively keeping the entire desktop at the end-point desktop, as is the case with Traditional  and without a  local hypervisor as with Client-Side Hypervisor solutions.
Wanova suggest DDV offers a third alternative specifically designed to address the needs of distributed organizations. So we gave it a test.
Kicking Tires of Mirage
There are a number of components to Wanova Mirage:

• Mirage Server: Each PC to be managed is migrated to the Mirage Server. This migrated instance becomes the authoritative copy, known as a Centralized Virtual Desktop (CVD). A CVD  is the ‘base’ allowing you to centrally manage, update, patch, back up, troubleshoot, restore, and audit the desktop in the data centre – regardless of whether the endpoint is connected to the network.
• A CVD has three parts – which can become interchangeable:
  1. Base Image: this is defined by the administrator, a BI comprises the operating system image plus the core applications.
  2. User-installed applications and machine state (unique identifier, hostname, any configuration changes to the machine registry, DLLs, and configuration files).
  3. User settings and data. Changes made by the end user to data, application settings, applications, or machine state are transferred to the data-centre. Conversely, all changes made to the data-centre based BI can be transferred to the endpoints. Administrators can identify files that are considered local-only to the endpoint so that they can be excluded – such as user’s personal files.
• Mirage Client: Needs to be installed by an administrator on each endpoint. The client executes in the base operating system, making sure the image at the endpoint and the CVD are fully synchronized. The Mirage Client is not a hypervisor, though execution of the client on Type 1 or Type 2 client side hypervisors is supported.
• Distributed Desktop Optimization (DDO): Optimizes transport of data between the Mirage Server and the Mirage Client – making it feasible to support remote endpoints regardless of network speed or bandwidth. DDO incorporates technologies that include read-write caching, file- and block-level de-duplication, network optimization, and desktop streaming over the WAN.

We took a look at the demo version of Mirage which was v1.5. This version supported virtual machines only, although we did get a limited opportunity to integrate traditional and CsHV based devices into the set-up.

Note that the Mirage server needs to sit on Windows 2008R2 x64: it should have a minimum of 8GB of RAM and have two quad core processors. Disk Storage is important – minimum drive capacity for a production environment is 146GB. There is also a requirement during the installation to have a Microsoft SQL database available for storing configuration information.
Installation of all components – server and agent is straightforward. Management is performed using a Microsoft Management Console snap-in, and the agent is an .msi installation that can be scripted for install, deployed via Active Directory or incorporated into a third-party software distribution service.
Client installation requirements are Windows XP SP2 or above, or Windows 7, with .NET Framework version 3.5 SP1. Unlike CsHV solutions, Mirage’s hardware minimum requirements are simply 512MB of RAM and 5GB of disk.

Mirage supports the concept of roles for uses – by default users can be an Administrator, Desktop Engineer or Helpdesk user – other roles can be added. The processes for migrating a device to become a CVD, capturing Base Images and assigning those to managed devices is straightforward. In fact, perhaps too simple: I was able to install two anti-virus software base images to the same device. The important thing here is, you can standardise images very easily but be aware of what software is currently deployed in order to make the best decisions for deployment and standardisation. Ideally I’d have reviewed the reporting option available in Mirage to help understand what software is deployed on devices. The output is in .csv file format, but it does present a guide as to what is deployed where. Ideally, this report would be available in format you could view more easily in the console – and/or could be used to generate software auditing reports. It should be noted that Wanova recommended that a Base Image is created per hardware family – if you’ve a number of different physical device types (different build model of laptops for instance), you may find you need to create multiple instances of base images.
That said, the logging and journalling is straightforward – with the Dashboard (shown above) providing a useful summary of the status of managed devices.
Restoring image was perhaps too simple: once a CVD is created you can re-build a machine very quickly and easily by reapplying that CVD to a standard Windows installation with the Mirage client installed. If you accidentally restore a device to a new machine you can end up with two duplicate machines on the network. Computers only do what they’re told after all.
Allowing users to restore deleted files was also easy. Once the device had a base CVD file changes that had been saved during a sync could be restored/recovered as needed. The process is very similar from a user perspective to restoring files using a Microsoft’s standard recovery tools for network shares.
A Mirage client can be hosted on a device using disk encryption; although the point to be aware of is that the reference machine creating the Base Images can’t.
We updated a couple of devices from XP to Windows 7 – again a straightforward wizard driven operation. Create the reference instance of Win7, apply the reference instance to a CVD. Go and have a coffee. Come back and its done.
In summary – Mirage is straightforward to use and deploy. A desktop service could readily be up and running in a short period of time – likely giving a fast return on the investment quite simply by allowing you to restore and recover users devices.
A Welcome Mirage?
2010 may have been the year when the software needed to make virtual desktops work became enterprise ready – but are enterprises ready for virtual desktops? For many organisations – especially those with a distributed environment – current existing delivery types fail to consistently deliver.
What does DDV uniquely offer as an alternative to existing desktop delivery types? Wanova’s marketing is focused on laptop deployments – but it is possible to see how Mirage could be deployed to manage desktops, physical and virtual. To consider the mnemonic mentioned – Mirage allows a straightforward transition, utilising the local device. The resulting service can be  flexible to switch between physical or virtual devices giving a level of independence. Perhaps most importantly for many organisation, Mirage does not require a dramatic change in services –  a central storage repository is available for backups, users can still  maintain their own applications if needs be – but still have a base environment managed by IT.
Does it make other solution types irrelevant? No. Remote desktops keep data centralised delivering client server applications more efficiently over wide area networks; it is also possible to change hardware – add memory/cpu more readily. CsHV offer the ability to run multiple instances of OS and allow a separation of operating systems between (for example) the user’s personal OS and their corporate instance.
However, a distinct advantage of  Mirage’s is its simplicity in the first instance. At a base level Mirage gives you the ability to manage a distributed environment allowing saving and restoring of users devices and data: while CsHV can achieve this to an extent, the transition process to enable this function is far more complex. Perhaps the most compelling part is the management of user data and workspace states: however, remember in centralising the data, you’ll need storage to hold that data – planning here is key to ensure to ensure that the capacity of your server environment is correctly scaled and available. As with CsHV, a Mirage service needs less centralised hardware than VDI – but it will need storage capacity to host the captured data, and manage the delivery of the components to the end-points.
Can Wanova offer the facility to deliver virtualised desktops to disparate devices; they most definitely can and their distributed desktop virtualization model should be one you consider in delivering desktop services to your corporate devices.