Haven't tested it at all, so can't say.

-Rich

If you DO run it from the unsupported mode on the ESXi server, it WILL change vswif0 as well.

After running the script, a reboot is required. The vswif0 reference could now potentially cause a disconnect if your vswif0 is not pointing to the first NIC on the PCI bus.

The intent here is for scripted installations where the NIC order is not what is expected and needs to be reset. I have seen this primarily on HP servers. It could be differences in the way isolinux kernel and the hypervisor kernel handles the PCI addresses.

Dave Convery
VMware vExpert 2009
http://www.dailyhypervisor.com

Careful. We don't want to learn from this.
Bill Watterson, "Calvin and Hobbes"

You're right Tom. It is weird too. I have it with the DL580 servers, but blades are OK. I did a deployment recently with 16 Dell R900 servers and had no problem with it. I include itin all deployments just in case now anyway. I think it has something to do with the way the kernel treats the addressing of internal components vs. slot components.

Dave Convery
VMware vExpert 2009
http://www.dailyhypervisor.com

Careful. We don't want to learn from this.
Bill Watterson, "Calvin and Hobbes"

You need to fix both esx.conf and modules.conf in order to complete the fix properly.

I used the attached scripts to achieve that.

If you run into problems, respond to thread and I'll post an update.

-
Richard Dagenais, VCP

It's funny that you say that because the impression I got is that you kinda resented that I posted an alternate solution to the problem.

I think its quite cool that you posted your script online, and that you've been actively maintaining it, and I've given you credit for that since my first post.

There are two reasons why I started from scratch on this problem after trying your much earlier script in the lab.

First, you used python which was not supported by any of our resources in-house. We decided to leverage bash, gawk/awk, sed - tools that were very supportable and consistent with the rest of the deployment script suite we were developing. Your original version was not working correctly in our environment and we couldn't debug it, so we figured the problem out on our own and wrote our own script.

Also, you ignored the modules.conf file which is necessary to complete the nic renumeration properly. Otherwise you are going to have a port assignment mismatch in linux boot mode and lose connectivity. Further, you would leave the system inconsistent with the way it is intended to be deployed by VMware and when you do a support call and run into that problem, support will poo-poo the script.

Since I am a VCP and my primary mandate is to make things as conform to standards of practice as possible, I could not leave out the modules.conf fix from my script suite. If you look at the code I shared here, you'll see that the modules.conf fix is quite a bit more fancy that the esx.conf renumeration script. It had to be, to interpret the driver tables and pick the correct one.

The script was made by myself and another expert; combined we have over 30 years of Unix experience. We felt strongly that this was a required part of the solution and spent the extra time for good reason. The client (Federal Gov't) agreed. We wanted a reliable fix, not a partial hack.

An important note here is that there is no reason why you can't use my modules.conf fix script with your own python script. The two stand alone.

I don't have a website which I am driving traffic to with this thread. I published the scripts on the VMware community to help out my colleagues, not to compete with you. I think there is plenty of room for different solutions to this problem. In fact, I think that having a little "competition" of sorts has driven you to improve your script greatly which can only be a positive thing all around for those who choose to use it.

Cheers!

-Richard Dagenais, VCP

Looking at a modules.conf file from a recent engagement, it looks like it MAY need to be edited. I am not sure if kudzu discovers the changes are re-orders the modules.conf file. I would have to try it the next time I come into the need to give a definite answer. I CAN say, however, that on the last engagement where I used it with different NICs, the server ran fine. I do not have a modules.conf file available from one where I actually ran the script. Like I said, I would assume that kudzu would handle the changes to modules.conf. Here's what I did last time:

kickstart install
reboot
ran python script on ESX console
reboot
Kudzu detects changes during boot up and reboots again
system comes up fine

Maybe someone can confirm this on their system? The latest engagement I am working is ALL e1000 NICs, so modules.conf does not NEED to be edited

Here's an output from a modules.conf file from an HP:

alias eth0 e1000
alias eth1 e1000
alias eth2 e1000
alias eth3 e1000
alias eth4 e1000
alias eth5 e1000
alias eth6 e1000
alias eth7 e1000
alias eth8 e1000
alias eth9 e1000
alias eth10 e1000
alias eth11 e1000
alias eth12 e1000
alias eth13 e1000
alias eth14 e1000
alias eth15 e1000
alias eth16 bnx2
alias eth17 bnx2

Dave Convery
VMware vExpert 2009
http://www.dailyhypervisor.com

Careful. We don't want to learn from this.
Bill Watterson, "Calvin and Hobbes"

It's important to note that modules.conf and esx.conf are two different problems, for two different boot states/kernels.

It's also important to note that the kernel in the installer has the same problem with NIC ordering, but that this is unique to that kernel and the driver loading order on the install image.

So there are three places you need to implement a workaround:

• By selecting a different adapter during kickstart;

• by re-ordering NICs during POST using either of the scripts in this thread, and;

• by reordering modules.conf.

We wrote the make-modules_conf script to address the latter, to get the bnx's in their appropriate spot, and this consistent with nic renumeration of esx.conf (i.e. always in PCI address order, consistent with Best Practices).

make-modules_conf achieves this by parsing the PCI IDs, the driver tables provided by vmware, and building modules.conf from scratch.

I'm not sure why I'm getting flamed for pointing this out, but modules.conf needs to be fixed in order for the nic re-ordering to be complete. Of course fixing esx.conf will resolve nic ordering while running vmnix, and that is what matters 99.9% of the time. But if you reboot in linux mode you lose connectivity. make-modules_conf is the only script I am aware of that currently fixes this issue, which is why I wanted to share it with the class.

-Richard Dagenais, VCP

Hello,

I downloaded the script and used it, it works great, however since i'm new to the whole ks and post script arena i would like to know how could i include this script in the %post section of my ks. I need to deploy more than 40 hosts in one night and i don't want to configure them manually. i jsut want to automate as much as possible. Thanks for your help!!

-- Ken