Archive for December, 2010

Happy New Year!

30 Dec 2010 Leave a comment

Happy New Year!

All the best for a great 2011!

Categories: general

VMware CapacityIQ 1.5 released

VMware has just released a new version of Capacity IQ, namely VMware Capacity IQ 1.5.

The new features are:

  • Storage Analytics – Adds disk space and disk I/O trending and storage analysis. The dashboard and views provide visibility into consumption of storage resources and ways to identify capacity bottlenecks. The data is optimized for vSphere and accounts for thin provisioning, I/O control, and linked clones.
  • Resource optimization – Adds storage-aware workload modeling and what if scenarios to forecast future capacity needs. CapacityIQ provides outlier detection and filtering capabilities for improved analytics.
  • Scheduled Reports – Adds report scheduling with email capabilities for automated delivery of capacity utilization and optimization reports.
  • Performance and scalability improvements – Improves the response time in the interface and raises the scalability limits to 6000 powered on virtual machines and 8000 registered virtual machines.
  • Virtual machine-based licensing – Supports virtual machine and CPU-based licensing. If you obtain a virtual machine-based license for CapacityIQ, install and manage the license from vCenter Server instead of the Administration Portal. You can continue to manage CPU-based licenses in the Administration Portal.

You can read the full release notes here and download the software here

Categories: virtualization, vmware, vsphere Tags:

Some thoughts about pCPU/vCPU

1 Dec 2010 5 comments

Yesterday I’ve seen some question posted on the community forum about vCPU and pCPU that made me think about the fact that there are still some misconception about the relationship between vCPU and pCPU.

I thought that nowadays the concepts of pCPU, vCPU and their relationship are well known, but it seems that I’m wrong. In this post I will explain the basic concept.

A personal note: Thanks to my friend @vladan that encouraged me to publish my thought about this subject! I think that the right attitude about doing a post is “if something that I think is common knowledge is somewhat not so well known, it’s worth a post”.

What is a pCPU?

A pCPU denotes a physical CPU.

A physical CPU refers to:

  • a physical CPU core if hyperthreading is unavailable or disabled


  • a logical CPU (also known as SMT thread) if hyperthreading is enabled.

Some examples:

  • a host equipped with 2 x Xeon 5405 has 8 pCPU: 4 CPU core per socket x 2 sockets = 8 CPU core.
  • a host equipped with 2 x Xeon 5520 can have 8 or 16 pCPU:
    • if hyper-threading is disabled it has (4 CPU core per socket x 2 sockets)= 8 CPU core
    • if hyper-threading is enabled it has (4 CPU core per socket x 2 SMT thread per core x 2 sockets)= 16 logical CPU

What is a vCPU?

A vCPU denotes a virtual CPU. A virtual CPU refers to a virtual machine’s virtual processor.

A vCPU runs on a pCPU. It is an execution context on a pCPU and, like a process, a vCPU can be in running state, ready state, wait state or wait_idle state.

You can configure each virtual machine to have up to 8 vCPU: the current number is limited by the vSphere license purchased,  by the total pCPU of the host (on a dual proc/dual core host the maximum number of vCPU per VM is 4) and by the guest OS.

And the 1 billion dollar question…

Yes, the recurring question is “How many total vCPU I can use if my host has X pCPU?”.

The answer is… “it depends”.

First of all there is no 1:1 relationship between total vCPU and total pCPU: the maximums, as described in  the Configuration Maximums for ESX 4.1 doc, are 512 vCPU per host and 25 vCPU per core, but those are just maximums!

The correct question is “what consolidation ratio can I obtain while having good VM performance?” And there is no silver bullet for this problem: you have to know the workloads that will be present, or at last estimate them. And you also need to understand what a “good performing VM” means: for example, the acceptable performance for a test or preproduction VM can be something that is totally unacceptable for a production VM!

So, the correct way to begin with is to understand the workloads involved and testing.

But, what if you can’t have a clear idea about your workload or you have too much different kind of them?

Well,  I use a rule of thumb: I start with a consolidation ratio of 3-5 vCPU per pCPU and then I monitor the cluster performance and the user perceived performance to understand if everything goes well and if I can push the consolidation ratio.

Anyone want to share some thoughts about this?

[tweetmeme only_single=”false”]
Categories: virtualization, vmware, vsphere Tags: ,