TIA,
J

It does all come down to comfort level and number of VMs. Obviously if you have 40 VMs on a host and 50% of the time they’re getting blocked from running you have a problem. Of course if those 40 VMs really weren’t doing anything all the time (maybe you have 40 idle print servers or DHCP servers or something) then 50% ready really isn’t a big deal. I too used to say anything over 5% ready is bad. I’ve slowly increased it over time to the 50% threshold. Again, these are my recommendations – not VMware’s. You’ll have to find something that you’re comfortable and as always LOOK and UNDERSTAND your applications. I’ve seen too many customers that have no clue what they’re app is doing or is supposed to be doing and then they want to start troubleshooting at the virtualization layer. Bad idea.

%RDY (READY spelled out) means the percentage of time that a VM is ready to run but can’t run because it can’t get onto a CPU. Basically the VM was next up in line to get scheduled but all of the lCPUs were busy. The higher the %RDY the more contention you have on the host. There are 2 things you could do to reduce %RDY:

1) Reduce the number of vCPUs in your guests.I see the case all the time where people create 2 vCPU guests by default whether the app needs it or not. This is because they had 2 CPU physical hosts so they’re just following what they did in the physical world. The problem is 2 vCPU guests take up twice as many lCPUs when scheduled. The more lCPUs in use with more VMs means someone has to wait and %RDY goes up. This is just fine most of the time but I generally say if you see %RDY higher than 50% then you should look at your VMs and determine if they really need that other CPU. If you decide that you can knock down the vCPU count in a VM make sure to change the HAL in Windows or kernel in Linux to match the single CPU VM. Going from multi-proc HAL/kernel to single-proc HAL/kernel is easier (and supported) in the Linux world than the Windows world.

One clue that the VM doesn’t really need the second vCPU is to look at %WAIT. If %WAIT is higher then 30% there’s a good chance the second CPU is just sitting idle when the VM gets scheduled.

2) The other thing you can do is buy another physical host to increase the core count in your cluster.

NOTE: The recommended percentages I’m giving you for %RDY and %WAIT are my personal recommendations just based on seeing this stuff for 6 1/2 years at various customers. You may feel comfortable with lower limits. I know of one customer that won’t go over 30% for %RDY or 10% for %WAIT. I’m just telling you what to look for. With some practice tuning in your environment with your workloads you’ll be able to find out the exact threshold you need.

I hope this helps.

But at the same time if we look at the performance tab of the HOST we can see that tfor a 100% of VM cpu utilization the host’s graph only reaches 25%!!!
That is because the VM is stressing only one core (2 processors * 2 cores = 4. So 1/4 = 25%) ?????

Can we achieve more utilization?

PS1: I’ve checked the affinity of the VM and It can be ran in all the cores.

PS2: It is true also that with 1vCPU, the %RDY parameter (esxtop) decreases wich is good. What is the good value for %RDY? Less than 5%?

Thanks for your time!
J

Thanks for the clarifications, and I changed your URL in the body of the post. Did it recently change?

Most importantly, thanks for the great VMworld presentation!

1) If you need more than 768 MB of RAM then go ahead and allocate it. Jason Willey’s comment hit the nail on the head. What I meant to say was there are a lot of Linux VMs out there doing simple tasks that were given 1 GB of memory as a default install and they really don’t need it. Once you break the 768 MB threshold in most Linux distros then you end up allocating another chunk of memory for file system cache. Staying under 768 MB if your VM doesn’t need it prevents the extra memory usage for file system cache which means you can get more VMs on a host (generally memory is the limiting factor to VM density).

2) Nearly all apps out there will scale better when you stack multiple single CPU VMs on a host versus fewer multi CPU VMs – even apps like databases that like multiple CPUs. The reason is writing a true, preemptive multi-processing, multi-threaded application that behaves properly with the underlying operating system’s scheduling is very difficult. Whenever you add more CPUs to the mix from a scheduling standpoint whether it be physical or virtual you add overhead since you must keep the multiple CPUs in sync. Scaling out with multiple single CPU VMs allows for more flexible VM scheduling and also removes the overhead in a multi processor Guest OS and App stack. Now, if you want to scale out with multi CPU VMs that’s fine. I was simply making the point that VMs allow you to think differently and scale differently. Of course it’s a though process that’s uncomfortable for most.

3) I’ll be posting the PXE booting of ESX soon.

4) The correct URL for my blog is http://www.mikedipetrillo.com.

5) Andy Leonard posted a great URL that I had forgotten to hand out before for time sync in guests. Make sure to check it out in the comments above.

I hope that clears some things up.