More and more this novel idea of user classifications and workload profiles is being used to separate VDI user allocations. I've worked with many customers who prefer to stack rank their users based on the importance of their role/job function and the typical applications that user needs in their role as a means to (hopefully) gain a more appropriate VDI resource allocation. Again -this is a great idea and a good excuse for organizations to take a long hard look at their users and the applications they use day to day.

In case you are finding this blog for the first time, we have been attempting to defy blog physics and host a series of blogs -this requires the use of a manually updated table of contents:

1. Introduction -VDI -The Questions you didn't ask (but really should)
2. VDI "The Missing Questions"#1: Core Count vs. Core Speed
3. VDI "The Missing Questions"#2: Core Speed Scaling (Burst)
4. VDI "The Missing Questions"#3: Realistic Virtual Desktop Limits
5. VDI "The Missing Questions"#4: How much SPECint is enough
6. VDI "The Missing Questions"#5: How does 1vCPU scale compared to 2vCPU's? (you are here!)
7. VDI "The Missing Questions"#6: What do you really gain from a 2vCPU virtual desktop? 
8. VDI "The Missing Questions"#7:  How memory bus speed affects scale
9. VDI "The Missing Questions"#8: How does memory density affect VDI scalability?
10. VDI "The Missing Questions"#9: How many storage IOPs?

You are Invited! If you've been enjoying our blog series, please join us for a free webinar discussing the VDI Missing Questions, with Tony, Doron, Shawn and Jason!  Access the webinar here!

Most of the time the three main items separating user classes are:

1. vCPU quantity
2. Memory allocation
3. Disk space

The first sort of pitfall that I see occasionally is too much granularity in the workload profiles. Don't get me wrong, if you have a good view into your users and applications that you see the need to support and manage 5 different user classifications -that's great news! But most of the time it comes down to 3 particular types of user classifications:

1. Gold (Multiple vCPU's, a lot more RAM and disk space than other folks)
2. Silver (Could be a couple of vCPU's, usually more RAM than the OS calls for, can be required for specialized apps, etc)
3. Bronze (These are almost always single vCPU and minimum amount of RAM profiles)

A good sort of buildup approach to start determining your workload profile requirements must take into consideration the users and compute requirements based on the apps those users will be running. In most cases, the Operating System you choose will be the foundation to start your buildup approach. The aging Windows XP platform is quickly being consumed by Windows 7 in the corporate workspace. There are few folks out there continuing to stand up net new systems for users and using Windows XP. This is for a number of reasons -most new PC's and their manufacturers (not to mention this little company called Microsoft) are not developing drivers and supporting the workhorse XP operating system. Let's be honest, Windows XP came out in 2001. Windows XP is older than my twin girls that are in 4^thgrade! It was a good ride, but it must come to an end. You probably noticed that I haven't mentioned Windows 8 yet. After all, it is the newest desktop Operating System (OS) that Microsoft has out. There are a couple of reasons for this: Most corporate users don't jump onto the latest OS because they have to support many users, must test/qualify their applications on a new operating system and as we all know -anything new usually has fixes and enhancements to follow. Plus, as a general rule of thumb, the first Service Pack must come out before anyone will give real consideration to mass deployment in any organization. Beyond the general newness of the Windows 8 OS, it will be interesting to see how "Corporate America" will integrate the new look and feel of Windows 8. With that being said, we have Windows 7 which came out in 2009 and already has Service Pack 1 with a host of subsequent updates. This is the OS that most folks are planning their VDI environments for. Per Microsoft, the requirements for Windows 7 are as follows:

• 1 gigahertz (GHz) or faster 32-bit (x86) or 64-bit (x64) processor
• 1 gigabyte (GB) RAM (32-bit) or 2 GB RAM (64-bit)
• 16 GB available hard disk space (32-bit) or 20 GB (64-bit)
• DirectX 9 graphics device with WDDM 1.0 or higher driver

You've heard about minimum system requirements right?They are minimums! Try playing your latest favorite video game on the "minimum system requirements" listed on the back of the package -not very fun or functional is it? Most of the folks I talk to are split on 32 v. 64 bit, but most of the time I see users being deployed with either 1.5GB to 4GB of RAM and 1 to 2vCPU's. For the purposes of our testing and somewhat inline with the Gold/Silver/Bronze user space, we have a hybrid scenario of sorts. Hybrid meaning we have a "Bronz'ish Silver" user that has 1vCPU and 1.5GB of RAM running Windows 7 32 bit. We also have a "Silver'ish Gold" user that has 2vCPU's and 1.5GB of RAM. The hybrid users are more or less irrelevant from a memory standpoint as the primary purpose of answering this question is to measure the impact of 1vCPU vs. 2 vCPU allocations on the same Login VSI workload. If you missed the Introduction to this series, you should take a look for the full Configuration Settings that we used.

Data time!Let's start by looking at the E5-2643 Processor and see how it scales between the different vCPU configurations.

With 1vCPU, the E5-2643 system scaled to 81 virtual desktops before exceeding the VSImax. The same system only scaled to 54 virtual desktops when configured with two vCPUs (a 33% decrease in scale). There was little improvement to end-user latency by adding a second vCPU to the user's virtual desktop, even at a low number of virtual desktops.  You can see this as the red and blue lines are pretty much following the same ramp up in terms of user count and latency.

Now look at the impact to the E5-2665 system. With 1vCPU, the E5-2665 system scaled to 130 virtual desktops before exceeding the VSImax. The same system only scaled to 93 virtual desktops when configured with two vCPUs (a 40% decrease in scale).

Unlike the E5-2643 system, the E5-2665 system showed a slight improvement in virtual desktop latency by utilizing two vCPUs. The slight improvement was realized below 45 total virtual desktops -but more to come on this in a later question.

Answer:Be careful what you ask for if you want 2vCPU desktops... If you find yourself in a "well, I would prefer to have 2vCPU's..." situation and there is no real application or resource level need, your dollar will stretch a lot farther if you stick with a single CPU.

Just a quick example -if you were going to deploy 1,000 Virtual Desktops on the B200 M3/E5-2665 system we looked at. A single vCPU deployment would require 8 blades without redundancy. If you needed/wanted to use 2vCPU's on each VM, you would need 11 servers without redundancy. 3 more servers doesn't sound like much, but it is a 37.5% increase in the compute infrastructure needed!

In addition, the purpose of using multiple vCPU's is to reduce user latency and application response times right? Well, take a close look at the ~45 user mark on the E5-2665 graph above? Notice anything?

What's next?Come back next week as Jason explores this latency/multi-vCPU situation in more depth when he answers -"What do you really gain from a 2vCPU virtual desktop?".