Re: multiple UNDI NICs in VMWare ESX 3.5 cause gPXEDHCP to fail on 1st NIC

"Miller, Shao" <[email protected]>
Newsgroups gmane.network.etherboot.user
Message-ID <[email protected]>
Good day Bill,

In regards to your two-NIC scenario's trouble using a gPXE build
including only the UNDI driver:

It looks to me like gPXE scans for PXE ROM code.  It finds the code for
NIC #1.  It registers an instance of the UNDI driver which will use the
UNDI provided by NIC #1 for adapters with the PCI VENdor and DEVice
codes listed in your debugging output.

It then continues to scan for PXE ROM code and finds the ROM for NIC #2.
It registers an instance of the UNDI driver which will use the UNDI
provided by NIC #2 for adapters with the PCI VENdor and DEVice codes
listed in your debugging output.

The second instance has registered to handle the same PCI codes as the
first instance, so it overrides the first instance.

When gPXE tries to use the second instance to actually talk to the first
NIC, gPXE is actually asking the PXE ROM on NIC #2 to handle NIC #1,
which, of course, it's not intelligent enough to do.  A proper gPXE
driver would be, but a common, vendor-provided PXE ROM is unlikely to
anticipate/support this, even if the other NIC is the same type.

I'm not too sure why you'd want to use NIC #1 when you already are doing
some management/control by allowing to PXE-boot NIC #2, but it's not
unreasonable, by any means.  It's a limitation of VMware's PXE ROM code,
in a way.  A proper gPXE driver for that NIC would be the best bet.
Another possible solution would be to associate the particular PXE ROM
code with the appropriate adapter, but I'm not sure that this is
supported/allowed by the PXE specification.  A more informed developer
could likely comment on this.  If only PCI VENdor and DEVice codes are
passed along, this would seem to be a fundamental limitation.  If slot,
function or some other parameters were available, this might very well
be possible for gPXE to work with.

If both NICs are on the same network for some kind of fault-tolerance,
and the cable in NIC #1 is faulty, the PXE-boot for NIC #2 should be
successful, and you'd want to use it anyway.  Perhaps that's not your
aim, though.

Does any of this make sense?

- Shao Miller

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.