the birdhouse in my soul

(An update of an older post: now with vSphere 4.1 info. Further updated in 2011 with vSphere 5 info.) Your Linux runs on a VMware VM, but which ESX version is it ? You can see for yourself (as already explained in an earlier post on this blog). Run "dmidecode" and look at lines 10, 11 and 12. The list has been updated with current info: ESX 2.5 - BIOS Release Date: 04/21/2004 - Address 0xE8480 - Size 97152 bytes ESX 3.0 - BIOS Release Date: 04/17/2006 - Address 0xE7C70 - Size 99216 bytes ESX 3.5 - BIOS Release Date: 01/30/2008 - Address 0xE7910 - Size 100080 bytes ESX 4 - BIOS Release Date: 08/15/2008 - Address 0xEA6C0 - Size 88384 bytes ESX 4U1 - BIOS Release Date: 09/22/2009 - Address 0xEA550 - Size 88752 bytes ESX 4.1 - BIOS Release Date: 10/13/2009 - Address 0xEA2E0 - Size 89376 bytes ESX 5 - BIOS Release Date: 01/07/2011 - Address 0xE72C0 - Size 101696 bytes

My original home lab, three years old now, included two PC's running virtualization software, with Intel core 2 quad CPU's and 8 GB RAM each. While browsing for a replacement, I found Didier's Shuttle SX58J3 review . I researched some alternatives, but decided to go for the SX58J3 as well, fitted with 12 GB RAM and i7-970 CPUs, hexacores with hyperthreading. shallow: depth is critical in my telco rack. reduced height: I might get 4 shuttles in the same space as 2 minitowers earlier. They're actually slightly wider, but not by much. 12 GB per server is 50% more than the old lab (16 GB is supported but slower) the Intel core i7-970 CPU gives 100% more MHz than the old Q6600. They are much more expensive, truth be told. But being Westmere generation, they support vSphere4.1 features like DirectPath I/O and Fault Tolerance. I can re-use the PCIe dual gigabit adapters I had in the old lab. One real problem so far: in BIOS v100, I couldn't change any setting without rende...

Your Linux runs on a VMware VM, but which ESX version is it ? You can see for yourself (as already explained in an earlier post on this blog). Run "dmidecode" and look at lines 10, 11 and 12. The list has been updated with current info: ESX 2.5 - BIOS Release Date: 04/21/2004 - Address 0xE8480 - Size 97152 bytes ESX 3.0 - BIOS Release Date: 04/17/2006 - Address 0xE7C70 - Size 99216 bytes ESX 3.5 - BIOS Release Date: 01/30/2008 - Address 0xE7910 - Size 100080 bytes ESX 4 - BIOS Release Date: 08/15/2008 - Address 0xEA6C0 - Size 88384 bytes ESX 4U1 - BIOS Release Date: 09/22/2009 - Address 0xEA550 - Size 88752 bytes

Red Hat and related distro's (like CentOS) use 1000 timer interrupts per second, per CPU core or thread (this is called the "HZ value" inside the kernel). Because this causes a lot of extra work in case of virtualization, and caused (past tense since RHEL 5.4!) problems with timekeeping, the " divider " kernel parameter has been introduced. For example, by booting with "divider=10", the kernel uses 100 timer interrupts instead of 1000, and "divider=25" means 40 timer interrupts per second. I did a little test today to see what difference that makes when running CentOS5.4 on vSphere. Tests were done with the current 2.6.18-164.11.1.el5 x86_64 kernel in a single vCPU VM. These are the results from my test environment: standard settings: HZ=1000: 60 MHz cycles used when idle. divider=2: HZ=500: 36 MHz cycles used when idle. divider=5: HZ=200: 25 MHz cycles used when idle. divider=10: HZ=100: 20 MHz cycles used when idle. divider=25: HZ=40: a...

An interesting issue popped up: how can a program or script in a VM determine the type and version of the hypervisor it is running on ? This is important if you want to install version-specific software, like the VMware Tools ("enlightened hardware drivers", as MS would say). Knowing that you're running in a virtual machine is pretty easy: you can look at the hardware, on VMware you'll see "00:0f.0 VGA compatible controller: VMware Inc Abstract SVGA II Adapter" which makes it pretty clear, and lspci -v says "Subsystem: VMware Inc" for every PCI device. Easy as 1 2 3. But which version of VMware ESX is it ? Not that easy, it seems. But we (hi Dag !) found a unique signature for each ESX version: looking at dmidecode, the output in the "BIOS Information" section lists a Release Date and an Address field. These seem to be unique for each ESX version. The mapping we could build was: ESX 2.5 - BIOS Release Date: 04/21/2004 - Address 0xE8480 -...

One of the first steps in a virtualization project is building a list of workloads that will get virtualized, with a measurement or estimate of the resources that they will need. X MHz and Y MB, sum everything up, and let's say you get 30 GHz of CPU power and 20 GB of RAM. The hardware you'd like to run all those virtual machines on can handle two CPUs (dual-socket), four cores each (quad-core). That means that every physical server will give you between 20 and 25 GHz of CPU power. For memory, you'll buy 12 GB of RAM in each server. So the plan is to buy two of those servers, right ? Well, as long as your infrastructure is 100% healthy and running OK, two servers will do the job just fine. You've got enough resources, with a bit of headroom for overhead and future growth. But what happens when one of the physical servers is down ? Think of hardware problems, think of virtualization software upgrades, think of patching the hypervisor. Then the available resources are dow...

When you're shopping for ESX servers to build your next production cluster, you know where to look. The hardware compatibility lists at vmware.com are frequently updated, and contain everything you need to know. But what about test labs ? When you don't care too much about "is it supported" but rather ask yourself "does it work" and "can I buy something cheaper" ? I asked myself the same questions when I built my own testlab. And this was my choice: 2 identical PCs, equipped with MSI MS7345 motherboard Q6600 intel CPU 8 GB of RAM (four times 2 GB) PCI Promise SATA 300 TX2plus 80 GB sata harddrive (smallest I could get) a dual port Intel gigabit card Add a third PC, similar but with more diskspace, running CentOS 5 with IET as an iSCSI server, and you get a 19 GHz, 16 GB VI3 cluster with several hundred GB storage space. Perfect for testing, and without losing an arm and a leg paying for them.

So you're running the new ESX 3.5 update 2. And you want to try the new EVC feature on your cluster. And you've found it under "edit settings" on your cluster object... And then VirtualCenter refuses to enable it for you, because there is still at least one VM powered on in the cluster. Of course there is, because your VirtualCenter runs in a VM, in that same cluster. Catch-22 ? Well, getting round this is a bit weird, but nevertheless possible. Here's what I did on my two-node test cluster: Step one: you evacuate one ESX host in your cluster. You put it in maintenance mode, and move it out of the cluster, right under your datacenter object. Two: manually migrate (VMotion via drag-and-drop for example) your VirtualCenter VM (running on a host in the cluster) to the host that is now outside the cluster. Do this with all other VMs that were still running in the cluster. Three: enable EVC on your cluster. This now works, because the cluster doesn't contain any ru...