Virtual Desktops with Local Storage, Good Enough for Me

The desktop is a unique beast within the data center. It is something different than what we’ve typically placed within the tightly controlled, highly-available environment. What happened so far is that the desktop has changed to better align with data center practices. That means having high levels of availability and utilizing shared storage. But is this the right approach? Should the desktop align with the data center or should the data center align with the desktop by developing a new service level?

I’ve seen many people apply high-availability requirements to the desktop, which often requires the use of shared storage. Personally, I think this is going too far. I don’t think it is needed, but as soon as I state something like this, I get a lot of pushback.

Let’s walk through the arguments I normally hear:


There is a belief that utilizing local storage will not provide enough performance to accommodate virtual desktops. Organizations have successfully used local storage. I’ve seen lab tests help back this up. The important thing is that you have enough performance (which is no different if you use shared storage). On the local storage side of things, your limiting factor will be how many drive bays you have. With a 8 core, dual processor server (16 total cores), you will need roughly eight 15,000 RPM spindles. It is also a good idea to utilize an array controller that can do caching of the writes to help reduce the peaks.


Once you finally believe that local storage can provide the required performance, the next roadblock is availability. What happens if the server has a catastrophic failure and everything is lost?

Truth be told, a server hosted virtual desktop has better availability than any traditional desktop I’ve ever seen. Think about all of the redundancies we apply to any data center workload:

• RAID: A server will most likely use RAID, allowing me to overcome a failure of a drive. My traditional desktop can’t do this.

• Power: A server will most likely have redundant power supplies. My traditional desktop doesn’t have this.

• Network: A server will most likely have redundant network connections. My traditional desktop has one.

• Monitoring: A server will most likely be constantly monitored by a team of admins. My traditional desktop is ignored.

Already, my server hosted virtual desktop will have better availability than my traditional desktop and I haven’t even made a requirement for shared storage.

Even with all of these redundancies at the local server level, what happens if the server still has a catastrophic failure and I’m using local storage?

• If I have a shared desktop (XenApp), and it fails, I simply start a new session. The impact is pretty minimal.

• If I have a pooled desktop and it fails, I simply start a new session. The impact is pretty minimal.

• If I have a personal desktop (Personal vDisk or dedicated desktop) and it fails. The user gets a fresh desktop with the standard, corporate image including the standard application set. The user completes the process by personalizing it as necessary. This isn’t as bad as it sounds. Think about what goes into personalization

○ Data: The user’s data should be stored somewhere besides locally (ShareFile or network share is optimal).

○ User Settings: Desktop and application settings are still part of the profile, which should be on a network share and configured as a roaming profile.

○ User Applications: If we are using local storage for the virtual desktop, then our user applications have been lost.

Is losing user applications a reason that would require us to use shared storage? I don’t think so.

Remember, by their very nature, user installed apps are not supported/managed/maintained by IT, they are user-managed. User apps are the user’s responsibility. It is the user’s responsibility to install the apps if they need them. It is the user’s responsibility to fix the apps if they break. The nature of user apps is that it is all up to the user.

This is the point many people forget to consider when debating about local vs. shared storage.


Your hardware platform will dictate whether you can even approach local storage. If you go with blades, local storage is not going to happen due to the limitations on drive bays.

What if you have 2000 or fewer users? Too many times, we focus squarely on the enterprise environments (10,000+ users) and ignore the small-to-medium business. So I ask you, does it make sense to go with blade servers with SMB? Will you even fill up a single chassis?

You will more than likely run rack-mounted servers where you will be able to fit at least 8 drive spindles within each server.


Remember, we are dealing with a desktop. In the traditional desktop model where we each have a physical PC sitting at our desk, what is the SLA to get that PC repaired if it fails? How long will it take to get a loaner device? What will be included within the loaner? I can guarantee you it will not include your user apps, and chances are it will be some outdated piece of hardware that no one wants.

Simply moving towards a server hosted model, even on local storage, will still have a better SLA than traditional desktop. I can simply access a fresh virtual desktop and start working. This is much faster than the traditional model.


I ask you, is local storage such a bad thing for virtual desktops within the data center?

Daniel – Lead Architect

6 thoughts on “Virtual Desktops with Local Storage, Good Enough for Me”

  1. Hi Daniel

    Couldn’t agree more – the only really issue I have against this is taking personalised desktops offline to perform hardware maintenance / patch the hypervisor – it sort of means that all has to be undertaken out of hours which is a bit of a bind, or do you have a solution for that ?



    1. I believe all hypervisors now support live migration to another physical server even if you use local storage. It will take a little longer than if using shared storage, but it is still possible, which should alleviate the maintenance concern.


      1. Thanks Daniel

        So live storage migration. I see what you are saying but for a large scale deployment with fortnightly security patches, it seems a bit much (I.e. If you are using hyper-v) – I guess if you have a small number of assigned machines then it really isn’t an issue (or shouldn’t be)

        Thanks for coming back to me



  2. Obviously, local storage is a no brainer for non-persistent desktops, for persistent it’s a different case when you talk to customers, the conversation revolves around the failure domain, losing one desktop is fine, losing 200? Not so good.


    1. Why does 1 desktop mean nothing but 200 means the world? If a customer is worried about losing 200 desktops, then why aren’t they worried about losing 1? What is the failure rate between a server versus a traditional desktop? My desktop gets kicked, knocked over and is used as a shelf for coffee cups. Servers have RAID, redundant power, redundant network, and no drinks are allowed in the data center.

      If an organizations wants to use shared storage, then feel free, but I think it is overkill for desktops. Even with the risk of losing a entire physical server. It is all based on how you define your SLAs with the user. A persistent and non-persistent desktop are identical from IT’s perspective. IT is required to provide the base operating environment (OS and corporate apps). I don’t think IT is required to support the user-apps. So if an entire server fails, the user experience is similar, you get assigned a new desktop.

      You settings and data should persist, assuming you defined your data and profile settings correctly, but the physical changes you make to that desktop will be lost.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.