Solving the VDI I/O Problem

In my post on last year’s HP tech day (Enterprise Computing HP Blades Tech Day) I raised my skepticism on the ROI of desktop virtualisation or VDI (Virtual Desktop Infrastructure) solutions.  One of the reasons for my concern was the excessive costs for deploying the storage needed to support I/O to hundreds or thousands of virtual desktops.  The issues aren’t new; I/O is a particular problem due its unpredictability.  Bootstorms first thing in the morning as workers start up their desktops are a known particular problem, for example.  Solutions focus around increasing the IOPS count of the storage component of a solution, perhaps with additional spindles, distributing I/O across more disks or using SSDs.  This all translates into cost.  Recently however I’ve seen two solutions that aim to fix the problem of I/O demand through the use of software and/or dedicated appliances.

Virsto

Virsto Overview

Virsto provide a software-only solution that works with Microsoft’s Hyper-V platform.  There are two versions available today; VSI for virtual servers and VDI for virtual desktop infrastructures.  The software works to address the issue all virtual solutions (and VDI in particular) have, that is the random nature of I/O.  Random I/O, especially random writes are more difficult to optimise as the storage array can’t efficiently use caching to minimise head movement on physical disks as well as they can with sequential writes.  The Virsto solution works by creating a virtual VHD object for the virtual machines.  As random writes are received, they are written sequentially to a log file in a similar fashion to a relational database.  The updates are then destaged asynchronously to the main logical copy of the VHD at a later stage.  Many virtual VHDs can be created from a single Virsto data and log LUN pair, making the solution ideal to deploy in a virtual environment.

Virsto seems like a simple but elegant answer to the issue of random I/O across many virtual guests.  Of course there’s no such thing as the proverbial free lunch and so there are considerations to make with this product.  Firstly, LUNs are created in the Virsto space using long GUIDs as identifiers.  The Virsto API is then used to manage these LUNs with more reasonable identifiers.  However drop to the standard Hyper-V dashboard and you’re back to meaningless GUID VHD names.  Next there’s the question of performance.  In a large environment, how will the Virsto driver handle workload prioritisation?  For example, I want to ensure my main Hyper-V guests are delivered the highest priority, but now all of my I/O is going through an additional layer on the hypervisor host.

Virsto is on test in the TSA Lab and I hope to have some feedback and more detail in a few weeks.

Atlantis

Atlantis Computing

The second solution comes from a company called Atlantis Computing.  Their ILIO (Inline Image Optimisation) product sits as a software virtual appliance between the VDI storage and the hypervisor.  The software takes advantage of the type of I/O performed by the Windows desktop, where much of the traffic is reading of common operating system files.  These don’t need to be served out of individual guest disk images but are managed by the ILIO virtual appliance directly, resulting in a significant reduction in I/O to the underlying disk storage.  Instead the appliance acts as a cache within the hypervisor.  Of course the immediate question here is data integrity and that could be a problem.  However if stateless desktops are deployed and the data for those desktops is stored elsewhere, then there’s no reason the solution should have data issues.  In fact, one of the benefits of using ILIO is that it can be deployed with local DAS disk rather than using SAN storage.  If the server crashes or the disk fails, then the guests can be restarted on another server.  This may be inconvenient for those users at the time, but in reality disk failures aren’t that common and in any case the stateless nature means no data should be lost.  Using ILIO addresses two of the issues with VDI – I/O performance and cost.  Using DAS for VDI is a much more compelling solution.  I’m hoping to get ILIO into the Lab too and give it a spin.

Either of these two startups could be acquired by Microsoft or VMware and be easily integrated into the base product.  As usual the boundary between storage and virtualisation continues to be blurred.