Yellow Bricks

by Duncan Epping

Archives for 2009

Run the Golden Gate Bridge – VMworld 2009

· ·

A few weeks ago @jasonboche and myself discussed doing a daily run during VMworld. This single tweet evolved into something no one expected… “Run the Golden Gate Bridge” event. After several discussions with David Davis from Train Signal we decided that because of the huge amount of people interested and several positive reactions for sponsoring that VMware / VMworld should take over.

We’ve just started the whole discussion internally at VMware and everyone is really excited about this. I can’t give any details at this point time but I promise we will have them soon. If anyone is interested to sponsor the run in anyway please let me know, all donations will go to charity of course! Currently we have Veeam, EMC, VMware, Train Signal, NetApp and possibly 3-PAR committed.

Of course I expect every single one of you to run along!

vGhetto Script Repository

· ·

I regularly check William Lam’s section on the VMTN communities. William is definitely one of the most active contributors in terms of perl / vMA scripting. William wrote the famous ghettoVCB script which basically enables you to do full image level backups of your VMs. But that’s not the only script William wrote. He’s also written scripts for creating screenshots of VMs, resizing your vMA disks, hotplugging memory and CPUs, suspending VMs and a whole lot more. Definitely worth the bookmark: http://communities.vmware.com/docs/DOC-9852

vSphere CPU Scheduler whitepaper, this is it!!

· ·

This is the whitepaper I’ve been waiting for. By now we all know that the CPU Scheduler has changed. The only problem is that there wasn’t any official documentation about what changed and where we would benefit. Well this has changed. VMware just published a new whitepaper titled “The CPU Scheduler in VMware® ESX™ 4“.

The CPU scheduler in VMware ESX 4 is crucial to providing good performance in a consolidated environment. Since most modern processors are equipped with multiple cores per processor, systems with tens of cores running hundreds of virtual machines are common. In such a large system, allocating CPU resource efficiently and fairly is critical. In ESX 4, there are significant changes to the ESX CPU scheduler that improve performance and scalability. This paper describes these changes and their impact. This paper also provides details of the CPU scheduling algorithms in the ESX server.

I can elaborate all I want but I need you guys to read the whitepaper to understand why vSphere is performing a lot better than VI 3.5. (I will give you a hint: “cell”.)

Another whitepaper that’s definitely worth reading is “Virtual Machine Monitor Execution Modes: in VMware vSphere 4.0“.

The monitor is a thin layer that provides virtual x86 hardware to the overlying operating system. This paper contains VMware vSphere 4.0 default monitor modes chosen for many popular guests running modern x86 CPUs. While most workloads perform well under these default settings, a user may derive performance benefits by overriding the defaults. The paper examines situations where manual monitor mode configuration may be practical and provides two ways of changing the default monitor mode of the virtual machine in vSphere.

And while you arealready taking the time off to educate yourself you might also want to read the “FT Architecture and Performance” whitepaper. Definitely worth reading!

New book in town: vSphere Quick Start Guide

· ·

Months ago I shared an idea on Twitter about starting a “super blog”. This “super blog” should have contained the top articles of some of the best VMware or virtualization bloggers around. I asked myself what the added value would be and came to the conclusion that there already were many “super blogs” around. Although the “super blog” idea died a slow death the urge to collaborate with others on a challenging project still lived on. (Although Stephen Foskett picked it up and created Gestalt IT at the time.)

This is when the idea of a book series was born, which I for obvious reasons did not share with the twitter community. This book, and hopefully the rest of the following books, is written by six well known VMware community members. I don’t think they need further introduction so here are there names: Bernie Baker(thanks Chad for the tip), Thomas Bryant III, Stu Radnidge, Dave Mishchenko, Alan Renouf and myself of course.

The original idea was to publish a series of short topics, deep-dives, with each book limited to 150 pages, pocket size, sold at a minimum price and completely “diy”. For those unfamiliar with the term “diy” it means “do it yourself”. In other words we do not have a publisher helping us or funding it. We also don’t have a marketing budget, so we are relying on you guys to spread the word and we will be relying on Lulu.com for distributing/selling it.

When we started outlining our first book Ron Oglesby gave us the opportunity to rewrite the Quick Start Guide he and his team at RapidApp published in March 2007. We all agreed that this would be a good start of the series. Thanks again Ron! Of course this book will exceed the limit we agreed on of 150 pages, but it is worth it. We hope to get it done before VMworld and bring a couple of copies to VMworld but the clock is ticking fast and we are not there yet. We will keep you informed!

I just hope we can get all you guys as excited about new technology and VMware products in general as we are!

HA and Slot sizes

· ·

This has always been a hot topic, HA and Slot sizes/Admission Control. One of the most extensive (Non-VMware) articles is by Chad Sakac aka Virtual Geek, but of course since then a couple of things has changed. Chad commented on my HA Deepdive if I could address this topic, here you go Chad.

Slot sizes

Lets start with the basics.

What is a slot?

A slot is a logical representation of the memory and CPU resources that satisfy the requirements for any powered-on virtual machine in the cluster.

In other words a slot size is the worst case CPU and Memory reservation scenario in a cluster. This directly leads to the first “gotcha”:

HA uses the highest CPU reservation of any given VM and the highest memory reservation of any given VM.

If VM1 has 2GHZ and 1024GB reserved and VM2 has 1GHZ and 2048GB reserved the slot size for memory will be 2048MB+memory overhead and the slot size for CPU will be 2GHZ.

Now how does HA calculate how many slots are available per host?

Of course we need to know what the slot size for memory and CPU is first. Then we divide the total available CPU resources of a host by the CPU slot size and the total available Memory Resources of a host by the memory slot size. This leaves us with a slot size for both memory and CPU. The most restrictive number is the amount of slots for this host. If you have 25 CPU slots but only 5 memory slots the amount of available slots for this host will be 5.

As you can see this can lead to very conservative consolidation ratios. With vSphere this is something that’s configurable. If you have just one VM with a really high reservation you can set the following advanced settings to lower the slot size being used during these calculations: das.slotCpuInMHz or das.slotMemInMB. To avoid not being able to power on the VM with high reservations these VM will take up multiple slots. Keep in mind that when you are low on resources this could mean that you are not able to power-on this high reservation VM as resources are fragmented throughout the cluster instead of located on a single host.

Host Failures?

Now what happens if you set the number of allowed host failures to 1?
The host with the most slots will be taken out of the equation. If you have 8 hosts with 90 slots in total but 7 hosts each have 10 slots and one host 20 this single host will not be taken into account. Worst case scenario! In other words the 7 hosts should be able to provide enough resources for the cluster when a failure of the “20 slot” host occurs.

And of course if you set it to 2 the next host that will be taken out of the equation is the host with the second most slots and so on.

What more?

One thing worth mentioning, as Chad stated with vCenter 2.5 the number of vCPUs for any given VM was also taken in to account. This led to a very conservative and restrictive admission control. This behavior has been modified with vCenter 2.5 U2, the amount of vCPUs is not taken into account.