ESXi 4.0 U1 and DS3500 (SAS), doesn't show multipathing

Had this at a customer site. Basicaly creating a claimrule for the ds3500. Basic summary:
esxcli nmp satp addrule -s VMW_SATP_LSI -V IBM -M "^1746*" -e "IBM DS3500"

You need to reboot to use the claim rules or just force it on a disk via
esxcli corestorage claiming reclaim -d

Full article at
http://www-01.ibm.com/support/docview.wss?uid=isg3T1012434

vCenter DB on full and no backups being taken

Results in logs that are to big. Changed the recovery model to simple and executed the following to truncated the log

USE vcms_nieuw
GO
DBCC SHRINKFILE("logicalname_log", 1)
BACKUP LOG vcms_nieuw WITH TRUNCATE_ONLY
DBCC SHRINKFILE("logicalname_log", 1)
GO

This cleaned up the logs. Waiting for the backup guys to take it over from here :)

vCloudPHP 1.0.1 : Howto get it working on Centos 5.5

• Start by downloading the tar.gz or the zip. You can also scp it to centos but i just used elinks :)
• install the redhat repo so that you can install php-pear
• You'll need the php-pear-HTTP-Request2 . I found it on the "remi' repo, so I added the repository. You can also install the rpm directly without adding the repository.
• install php
• Install the php-xml package
• install php-pear-HTTP-Request2
• You can now run helloVCloud.php

I noticed that you might have to restart the httpd service to reload the new PHP module

[root@request ~]# yum install elinks
[root@request ~]# elinks 'http://www.vmware.com/downloads/downloadBinary.do?downloadGroup=VCDSDKPHP101&vmware=downloadBinary&file=vcloudPHP-1.0.1-362508.zip'
[root@request ~]# tar -xzvf vcloudPHP-1.0.1-362508.tar.gz 
[root@request ~]# cd vcloudPHP-1.0.1/samples

[root@request samples]# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
[root@request samples]# rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
[root@request samples]# echo "enabled the repo"
[root@request samples]# cat /etc/yum.repos.d/remi.repo | grep -e "name" -e "enabled" -e "\["
[remi]
name=Les RPM de remi pour Enterprise Linux $releasever - $basearch
enabled=1
[remi-test]
name=Les RPM de remi en test pour Enterprise Linux $releasever - $basearch
enabled=0

[root@request samples]# yum install php
[root@request samples]# yum install php-pear-HTTP-Request2
[root@request samples]# yum install php-xml

[root@request samples]# php helloVCloud.php  -s '172.27.2.30' -u 'cloudadministrator@MyCloudOrg' -p 'testpass' -o='MyCloudOrg'

Injecting drivers with ESX 4.1 and creating an ISO

Actually based on vGhetto Blog

I'm just referencing what I did for myself . If you need more details, visit the link above

[root@vad iso]# mkdir /mnt/iso
[root@vad iso]# mkdir /mnt/edit
[root@vad iso]# mkdir /mnt/driver
[root@vad edit]# mkdir /mnt/newiso
[root@vad vi-admin]# sudo mount -o loop VMware-VMvisor-Installer-4.1.0.update1-348481.x86_64.iso /mnt/iso/
[root@vad iso]# cd /mnt/edit/
[root@vad edit]# bunzip2 -c ../iso/imagedd.bz2 > imagedd
[root@vad edit]# vibddi -i imagedd -q
< oem-vmware-esx-drivers-net-vxge (400.2.0.28.21239-1OEM) >
< oem-vmware-esx-drivers-scsi-3w-9xxx (400.2.26.08.036vm40-1OEM) >
< vmware-esx-firmware (4.1.0-1.4.348481) >
< CMPI-1.0 >
< VMW_CMPI_CPP-1.0.5 >
< vmkapi_1_1_0_0 >
< vmknexus1kvapi-1-4 >
< vmkepsecapi_1.0.0.0 >
< DriverAPI-9.0 >
< DriverAPI-9.1 >
< vmware-esx-tools-light (4.1.0-1.4.348481) >
[root@vad edit]# mount /home/vi-admin/vmware-esx-drivers-scsi-megaraid-sas_400.5.29-1vmw.2.17.00000.379626.iso /mnt/driver/ -o loop
[root@vad edit]# vibddi -i imagedd -o ../driver/offline-bundle/LSI_5.29-offline_bundle-379626.zip -n
[root@vad edit]# vibddi -i imagedd -q
< oem-vmware-esx-drivers-net-vxge (400.2.0.28.21239-1OEM) >
< oem-vmware-esx-drivers-scsi-3w-9xxx (400.2.26.08.036vm40-1OEM) >
< vmware-esx-drivers-scsi-megaraid-sas (400.5.29-1vmw.2.17.00000) >
< vmware-esx-firmware (4.1.0-1.4.348481) >
< CMPI-1.0 >
< VMW_CMPI_CPP-1.0.5 >
< vmkapi_1_1_0_0 >
< vmknexus1kvapi-1-4 >
< vmkepsecapi_1.0.0.0 >
< DriverAPI-9.0 >
< DriverAPI-9.1 >
< vmware-esx-tools-light (4.1.0-1.4.348481) >
[root@vad edit]# vibddi -i imagedd -c
Checking bootbank filesystems
Bootbank filesystems are valid
[root@vad edit]# bzip2 -cv imagedd > imagedd.bz2  imagedd: 
 3.052:1,  2.621 bits/byte, 67.24% saved, 943718400 in, 309208798 out.
[root@vad edit]# cp -R /mnt/iso/ /mnt/newiso/
[root@vad iso]# cd /mnt/newiso/iso/
[root@vad iso]# cp /mnt/edit/imagedd.bz2 /mnt/newiso/iso/
cp: overwrite `/mnt/newiso/iso/imagedd.bz2'? y
[root@vad iso]# echo "$(echo $(md5sum imagedd.bz2)| cut -f1 -d' ')  VMware-VMvisor-big-4.1.0-348481-x86_64.dd.bz2" > imagedd.md5
[root@vad iso]# cat imagedd.md5 
0a7814146df74441063a50c6609f6d35  VMware-VMvisor-big-4.1.0-348481-x86_64.dd.bz2
[root@vad iso]# cd /mnt/newiso/iso/
[root@vad iso]# mkisofs -o ../VMware-VMvisor-ICustom-4.1.0.update1-348481.x86_64.iso -b isolinux.bin -c boot.catalog -no-emul-boot -boot-load-size 4 -boot-info-table ./
[root@vad iso]# ls /mnt/newiso/*.iso -alh
-rw-r--r-- 1 root root 394M Apr 19 07:19 /mnt/newiso/VMware-VMvisor-ICustom-4.1.0.update1-348481.x86_64.iso
[root@vad newiso]# ls -alh /home/vi-admin/VMware-VMvisor-Installer-4.1.0.update1-348481.x86_64.iso 
-rw-r--r-- 1 vi-admin root 394M Apr 19 05:25 /home/vi-admin/VMware-VMvisor-Installer-4.1.0.update1-348481.x86_64.iso

This account is currently not available.

Warning, enabling your root account might pose extra security threads. If you don't care, read on :)

When you want to use the root account via su -, but you are getting this message it might mean that the shell is wrong in /etc/passwd. You'll get the following symptons

[vi-admin@vad ~]$ sudo su
This account is currently not available.

You can fix this by using the sudo vi /etc/passwd . You should fix the root line by changing the shell from /sbin/nologin to /bin/bash. for example

root:x:0:0:root:/root:/bin/bash

Save the file and you should be able to login.

ESXi still thinks it is connected to vCenter...

and you can't remove any resource pools. I had this issue because I created an SRM lab, tried the exercises and then reverted to snapshots. While testing the lab I created resource pools which were pushed to the ESX hosts. When I reverted to the snapshots, my vCenter was resetted, but the ESX hosts still had the vcenter agent running and in effect they thought they were still connected to a vCenter. You'll also get the annoying issue that when you reconnect a host to "another" vCenter, it will complain about already being managed. When you then try to remove the resource pool, the ESXi host for some reason auto recreates the resource pool. Very annoying :) You could readadd it to a vCenter and then properly remove it. However you can also do the following

Enable the remote technical support.
Run /opt/vmware/uninstallers/VMware-vpxa-uninstall.sh

You should be able to remove the resource pool. I remembered this command from an issue I used to have when I did a migration. Here is a link to the kb article

Zimbra antispam and antivirus not working

If you notice that mails are getting stuck in deferred status you might have the same problem that i just had. Check the logs for a message like this (/var/log/zimbra.log)

Apr  3 21:44:54 mail01 postfix/smtp[9304]: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused

First of all you should try to manually start the service

[root@mail01 conf]$ su zimbra -
[zimbra@mail01 conf]$ zmamavisdctl start
Starting amavisd...  The value of variable $myhostname is "mail01", but should have been
 a fully qualified domain name; perhaps uname(3) did not provide such.
 You must explicitly assign a FQDN of this host to variable $myhostname
 in amavisd.conf, or fix what uname(3) provides as a host's network name!

If you get this error you made a mistake like I did. I did gave the fqdn while setting up the server. You can fix this by executing

/opt/zimbra/libexec/zmsetservername -n mail01.demo

Then do an exit to get you back to the root shell and reboot