View Sizing - Include HT or not?

[Braumin]

Good day all,

We are looking at doing a pilot of VMware View 5.  Reading the VMware website, they seem to recommend 8-10 desktops per CPU core.  Should I include HT as a core or no?

I am limited to which vendors I can buy from, and have to choose a basic configuration for a server (I can not pick my CPU).  It is all based on a standing offer so it is not very flexible.

The reason I ask is that I can get the HP DL580 G7, which comes with four x 1.86GHz Six Core Xeon E7530, which has Hyperthreading.  My other choice is a HP DL585 G7, which comes with four x 12 core AMD Opteron 6174.

The benchmarks seem to favor the Intel chip, but it has only half the cores of the AMD one.  Does that matter or can I include the HT as another core?

Any advice is appreciated!

[weinstein5]

You should be able to consider HT as a core - since both are seen as Logical CPUs by the ESXi host -

[dbrinkmann99 · Accepted solution]

I don't care what the vExpert before me is saying, if you are hoping for 8-10 desktops per core don't count logical processors, count only physical ones.  Best thing you can do for yourself is to pilot a sample of the environment and use assessment tools like those from Lakeside, Lanamark, or LWL to determine load, app demands, etc.  Take it from someone who actually does this for a living...if you count logical processors and think you're going to hit 8-10 desktops per logical core you better be running DOS desktops.  CPU load is not the barrier here...CPU wait times will be your limiting factor.

[sketchy00]

Great point dbrinkmann99.  HT, while generally a good thing, can do more harm when attempting to factor in (often times incorrectly) in these types of estimates.  In the immortal words of Michael Scott, it's "incalculacable" 

[dbrinkmann99]

hyperthreading is like 2 lines per checkout lane at the grocery stores, gets people lined up and ready, but in the end there's only 1 person doing the work.  From my experience View sizing based on vCpu's per core is based on physical, not logical cores.  Hyperthreading usually helps, but it's far from 2x.

Everyone's usage is different, I can't emphasize enough how important it is to use a tool to measure workload (as mentioned above) and to pilot it in your environment.

[rvversendaal]

I would have to agree with dbrinkmann99. As far as i can remember from my vcp courses, the cpu scheduler eventually needs to allocate the work to a physical core. A quad core vm is being allocated with all it's 4 cores to the physical cpu, also with light work. If your host is running on only 4 physical cores, you can get some nasty cpu ready time as soon as other vm's start to get busy because they can't get cpu time while the 4 core vm is being scheduled.

And thats also what i see on some of my esx hosts with 8 physical cores and 30 vm's. As soon as the quad core vm's start to get busy, cpu ready time gets over 10%. In my future environment i would not save money on cpu cores.

[sketchy00]

Hey rvversendaal,

I'd love to see some of your CPU ready times for those 4 core VM's running on your 8 core hosts.  I do the same thing for many of our VM's that are dedicated for software code compiling.  I'm just curious to hear your range, and at what thresholds you start to observe issues.

Sorry OP for digressing slightly off topic.  rvversendaal, you can pm me if you'd like.

[Braumin]

Thanks for all of the feedback!

We are doing a pilot, but just trying to size out our hardware.

So it sure seems like the 12 core AMD chips would be the better option if physical cores are king in the Desktop VM world.  They are the same price per server as the 6 core + HT Intel chips.

How do I measure the CPU wait time?  I don't see that as one of the options on the performance page.

[mittim12]

The CPU wait times references will be measured by the % Ready time counter.    Typically anything in double digits is a sign of CPU contention and that VM's are waiting to be scheduled for processor.

Also keep in mind memory.  If you do 12 cores at 10 per core than thats 120 desktops which would equate to around 240 GB of memory required for something like Windows 7.   Maybe a little less if you take into account a small number of memory sharing.   Also are you going to run HA on these boxes?   If you lose one box your looking at a large number of desktops restarting on other host in the cluster which could saturate your storage. 

[Braumin]

We were going to try the 8 VMs per core, since it seemed a bit more conservative.  Also we always factor in headroom to allow for a failover scenario.  It might not be HA but just a maintenance issue too.  I was going to calculate it as (VMs/8 VMs per core/Cores per CPU/CPUs per server) + 1 server.

For the very reasons you stated (if we lost a server) I would rather go with the DL380 G7 servers, but we can only get those with dual quad cores so the density would not be very high.  That is why I was looking at the larger servers since they can come with 6 and 12 core CPUs (remember I am stuck to what is on our contract offering).

We are going to go with SSD storage on our SAN for the boot disks.  Hopefully that will help.

Our pilot is going to be about 100 desktops, and then scaling up to 1000-1500 in the near term.  Not sure if it will be OK over the WAN (I am guessing not OK) so we would likely end at the 1500 mark since our remote offices don't have the bandwidth required.

Any other suggestions?  This posting has brought me more real world info that anything I have found on the internet.

[mittim12]

Always try to use PCOIP as your default protocol.   Since user experience is key in a VDI rollout you always want your best foot forward.   Also what kind of pools are you looking at?  If you are going to try to utilize floating pools than make sure your performance is there with the profile management.    Again user experience is key and a few unhappy users can easily stall your project.   

[Braumin]

PCoIP is what I am hoping to use.  I have a Wyse P20 thin client for some testing, and we can get those on our standing contract.

As for pools, We are planning on using an automated pool of dedicated Linked Clones, with the user data redirected to a persistent disk.  I agree that user experience is the key, and if users desktops get wiped out ever time the log out, this pilot will go down in flames.

The storage will be SSDs in the SAN for the Replicas (not going to use local storage) and the user disk will be on the SAN in 15k disks.  Hopefully that will give us the storage performance we want.

[sketchy00]

Nice to hear you are addressing the storage side, which affects the user experience as much as anything.  IOPS IOPS IOPS baby...

[dbrinkmann99]

Take a look at this article, goes against the general thought on where you need SSD drives.  For profile management I would suggest looking at the persona management in View 5 or looking at a 3rd party like AppSense or RES.

However you mentioned you are looking at using dedicated pools?  Why even concern yourself with profile management if you're going to do dedicated pools?  If you need users to install their own apps I understand that model...anything else though try to go with floating assignment.  As for the failure scenario... if you are using a floating pool set the HA policy not to start the VM's elsewhere... you don't need it.  The VM's are already running on your +1 host and user data will follow with persona and redirected folders.  I think you're misunderstanding the difference between persona and user data disks... it's accomplishing the same thing and is typically done for non-persistent VM's.

http://myvirtualcloud.net/?p=2513

I would suggest getting a VMware partner or VMware involved to help you through all this.

[Braumin]

I had not heard of the Persona Management and will look into it.  We had looked at AppSense but it is way too much money for what it gives (at least in our case).

I have not looked at View since version 4 came out, so obviously I have some reading to do.  Persona Managment looks amazing for VDI.

I'd rather not get a 3rd party involved if possible.  We are pretty comfortable with VMware products so I think we can work through it.

[gunnarb]

I dont want to come off rude but View design is MUCH more complicated than the way this thread is going.  Honestly it sounds like you are sizing an envirnment by guessing on how many VMs you can get per core, and maybe put things on SSD because you are aware IOPS are a major issue. 

Someone earlier recommmended the right thing.  get the right tools and capacity plan your environment.  id hifhly recommend you get a consultant at least to do the design.  you can do the implementantion.  but i do view design and implementations wrrk after week and most of thrm are redsigns because the team came froma vSphere background and thought they could do View with the same mind set.  EUC and VDI are diffrrent animals.  I specialize is EUC because its complicated and fun and honestly i just want all pilots to succeed. view is a great product but you have to design it right.

sorry for the typeos im on my phone here