Following from my popular (according to me!) blog post theme – of “what I learned this week…” a irregular round-up of stuff that seems really obivious – but actually has escaped me.

vCenter DB Retention Policy:

A couple of weeks ago I made a point about how the vCenter DB grows in size day-by-day and week-by-week – and that wasn’t away to control it size or FIFO its data. I turned out I was wrong. If you look in the vCenter Server Settings. In vCenter 4.0 there is actually something called the retention policy.

What I was hoping for was the ability to FIFO the performance data. As far as I know the only way to clear performance data is with SQL Transact commands to delete the redundant data.

VMware Tools won’t upgrade:

I’ve a couple of VMs who’s VMware Tools won’t upgrade. I think it maybe because the uninstall data was deleted – erm, by me. Opps. Anyway, I think I might have found a work around in this KB article.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001354

ESXi lacks RPMs for VMware Tools for Redhat Linux 64-bit:

This is little bit of an obscure one – and it was drawn to my attention by one of my students. If you create a Red Hat Linux 64-bit (RHEL5) on an ESX ‘Classic’ host you will find you have both the ability to install VMware Tools with either an .RPM or extract it from a .TGZ file. NOW, if you try the SAME thing on ESXi host you will find the RPM version isn’t there. Presumably this is done by VMware to reduce the footprint of ESXi.

Find out if your virtual disks are the right type for VMware Fault Tolerance:

This one came thru twitter. Specifically from William Lam. Thanks William this is great find. William has a great resource of scripts on his website:

http://www.engr.ucsb.edu/~duonglt/vmware/

My previous method of finding this out was pretty lame. It involved using vmkfstools and vmkernel log files – and looking at very obscure values therein. This is MUCH easier; MUCH clearer, and MUCH simpler.

Why is this important. Well, let say your VM has the ordinary thick type of disk (technical term is zeroedthick) or you have used the thin type – AND these disks are quite large (let say 2TB). To convert these disks the Fault Tolerance format (eagerzeroedthick format) requires a power off of the VM, and it can take a long time. That’s got to be factored into your maintenance window.

Of course none of this matter if the vSphere Client/vCenter actually showed the correct format. Unfortunately, both the zeroedthick and eagerzeroedthick format are both referred to as “thick” in the GUI.

Here’s how you do it.

Just cat & grep the last vmware.log file of the VM which you can see in the directory where the VM is located. So here’s a VM with three types of disk. Thin (scsi0:0), EagerZeroedthick (scsi0:1) and Thick (scsi0:2). In the screen grab you can see scsi(0:0) is thin

If you then PuTTy to a ESX host, and the type the following command:

[root@esx1 mail03]# cat vmware-1.log  | grep  ‘FT enable’

This will produce the output of:

Dec 02 00:38:08.505: vmx| VM has thin disk scsi0:0; FT enable will be disallowed
Dec 02 00:38:08.507: vmx| VM has zeroedthick disk scsi0:2; FT enable will be disallowed

Alternatively, if you use

[root@esx1 mail03]# cat vmware-1.log  | grep  ‘scsi0:0′

[root@esx1 mail03]# cat vmware-1.log  | grep  ‘scsi0:1′

[root@esx1 mail03]# cat vmware-1.log  | grep  ‘scsi0:2′

This will print out much detailed information. The difference between each output is the “allocation type” field. These are are as follows:

allocation type: 0 – EagerZeroedthick Virtual Disk

allocation type: 1 – Zeroedthick Disk (Default)

allocation type: 2 – Thin Virtual Disk

This entry was posted on Wednesday, December 2nd, 2009 at 12:58 am and is filed under ESX, vCenter. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.