Some commando's I always need to lookup so lets gather them a bit
First of all, ESXi modules work a lot like linux. You can find them in a specific location
~ # ls /usr/lib/vmware/vmkmod/bnx*
/usr/lib/vmware/vmkmod/bnx2.o /usr/lib/vmware/vmkmod/bnx2i.o /usr/lib/vmware/vmkmod/bnx2x.o
You can also list the active modules
~ # esxcfg-module -l | grep bnx
bnx2 1 180
bnx2i 0 88
More info about a module can be obtained with the -i switch
~ # esxcfg-module -i bnx2
esxcfg-module module information
input file: /usr/lib/vmware/vmkmod/bnx2.o
License: GPL
Version:
Name-space:
Required name-spaces:
com.vmware.vmkapi@v1_1_0_0
Parameters:
disable_msi: int
Disable Message Signaled Interrupt (MSI)
heap_initial: int
Initial heap size allocated for the driver.
heap_max: int
Maximum attainable heap size for the driver.
skb_heap_initial: int
Initial private socket buffer heap size allocated for the driver.
skb_heap_max: int
Maximum attainable private socket buffer heap size for the driver.
stop_on_tx_timeout: int
For debugging purposes, prevent a chip reset when a tx timeout occurs
You can then get the current options
~ # esxcfg-module -g bnx2
bnx2 enabled = 1 options = ''
Setting an options works with the -s parameter
~ # esxcfg-module -s "oneRequest=false" nfsclient
~ # esxcfg-module -g nfsclient
nfsclient enabled = 1 options = 'oneRequest=false'
~ # esxcfg-module -s "" nfsclient
~ # esxcfg-module -g nfsclient
nfsclient enabled = 1 options = ''
Enabling modules is done by using the -e parameter. To disable a module, you will need the -d switch. Notice, you will need to reboot to get the module enabled this way
~ # ls /usr/lib/vmware/vmkmod/ | grep tg3
tg3.o
~ # esxcfg-module -e tg3
~ # esxcfg-module -d tg3
Esxcfg that a lot of things that the vmkload_mod command does. You can load modules live by using this commando. You will not have to reboot the server
~ # vmkload_mod tg3
Module tg3 loaded successfully
~ # vmkload_mod -u tg3
Module tg3 successfully unloaded
You can also see that the vmkload_mod gives similar output as the esxcfg-module
~ # vmkload_mod -l | grep tg3
tg3 0 120
~ # vmkload_mod -s tg3
vmkload_mod module information
input file: /usr/lib/vmware/vmkmod/tg3.o
Version: Version 3.86.0.1-1vmw, Build: 320137, Interface: ddi_9_1 Built on: Nov 2 2010
License: GPL
Required name-spaces:
com.vmware.vmkapi@v1_1_0_0
Parameters:
skb_heap_max: int
Maximum attainable private socket buffer heap size for the driver.
skb_heap_initial: int
Initial private socket buffer heap size allocated for the driver.
heap_max: int
Maximum attainable heap size for the driver.
heap_initial: int
Initial heap size allocated for the driver.
tg3_debug: int
Tigon3 bitmapped debugging message enable value
~ #
Another fun thing to do with the vmkload_mod is loading the cdrom driver
~ # vmkload_mod iso9660
Module iso9660 loaded successfully
Then you can mount the cdrom with
vsish -e set /vmkModules/iso9660/mount $(esxcfg-mpath -b | grep "CD-ROM" | awk '{print $1}')
You should the see the cdrom mounted in /vmfs/volumes
Unmount it later on
vsish -e set /vmkModules/iso9660/umount $(esxcfg-mpath -b | grep "CD-ROM" | awk '{print $1}')
Afterwards unload the module
~ # vmkload_mod -u iso9660
Module iso9660 successfully unloaded
(CDROM commands are from (http://www.virtuallyghetto.com/2011/04/how-to-mount-cdrom-using-vsish-on-esxi.html)
2011/07/05
2011/05/20
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
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
2011/05/18
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 :)
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 :)
2011/04/20
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'
2011/04/19
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
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.
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.
2011/04/05
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
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
Subscribe to:
Posts (Atom)