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]>
Bill,

In your VMware two-NIC scenario where you are chainloading gPXE from the
PXE ROM code provided by the VM itself natively:

You wondered about the address 15ad:0720.  I believe that those are the
PCI VENdor and DEVice IDs for both NICs.  My possibly-incorrect guess is
that this collision is what causes both NICs to use the UNDI driver for
the second NIC only, since its PXE ROM code is found last.

Are you serious in that undionly.kpxe and/or undionly.kkpxe shows _no_
adapters from 'ifstat'?  This is hard to believe.

Ah yes, concerning iSCSI best practices of having one adapter for iSCSI
and the other for all other traffic: I'd totally forgotten about this
best practice, but it makes perfect sense.  In your situation, I think
you've said that you don't want the choice of which adapter does which
to be too difficult to change.

You might be interested in the information available at
http://etherboot.org/wiki/appnotes/port_winnt_sanboot.  You can
pre-populate every "slot" in the VM with a NIC, install them all in
Windows, make sure the appropriate services are set to boot-start, then
any one of the adapters should allow you to boot, though I'd recommend
installing Michael Brown's sanbootconf package to help out with such.
If you're not using a VM in production, you can similarly pre-populate
every slot; as long as you have two of the NICs, you boot from one with
the other in a new slot for each boot.

- 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.