6 Replies Latest reply on Sep 30, 2010 8:53 PM by lanamarkinc

    Capacity Planner question

    kennyfranklin Enthusiast

       

      I had some interesting results on an analysis I'm currently working on.  For some reason, the tool has looked at all of the physical servers in the environment and has deemed they are all good candidates for virtualization.  It has recommended a 3 host infrastructure for 15 physical servers.  The odd thing is in the Detailed Placement Results (where the tool models and predicts how individual VMs will be placed on physical hosts), it has placed 13 servers on one host and has placed each of two VMs on their own physical hosts.  I'm having a hard time seeing why it might have done this.  Neither physical server has a tremendous amount of IOPS, CPU utilization, or memory usage.  Both of the physical servers which were placed on their own hosts in the virtualization scenarios had a fair amount of memory (24GB and 64GB) and more processor cores (8 and 4) than most of the other physical boxes;  though there were at least two other physical servers which had 4 cores and 16GB of RAM which were lumped together on one ESX host with 11 other VMs.

       

       

      I'm thinking it has something to do with the memory numbers, but the odd thing is it didn't seem to matter what sort of host I used in different scenarios... using hosts with 64GB of physical RAM and 8 cores yielded the same placement results as did hosts with 262GB of RAM and 16 cores.  Still 3 hosts with exactly the same VM placement.

       

       

      Does anyone have any explanation for why this might be?

       

       

      Thanks ,

       

       

      Kenny

       

       

        • 1. Re: Capacity Planner question
          chadwickking Expert

          Hi Kenny,

          I will do my best to provide with reasonable information.  Capacity Planner is a tool that gives you the best number for the Data it sees.  If you have large sized servers i.e. like 16 cores then it would make since having that server on a seperate host due to the amount of vCpu it may need to have and memory. If you have many single/dual Cpus systems it would make since from a performance perspective to have them on a seperate host because of the way ESX scedules HEC's.  Each vCpu will need to schedule a HEC and each physical core can schedule a HEC.  So if you have a Vm with 8 vCPU then it will need to schedule all 8 HECs at once vs. just one HEC for a 1 vCPU. If you dont have a Physical Core availble to schedule a HEC (because other vCpus maybe be taking them) then you will run into a "ready state" and will take a performance hit.

           

          Ultimately when going from a physical to virtual environement it is best practice to only allocate one vCpu anyways.  Doing this will in some cases increase performance because some servers only use 10% of their CPU anyways.  Only if an application will benefit from SMP should be when you add more than one vCpu.  Also, You should ALWAYS performance test the VM yourself to just see how it performs before taking into live production.

           

          Here is a great blog on understanding SMP when vCPU counts:

          http://blogs.vmware.com/performance/2008/06/esx-scheduler-s.html

           

          http://www.vmware.com/files/pdf/techpaper/VMW_vSphere41_cpu_schedule_ESX.pdf

           

          You have to first understand alot of "how" vSphere Hypervisors work to really know why it makes its recommendations.  Also it may plan that the capactive growth for those physical servers are more in regards to the others so they may need additional resources.  The best thing to do is to always take the recommendations and simply develop a procedure of testing them. 

           

          I hope this helps.

           






          Cheers,

          Chad King

          VCP-410 | Server+

           

          Twitter: http://twitter.com/cwjking

           

          If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

          1 person found this helpful
          • 2. Re: Capacity Planner question
            kennyfranklin Enthusiast

            Thanks for the response and the explanation makes a lot of sense.  I have read many times the wisdom of only allocating one vCPU per VM except in rare instances.  My understanding is one should generally not add more than a couple vCPUs per VM as this can actually adversely affect performance.  Have you (or anyone) run across a situation where you actually benefit from adding say 4 or 8 vCPU's to a VM?  I'm thinking needing this many vCPU's makes the server not such a great candidate for virtualization unless perhaps you have hosts with dozens of available processor cores.

             

            Thanks,

             

            Kenny

            • 3. Re: Capacity Planner question
              chadwickking Expert

              I will be straight with you - In some cases we have allocated 4vCPU based on the application types/loads.  For example Java web based farms benefit alot from having SMP and SQL Server as well.  You just have to understand your VM to host capacity and understand your tradeoffs. We do a tremendous amout of performance tweaking and monitoring as well as benchmarks.  But we also watch CPU Ready state (the problem of cpu contention due to over scheduling) by using the ESXtop or RESXTOP command for esx(i).  The host itself gives you the real numbers - if your hardcore do it all from there.

               

              Also if you run high CPU you can only us the max Ghz of 1 core. so if you have a six core 2.7 ghz cpu you can only run 1 vcpu at a max of 2.7 ghz.  so if you run into high CPU performance problems - add a vCpu and you can get more GHZ  - one scenario.

               

              hope this helps!

               

               

              Cheers,

              Chad King

              VCP-410 | Server+

               

              Twitter: http://twitter.com/cwjking

               

              If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

              • 4. Re: Capacity Planner question
                amvmware Expert

                I would recheck the scenario - i have seen this before and it is generally due to the specifications of the chosen hardware is insufficient or one of the default paramaters in the scenario modelling is set too low.

                 

                If you select the detailed output option you should see why the scernario modelling determined that it needed 3 hosts for 15 VM's - ie what configuration paramater has been exceeded.

                • 5. Re: Capacity Planner question
                  kennyfranklin Enthusiast

                  The feedback is much appreciated.  Yeah, I kind of figured something like this might be going on.  I played around with the scenario... throwing more processors and memory at it, but have not yet been able to zero in on the parameter which seems to be causing the behavior.  The two servers in question don't seem to have any stats which are way out of whack.  The only two parameters these servers appear to have in common which are slightly higher than the other servers are their Processor % Used stats... one is at 8.3% (for the 8 core machine) the other is at 22.65% (for the 4 core machine).  All other servers are at 7% or below.

                   

                  Will keep looking until I find it.

                   

                  Again, many thanks,

                   

                  Kenny

                  • 6. Re: Capacity Planner question
                    lanamarkinc Enthusiast

                    Kenny, if you are interested in more comprehensive server virtualization planning analytics, have a look at the Lanamark Suite Services Edition. It performs workload normalization between source and target CPU architectures and it uses multiple metrics (CPU, memory, IO, etc...) concurrently to come up with the optimal number of servers and best initial VM placement.