What in the world does this command do?
esxcfg-boot
esxcfg-boot
-h –help
-q –query bootvmkmod
-p –update-pci
-b –update-boot
-d –rootdev UUID=
-a –kernelappend
-r –refresh-initrd
-g –regenerate-grub
Queries cannot be combined with each other or other options. Passing -p or -d enables -b even if it is not passed explicitly. -b implies -g plus a new initrd creation. -b and -r are incompatible, but -g and -r can be combined.
Here is some output from my lab:
[root@esxlab2 root]# esxcfg-boot -q boot
272 0:*; UUID=96c048d7-ee1d-4455-b6a5-801bfbaabbdc /vmlinuz-2.4.21-7.ELvmnix /initrd-2.4.21-57.ELvmnix.img
[root@esxlab2 root]# esxcfg-boot -q vmkmod vmklinuxmptscsi_2xx.oe1000.olvmdrivervmfs3etherswitchshapertcpipcosShadow.omigrationnfsclientdeltadiskvmfs2
I am picturing these commands to be much like kernel options, modprobe and bootloader settings you would set up when you compile your kernel in Linux. Most hardcore linux guys would let you know you are a real man when you recompile your own kernel. In VMware, I would be hesitant to mess with any of this unless I broke something. Then again, with all of my VM’s on the SAN, if I bombed out an ESX host this bad, I would take 20 minutes to rebuild it.
Then I noticed from the B2V Guide that I would make use of this when I changed my queue depth on my hba’s. Which I have done before. I followed this note on the forums.
What other device driver options beside the hba will you every change?
Here is some things I found:
More HBA problems
And even more queue depth fun
And this list could be longer, just searching VMware Community.
I would guess that the reason we don’t jack with the drivers with ESX and the hardware is becuase of the very good compatibility list. You don’t just run ESX 3.5 on anything (at least not for production).