I had trouble with that python script. The author responds to posts on the forum about it though, which deserves a nod.

But I got impatient (see attached):

usage: renum-vmnic < esx.conf > esx.conf.renum

The key to vmnic ordering in esx.conf is to remember that the devices are listed in ascending PCI address order.

The first instance of an Ethernet card in the device section of esx.conf (look for vmkname) should be vmnic0, and increment up one from there for each subsequent device with a vmkname.

Then you need to go to the pnic section and make sure that child 0000 is vmnic0 and child 0001 is vmnic1 and so on. Don't worry about the MAC addresses - they are correct. It's all in PCI address ascending order.

If you end up with more pnic childs than vmnics in the device section, these are orphans from ESX trying to remap things. I delete them. You should have one device instance per pnic "child" id, with the vmkname/name being the association between them.

When you experience this NIC ordering insanity as I have with DL380 G5s, you will also note that modules.conf is wrong. modules.conf is going to be used when you boot in linux mode.

For example:

alias eth0 e1000
alias eth1 e1000
alias eth2 e1000
alias eth3 e1000
alias eth4 bnx2
alias eth5 bnx2

In a nutshell, e1000 gets loaded first, even if the Broadcom NICs have lower PCI addresses. Change it to:

alias eth0 bnx2
alias eth1 bnx2
alias eth2 e1000
alias eth3 e1000
alias eth4 e1000
alias eth5 e1000

I'm still working on a script to reorder modules.conf in a portable and programmatic way, based on PCI order, and the device to module mappings.

If you are kickstarting via http or ftp, you may be scratching your head about connectivity. In the above example, where e1000 got loaded first by default, it was the same in the kernel on the ISO. (See for yourself - in esx text mode installation, ALT-F2 once anaconda installer is kicked off to enter the shell, and go ahead and 'more /tmp/modules.conf')

For the DL380 G5's with this issue, I had to ksdevice=eth4 in order to use my first onboard NIC (i.e. the first bnx2 device in modules.conf) for network installation. By the time we get to post-install and my little awk script runs, we are in the kernel installed on the disk, so we've made this right - vmnic0 and eth0 are where they are supposed to be. But you can't do anything about the boot image other than hack the module load order and make a new ISO (I've been tempted to...) We just noted in our build book that for our specific G5's use ksdevice=eth4.

You can implement the nic reordering scripts during the first boot. Because networking is broken at that point, retrieving scripts during POST is a no-go. So I like to inject files during pre-install from the kickstart:

%pre
# declare the deploy path
http_addr=http://<deploy_host>/scripts
# get the pre-install script
echo "* GETTING the pre-install script..."
wget $http_addr/scripts/pre-install.sh
echo "*"
# make a backup, create a new file, inject the http_addr variable from above
echo "* INJECTING the http deploy host URL to pre-install.sh..."
mv pre-install.sh pre-install.orig
echo "*"
echo http_addr=$http_addr > pre-install.sh
echo "*"
# append the rest of the script
cat ./pre-install.orig >> pre-install.sh
echo "*"
# make it executable
echo "* MAKING pre-install.sh executable..."
chmod 755 ./pre-install.sh
echo "*"
# so lets go
echo "* STARTING pre-install.sh..."
./pre-install.sh &
echo "*"

Attached is a vanilla version of my pre-install script.

It will install and cue up a post-install.sh of your design on second boot, after the NICs have been re-ordered.

Updated Nov29

I think the audience for this thread is clustered environments, where standardized and automated deployment is considered a requirement.

In order to deliver a consistent host install across varied hardware, you need to be absolutely sure of your NIC assignments. In a big company, many different people touch the various components of the system - one person is racking servers and patching things, another configuring switches, and yet another deploying the OS. Everything is documented, and fully tested beforehand.

I would agree that, if you only have one ESX box, you clearly aren't doing HA. And probably not looking for this thread. You'd most likely just swap the cables around or tinker with the file by hand, as you suggest.

My hope is that the community can benefit from the time I spent to solve this problem.

P.S. I also hope that editing my posts is not spamming everyone in the thread. This post editor is a little persnickety.

Allen -

Kudos on the script. I used it again last week to get out of a jam. The customer forgot to disable the onboard NICs before an install and the NICs got out of order. Incidentally, it also changed the order of the onboard SAS and the PCI QLogic adapters, not as big of a deal, but it would be nice to have a script to fix this as well... Same type of info in the esx.conf file.

Dave

************************
Accomplishing the impossible means only that the boss will add it to your regular duties.
Doug Larson

Version 2.0 of the script is now available. The article is here linuxdynasty and the download link is there as well. You must become a member to download and membership is free.
Once you run the script, then all you have to do is reboot and vmware will reorder the nics back in the correct order.

1- Added the verbose option to the script.

2- fixed the verious non updates of the esx.conf..
example below.....

./esx_nic_fix.py --verbose
Pre Sort
011:00.0
005:00.0
003:00.0
011:00.1
015:00.0

Post Sort
003:00.0
005:00.0
011:00.0
011:00.1
015:00.0
Original Line: /device/011:00.0/vmkname = "vmnic2"
New Line: /device/011:00.0/vmkname = "vmnic2"

Original Line: /device/005:00.0/vmkname = "vmnic0"
New Line: /device/005:00.0/vmkname = "vmnic1"

Original Line: /device/003:00.0/vmkname = "vmnic1"
New Line: /device/003:00.0/vmkname = "vmnic0"

Original Line: /device/011:00.1/vmkname = "vmnic3"
New Line: /device/011:00.1/vmkname = "vmnic3"

Original Line: /device/015:00.0/vmkname = "vmnic4"
New Line: /device/015:00.0/vmkname = "vmnic4"

The reason for the renaming with the script is for automation purposes. Especially in an environment when you have to kickstart many ESX hosts. If you are running ESX only on a few host, then you are write just log in to each one manually.

Will this script work on ESXi via RCLI? (Obviously not for the vswif NICs )