Virtualize My Desktop

I’ve had another discussion with people passionate about memory overcommitting for virtual desktops. My stance is it can be dangerous if you take it too far. Unfortunately, many reports I see talking about the value of memory overcommit take it too far. So where is just far enough? Let’s go through an example (I’ve generalized this as I don’t want to talk about each different hypervisor)…

Let’s say you need 100 servers (192GB RAM) to host virtual desktops for 7500 users. Those 100 servers will reach maximum capacity (CPU and Memory) when they host 75 virtual desktops VMs (2.5GB RAM). For fault tolerance, you go with the N+10% formula where you will have 10% more servers than you need. That means you really have 110 servers.

As I spread the load across 110 servers, my server concurrency drops from 75 users per server to 68. That also lowers my RAM usage from 187GB to 170GB. I paid for the RAM, so I want to use the RAM.

In this example, being conservative, I will configure the upper memory threshold for the desktops to 2.8GB RAM each and the lower to be 2.5GB (which is what I determined these users must have).

Based on the example, during normal production mode, my desktops are not overcommitting RAM. However, during an outage (planned or unplanned), my servers will be required to host additional desktop VMs. As no RAM is free, the desktop VMs are overcommitting, although spread across the entire server and the entire environment, the impact is small and likely to go unnoticed. Additionally, the overcommitting only occurs during an outage. So day-to-day operations continue to run smoothly and provide a good user experience (at least from a RAM perspective).

What have you used on your deployments?

Daniel

XD Design Handbook

Had a brief discussion on twitter the other day where people (@simoncrosby, @joeshonk, @RichCrusco) were saying that we only need to focus on delivering applications and NOT a Windows 7 desktop. I completely disagree. In fact, we should be treating the desktop interface as an application. Of course the desktop-haters immediately came out saying “No, the desktop is not an application.” This was pretty much what I expected.

Unfortunately, trying to explain my point in 140 characters wouldn’t do it justice but a blog is a start.

The key point is that we need to focus on the users. When you look at how users work with these systems, you understand what they need in order to work effectively. We look at the applications as a way to get to the data. We decide if the user needs access to the application, and it is either granted or denied. If we ignored the desktop interface, things would be much easier. I already have a desktop interface, so why do I need another. My local desktop interface has my own applications, so simply let me subscribe to virtual applications. This would alleviate the user-installed application challenge. If you only focus on the applications, you are missing an important aspect because this model doesn’t work for everyone. Let me give you some examples for and against having the desktop interface delivered:

• iPad: I don’t want to use the Windows desktop interface on my iPad as it doesn’t feel natural (Windows 8 might change this, but will wait before deciding). On the iPad, I just want to get to one or two of my applications. So in this case, I want to ignore the desktop interface.
• Work-shifting: I work remotely on my company-owned laptop (Windows 7). If IT only gave me applications, things would feel unnatural. They could populate my start menu with my apps, but it wouldn’t feel right. I would need 2 Windows Explorers (one on my personal desktop and one for my virtualized environment). I would need two browsers (one for my personal and one for my virtual). Which one do I use? I’m not on the internal network, so I need to make sure I use the right one. Not user friendly and very unnatural. In this case, the Windows desktop is a requirement as it makes the user experience better.
• BYO: A user brings their device and uses it at work. From a technical perspective, delivering virtualized applications would work fine. Unfortunately, we aren’t looking at the user perspective. A user will not want corporate applications on there. They don’t want those applications to consume hard drive space, nor do they want it polluting their start menu. Virtualizing the applications could overcome these issues, but the user’s perception is that the applications are local. Even training the users about application virtualization would not be enough as many users believe big brother is still watching. Plus, there will be confusion of having the corporate web browser and your local web browser (I hope you are using the right one, or you might get into trouble). Users in a BYO program want to use their own device, but still be given a “Corporate” environment to work on.
• Local Corporate Device: You have a physical desktop (running Windows 7) located on the corporate WAN, so why do I want to deliver another desktop interface on the one I already have? You probably don’t, so simply deliver applications.

We love to talk about being able to do all of these cool things with virtualization and what the future will hold, but people tend to ignore the typical user and their perspective. This perspective and the comfort of using the system are what makes things succeed or fail. If the solution doesn’t feel natural, it won’t work. And I say that only focusing on applications and ignoring the desktop interface, you are ignoring the user and only thinking about some pie in the sky utopia.

If we treat the desktop interface (XP, Windows 7, RDS) as an application, you must assess the need for the interface using the same criteria you use for applications (end point device, user usage requirements, location, etc). If you treat the desktop as a desktop, you will surely go down the road believing the desktop interface is irrelevant only to find that users are unhappy with the application virtualization solution, thus killing user acceptance.

Not everyone requires a corporate-delivered desktop interface, but many do and we cannot ignore this need.

Daniel – Lead Architect
XenDesktop Design Handbook

When starting to transform a desktop, many people get stuck at one of the first decisions: What type of virtual desktop should I implement? (VDI, RDS, Local VM, etc) There are so many options for so many use cases that we are stuck analyzing our users until we confuse ourselves even more. The problem is we are trying to start by dealing with all of these exceptions. We let all of these unique use cases confuse and stall our efforts. This is why when doing desktop transformation; you need to start with the easiest use cases first. This isn’t because we can’t do the difficult use cases; it is that as the project team, you need to show progress. And the easiest use cases will allow you to show success quickly.

Honestly, when looking at the easiest use cases, it is a pretty safe bet to go with a shared desktop model (RDS/XenApp). Although many don’t talk about the shared desktop model much because everyone is so focused on VDI, it is an approach that is tried and tested. In fact, I remember working with an organization in 1998 that was doing desktops on the predecessor of RDS/XenApp, which was called Windows NT 4.0 Terminal Services Edition with MetaFrame 1.0. And guess what… It worked

Of course you can find loads of information talking about how the shared desktop model is more scalable than the personal desktop (VDI) model, but one aspect that is always missing is Comfort.

Oh my, one of these “marketing” words right? Yes, but here is what I mean.

If I do a personal desktop (VDI), I will get a Windows 7 desktop with applications and it will work. If I do a shared desktop (RDS/XenApp published desktop), I will get a “Windows 7″ desktop with applications and it will work. However, I also get something else. I can also access the applications seamlessly, where the desktop interface is hidden from the users view (some people call this a published application or seamless apps)

Many of you old-time XenApp users are thinking, big deal. We’ve done this for ages. Correct, we have, but now we have people trying to access the desktops/applications from tablets and phones. On my iPad or Android phone, I first had access to my Personal desktop (VDI). It worked, but it wasn’t comfortable and I’ve heard people say it was unnatural. I tend to agree. It was too hard to launch apps. If I’m trying to launch an app from the iPad, why do I want to first go to the Windows 7 desktop? Ummm, I don’t. I just want to launch an application. If I start with the shared desktop (RDS/XenApp), I get to choose between a full desktop and a single application, whereas the personal desktop (vdi) requires me to use the full desktop.

When starting desktop transformation, start with the shared desktop (RDS/XenApp). Work through the user groups that can work in a shared desktop environment. Once those groups are complete, we move onto the exceptions, which are probably fewer than you think. Stay tuned for more

Daniel – Lead Architect
XenDesktop Design Handbook