Follow me!

LinkedIn Twitter

Port Report News Letter

Subscribe to this news letter if you want to be kept up2date on the newest updates on the Port Report Project.
Port Report Project


Receive HTML?
Thank you for subscribing to the Port Report Project News Letter.

Newest Downloads

calendar.gifJun.26

This program will create a host up/down report from nagios.log

calendar.gifMay.22

This Script will list all Virtual Machines in an ESX Server... Example below.. python listVMsInf...

calendar.gifMay.08

I'm really excited to introduce Port Report Update 1.9 aka the Switch Port Mapper Tool. We've...

calendar.gifMay.04

Here is a quick update..... I just add dns reverse lookups to the output of this script.. So if ...

Script to fix VMWare ESX 3.5 NIC Reordering after kickstart
Virtualization - VMware
Written by Allen Sanabria   
Thursday, 19 June 2008 21:07

Once we moved to VMWare ESX 3.+ we ran into a very annoying issue. The issue was that if you have multiple NICs from Multiple vendors, VMWare will reorder your NICs and cause havoc to you guys who use PXE boot/Kickstart. So I had to come with a work around that will alleviate this issue. I went ahead and created this script and I injected it in the post section of our kickstart profile and had it run after rebooting 3 times. Since After the third reboot the VMWare is done with its configuration, after the third reboot the script will run and then delete itself. Once all said and done your NICs will be in the proper order.

Some of you might just use it as a once shot deal manually and some of you might use it as I did, but I did not realize how many f you are having the same issue as I did. Since I posted this script it has ad close to 3000 hits. So for those of you who have used it and appreciated the work I have done or for those of you who have modified it and added to it. Please leave some feed back weather in the form of comments or in the forums.

Could you believe that VMWare says that a feature of there software will reorder your NICs after the kickstart???
So if this was the order of our NICS
03:02.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
03:02.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
eth0 == 03:02.0
eth1 == 03:02.1
When VMWare comes up it will reorder them so that vmnic0 will point to 03:02:01 when it should be 03:02:00 Now this only happens when you have a box with multiple nics from multiple vendors. This script will take care of it for you.

Here are some instructions on how to run this script and what you should do before and after you run this script on your ESX Server..

  1. run esxcfg-nics -l   (keep the ouput so you can compare it to the new ouput after the script has done its job)
  2. copy this script in any directory you want... for instance  ( /tmp/esx_nic_fix.py )
  3. Reboot your ESX server and once it comes up ESXwill reboot again to apply the nic changes.
  4. run esxcfg-nics -l and compare the new output to the old output.... ( The order should be correct now ).
  5. Leave me a comment on how my script helped you and digg this article. ( I would appreciate it ).

 

You can download the Script here, but you must become a member first before you download. Membership is free



Add this page to your favorite Social Bookmarking websites
Reddit! Del.icio.us! Mixx! Free and Open Source Software News Google! Live! Facebook! StumbleUpon! Yahoo! Free Joomla PHP extensions, software, information and tutorials.
Comments
Search RSS
dynasty     |SAdministrator |2008-06-19 08:24:20
Sorry guys, for not fixing the script sooner, as I just found a bug the other
day. The script will now work with all HEX conversions.
William   |75.83.202.xxx |2008-07-01 11:18:33
Can this be integrated after the kickstart to re-order the NIC before the
vmkmodules are loaded?
Anonymous   |70.15.55.xxx |2008-07-01 11:24:37
The way we made this work was to put this script in rc.local (during the post of
the kickstart process) and count the reboots and once the reboot were equal to 4
we would clear out rc.local and then the box will come up correctly.

We tested
this back and forth for over a week.
Anonymous2   |76.174.124.xxx |2008-07-10 19:43:59
Does not seem to work on ESX 3.5U1
dynasty     |SAdministrator |2008-07-11 02:24:20
Weird, we are running 3.5 here and this works for all of our HP/BM Servers...
Maybe the way I'm translating the PCI ID is off could you show me the order that
vmware sees your nics and what is there PCI ID. esxcfg-nics -l.

Let me know I
would like to help you fix this issue.
dynasty   |SAdministrator |2008-07-14 05:49:16
I just ran into the issue on one of my boxes the fix is now in.. Try it and let
me know.
Rick Parker  - Will this work with ESXi (3.5)?   |216.41.41.xxx |2008-07-28 06:12:08
Saw your postings and we are having a (what we thought) was a unique issue.
We
make a highly redundant and fault tolerant VM appliance and found that we need
to purchase a NIC bypass card for when the ESX server went totatlly down.
What
we found was that after manufacturing built the boxes and sent them out,
customers were seeing strange things. Namely they would have their ethernets
plugged in and we found that they had their physical NICs reordered so that the
2 motherboard NICs were named for the 1 vm on the box.
Will this script fix
that? and how to install on the boxes?
Thanks,
Rick
dynasty   |SAdministrator |2008-07-28 06:34:21
This script will fix the NIC reordering issue. Once you run this script
and
reboot your ESX server, ESX will see the change and reboot again. This time
to apply the changes that the script made.

I and others who have used my
script
usually use it as part of the post kickstart section or in the
rc.local
file.

You can use this script manually as well. Just copy this script
to your
server and run it as root like this... python script_name.py.

Before
you run this script I suggest that you run esxcfg-nics -l to see your current
output and then run python script_name.py then reboot. Once ESX server is back
up rerun esxcfg-nics -l and compare the differences.
radagenais  - HP DL380 G5 - doesn't work *cries*   |Registered |2008-11-26 16:30:31
We implemented this script on an HP DL380 G5 platform with on-board bnx2
(Broadcom) and HP PCIe e1000 (Intel) NICs. The reordering doesn't happen.

I can
manually fix the order by making sure that esx.conf and modules.conf reflect the
correct nic order. See a diff below. Problem: we are a kickstart site so we need
networking to work automatically after deployment. Manual fix isn't an
option.

I currently inject the esx_nic_fix.py to the filesystem during %PRE in
kickstart. I call it via rc.local, making a backup first, stage a new rc.local
for second boot which runs my post-install script. Reboots automatically after
services have finished loading.

(BTW I have to ksdevice=eth4 on install boot
because the reordering is wrong from the get-go. No biggie..)

(cont'd)
pharoah   |Registered |2009-02-11 06:23:54
I have a DL380 G5 with the same Broadcome and Intel NICs.

Have not tried the
script yet. Is the problem resolved?

Thanks!

Liz
dynasty  - re:   |SAdministrator |2009-02-12 02:55:01
pharoah wrote:
I have a DL380 G5 with the same Broadcome and Intel NICs.

Have not tried
the script yet. Is the problem resolved?

Thanks!

Liz


Please go ahead and try the script and see if it works. The above issue
has only happen to one person so far as I have yet to see anyone
else complain.

I'm currently working with the dl380's in my new job
and we have both intel and broadcom and the script works just fine.

For
those of you who have found a bug please post with the esxcfg-nics -l
and the esx.conf and I will help debug but please post as an attachment.
dynasty   |SAdministrator |2009-02-12 10:04:15
OK, I found a bug today and the fix is is uploaded.

Lets me know if it works
guys..
radagenais   |Registered |2009-02-14 12:13:33
This script I got a friend to write for me is tested in a large government
production environment. I did literally hundreds of deploys and I
trust it.

I couldn't get it to post cleanly here so check the link on
VMware Communities.

Also, you are going to want to fix your
modules.conf, which this python script doesn't do. See link for that code
too.

http://communities.vmware.com/message/1111328#1...

Code:

#!/usr/bin/gawk -f
/vmkname = "vmnic[0-9]*"/
{ gsub("vmnic[0-9]*",sprintf("vmnic%d 4;,a)); a++

}
/^\/net\/pnic\/child\[[0-9]* \]\/name =/
{ gsub("vmnic[0-9]*",sprintf("vmnic%d 4;,b));
b++}
{print}
dynasty   |SAdministrator |2009-02-14 12:50:10
Hey thanks for the update. My script was ran at a bank that I previously worked
at around a few hundred deployments.

Also I still do not see the reason for the
modules.conf as I have yet have not a need to do that. At my previous job we did
not have t do that and at my current job we do not have to do that
either.

Might be the way your environment is setup.
radagenais   |Registered |2009-02-14 13:47:42
If you reboot in recovery mode you are going to need those NICs to line up with
modules.conf. If you didn't have those lined up, you would find VMware support
would have words for you.

Richard Dagenais, VCP
dynasty   |SAdministrator |2009-02-14 14:00:31
Ahh, I understand now, thanks for the advice. Though I never had to call
support.
chiupf   |Registered |2009-02-26 11:43:21
Is the new version 1.1? Or is there another version out there? I'm still having
problems with the hex numbers (f.0.0) coming up before my 3.0.0!
dynasty  - re:   |SAdministrator |2009-02-26 16:13:17
chiupf wrote:
Is the new version 1.1? Or is there another version out there? I'm still
having problems with the hex numbers (f.0.0) coming up before my 3.0.0!


The last update was 2 weeks ago. Did you download that one? I have not
seen any more issues since with the hex conversion since the
update. but if you still have it after downloading please let me know
and post the output of esxcfg-nics -l in the forumns
dynasty   |SAdministrator |2009-03-14 08:00:28
Version 2.0 has been released and I am happy to say, all previous issues have
been fixed as well as the verbose flag has been added.
kevinc  - What am I missing?     |Registered |2009-03-18 04:20:00
Hey Dynasty, great to see this script.

Am I missing somethign obvious here
and being a fool?

I downloaded your script and saved it to script.py.
I ran it with
#(root) python script.py
then I rebooted my DL385 G2 (ESX
3.5 U3, fully patched, twice:

Here's the output from my esxcfg-nics
-l command, it look the same now after two reboots as it did before:

Code:
Name    PCI      Driver      Link Speed    Duplex MTU   
Description

vmnic3 420.00 bnx2  Up 1000Mbps Full 1500
Broadcom Corporation Broadcom NetXtreme II BCM5708 1000Base-T
vmnic1
 080.00 e1000 Up 1000Mbps Full 1500  Intel Corporation
82571EB Gigabit Ethernet Controller
vmnic2 080.01 e1000 Up
 1000Mbps Full 1500 Intel Corporation 82571EB Gigabit Ethernet
Controller
vmnic0 040.00 bnx2   Up 1000Mbps Full 1500
Broadcom Corporation Bro...
dynasty  - What am I missing?     |SAdministrator |2009-03-18 04:10:02
hey Keith, please post this in the forums http://linuxdynasty.org/phpBB3/viewforum.php?f=3.
when you run the script could you run it with the --verbose option
please.

Also from looking at your PCI ID's they look to be in the right
order.
xperttech  - %pre or %post kickstart injection   |Registered |2009-06-14 09:12:54
Hello,

Does anyone have a script that will inject the esx_nic_fix.py and
count the reboots before the %post commands continue with the vSwitch
creation?

Thanks!

btw. I have manually ran the script on an IBM Blade HS21
with 8 nics and it worked!

XT
Only registered users can write comments!

3.22 Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved."

Last Updated on Wednesday, 08 October 2008 07:04