Home | Storage | Solving the VDI I/O Problem
Solving the VDI I/O Problem

Solving the VDI I/O Problem

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×

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 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 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.

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
  • http://blogs.netapp.com/virtualstorageguy/ Vaughn Stewart

    I agree that if you have traditional storage, you will need to augment it in order to deliver high I/O from a dense storage footprint. An alternative is to deploy a storage array which has dedupe awareness in it’s cache, thus allowing a single in-cache desktop image to serve the I/O for all desktop clones.


    The benefit of this design versus Atlantis, Virsto, or others is this technology works for every dataset on the array from virtual servers, database test & dev, Exchange mailbox servers, etc.


  • http://www.virsto.com Alex Miroshnichenko


    Thank you for quick review of VIrsto in the context of VDI.
    A couple of factual corrections:
    Virsto does not create new LUNs (virtual or any other kind) – we create and manage virtual disks objects which are represented in the Hyper-V storage name space as VHDs which are extremely easy and intuitive to deal with. There are no long GUIDs to worry about even if you don’t use the MMC console.
    On the performance: Virsto started as a server product, we do have extensive body of evidence – both internal and supported by our customers- that Virsto solutions outperforms the standard configuration by a factor 3-4 on the same storage HW.
    Please drop me a line – I’ll be happy to give you all the detail.


    Alex Miroshnichenko
    Virsto CTO/founder

    • http://www.brookend.com Chris Evans


      Thanks for the note. I’ve had the briefing from your marketing team, not sure if you were on the call. So in my installation I have all of the VHDs installed in a directory named “C:ProgramDataVirstoVHDDirVM”, I then have GUID style naming from that point onwards. I agree with you on terminology; perhaps I should have said virtual disk objects rather than LUNs. BTW, my license key only lasted 30 days; any chance of getting a more extended license to do further testing?


  • MrTheV

    Have you tried solutions such as HP’s Image Manager, Citrix Provisioning Server, Double-Take Flex or iSCSI-boot (gPXE + iSCSI initiators)?
    Here, the disk I/Os are “virtualized” to be translated into network I/Os.
    The writes are handled in “write caches” and you can tweak that to be quite efficient (or even, on stateless nodes, you can “write in RAM”).
    HP Image Manager, from my tests, has proven to make VDI more efficient regarding disk I/Os, storage usage (truly one image for multiple nodes. No clones…), VM density…

  • Pingback: Optimized VDI for Small Scale Higher Education Departments « Creator Of Good()

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×