vCartoon of the Week (07/18/2011)

Another great idea that isn’t really mine came from old friend. So basically every Monday (I will try my best) I plan to post a cartoon in the “vCartoon” section of my blog. The vCartoons will cover the virtual world in a comical way to lighten our already long Mondays. I have never been the artistic kind so I had to reach out to an old friend of mine. The vCartoons are produced by M. Ali.

As of now I haven’t figured out how to create a link to a category. As soon as I do, you will see a link to simply view all the vCartoons on the blog. If you have a vCartoon idea please send it to me I will request Ali to make it happen. In light of the licensing fiasco, enjoy the first vCartoon.


vSphere 5 licensing and what should you do – Think again

With vSphere 5 and its new licensing model, a fire storm has started across the internet resulting in very upset customers who think they are getting screwed by VMware. So I figured I will try a put together something that might help us all analyze the issue here. I keep hearing it’s really bad for SMB. Is it really as bad as we think it is?

Assuming we are all on 4.1 (not to mention with 4.1 HD/DRS limits were increased that should have helped in reducing the number of CPU licenses, I don’t remember VMware being thrown a party for that at the time), below are some limits for a 4.1 cluster:

  • Number of hosts per cluster (HA/DRS) = 32
  • Number of VMs per host = 320
  • Number of VMs in a HA/DRS cluster = 3000

For the purpose of this post, I will not push for the limits here but I just wanted to put the facts out there. We will assume we have the following setup in the 4.1 world:

  • 12 Hosts – dual processors – 256GB of memory each
  • 24 Enterprise Plus licenses
  • 2 – 6 host clusters (this will give has 1536GB of memory on each one our clusters)
  • HA/DRS is enabled and Admission controlled is also enabled (cluster failure tolerance is set to 1)
  • We will take one host out of the equation for HA to function which will leave us with 1280GB of memory in each one of our clusters

So what do we need to power on the same setup in vSphere 5? That will depend on the number of total physical CPUs we have and the total number of configured RAM in the VMs that will be powered on. We know we have 24 CPUs but what about the vRAM that will be needed to bring up all the VMs? If we go strictly by the number of total CPUs, we will have 24 * 48 = 1152GB in our vRAM pool. What does this mean?

With 1152GB in your vRAM pool you can only power on VMs that have a total of configured memory less than or equal to 1152Gb. Keep in mind with the exception of Essentials and Essentials Plus, these are only soft limits and I highly recommend you don’t exploit this area either.

We calculated earlier that we had 1280GB available earlier in each of the two clusters. But now we only have a total of 1152GB across the two clusters. This is not a moment to panic and freak out. This is the time to figure out how much memory do you really need. Let’s run a few examples. Let’s assume we have:

  • 200 2GB VMs
  • 500 4GB VMs
  • 80 8GB VMs
  • 20 24GB VMs
  • For the purpose of this discussion, we have no limits
  • And all VMs are on at all time

The amount of memory that’s allocated above is 3520GB when we really have 1280*2 of pRAM available and the magic of over-commitment is making all this come to life. Assuming the load above is evenly spread we are looking at 800 VMs spread across 2 6Host clusters. That is roughly about 67 VMs per host and I am not going to comment on the sanity of that setup (with the exception of VDI but even that is a little out there and most SMBs that I know of don’t leverage VDI yet). With only dual processors in each host running such a load will probably cause cpu ready issues in your environment. But I will boldly assume it all just works. So what do you have to do to make this setup work in vSphere 5?

Before we do that lets have a quick look at this document. In section 4.4 it clearly states that the recommended number of hosts for 500 VMs is 50 hosts to maintain reasonable performance with vCenter etc etc. Just thought I will compare that to the 800 VMs we are running in our 2 6host cluster example. Ok lets get back to craziness.

Since your total allocation is 3520GB your vRAM pool will have to be the same size, you will need 3520/48=73 Enterprise plus licenses to run the same gig in vSphere 5. That is 49 more licenses that what you previously had. But that is if you are trying to run the setup I mentioned above. Compare that to the cost of running 800 physical servers and you will definitely see the cost savings with virtualization. Is Hyper V or Xen a good option? Probably not.

What should you do?

  • I highly recommend you review your environment. It’s possible that some VMs in your environment are oversized, this will be a good time to give them what they need. No more oversizing as this will result in licensing costs to your organization.
  • Moving to Xen or Hyper V may not really be the best move. If you are using Enterprise Plus, chances are you will go in a state of depression with either one of these tools as they don’t come close to what vSphere 5 has to offer (I will cover the new capabilties of vSphere 5 in a few days).
  • What is a comparable product to vSphere, the honest answer is none. Accept that fact and make the best of the situation.
  • Do cost benefit analysis on what more functionality will you gain with vSphere 5. If this will enable you do more (SRM 5 has automatic failback), is the extra cost worth it? Or should you wait?
  • Wait! If you realize you don’t need the new functionalities in vSphere 5, don’t upgarde just yet. This will buy you more time before you go in front of your CIO to upgrade to vSphere 5. I like this approach the most as this will increase your chances of staying with your favorite hypervisor. Xen and Hyper V are just not there yet and we all know it.

The example above is an extreme case in my opinion and you will probably not be in such a bad shape. Calculate what you have today, how much vRAM you will need. Look around and see if you can reclaim memory from oversized VMs. That will be the best place to start.

As of today, you can still buy vSphere 5 licenses and downgrade them to vSphere 4, do that until the time is right for you to upgrade your environment. But most importantly review your environment. If you can reclaim configured VM memory, do everything in your power to do so. After all, oversized VMs will cost you more money now, that fact alone will get you all the backing you will need to start “mission reclaim”.


Duplicate MACs in vCenter

I don’t have a lot of experience with Hyper-V, but I have worked with people who have. After hearing their horror stories, I don’t envy acquiring that sort of experience. Speaking of horror stories, my favorite one is, when one of my co-workers told me about a Hyper-V environment they had setup which was generating duplicate MAC addresses. I was amused but in the back of my mind I started thinking if this was possible in a vSphere setup. Yes it is.


vCenter assigns MAC addresses using the unique ID that’s assigned to it under AdministrationvCenter Server Settings > Runtime Settings

This unique ID can be set to a value between 0-63. If you have two or more vCenter’s running the same instance ID, its only a matter of time before you start seeing mac conflicts in your environments.

vCenter assigns MAC addresses using a simple formula (00:50:56:80HEX+UID:00:00). So if your vCenter ID is 45, your VMs mac should be 00:50:56:ad:XX;XX. As you can tell the fourth byte is what can help you identify which vCenter was used to create the VM. The fifth and sixth bytes are the ones that are usually edited if you have a need for assigning a MAC instead of vCenter doing it for you.

Another interesting thing I noticed, I saw 3 different types of MAC addresses in my VMs. I saw,

VM1 00:50:56:ad:c2:3F

VM2 00:0C:29:73:B1:2F

VM3 00:5056:a5:d2:6F

It turns out, that VM1 was created on my new vCenter with a UID 45 (ad=80HEX + 45), VM2 was created directly on a ESXi host and VM3 was created on a different vCenter with a UID of 37(a5=80HEX + 37).

Though these little things don’t matter as much, but its important to know how all this comes together. It will be very helpful when you find yourself in a situation where your VMs have identical MACs. Someone forgot to set a unique ID for their vCenter.