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

Shao:

Since you were incredulous on the undionly scenario not working, I
decided to try documenting it and found that I had built it incorrectly
the first time.   If I build it correctly it works.

The first time I tried it, I had typed "make bin/undionly.pxe".   If you
try to boot using that executable, you get the following console output:


---------------------------------------------------------------------
PXE 0.9.7+ -- Open Source Boot Firmware -- http://etherboot.org

Features: HTTP DNS TFTP AoE iSCSI bzImage COMBOOT ELF Multiboot PXE
PXEXT

No more network devices
---------------------------------------------------------------------

But, if I build it correctly "make bin/undionly.kpxe", then it
eliminates that error and proceeds with the UNDI boot.



Unfortunately, now that I have gotten past one problem, I'm encountering
another.   I've got to do more testing to understand whether it is
isolated or not.

On my test machine for UNDI, I didn't actually have an OS installed.   I
was trying to get past the DHCP stage and figured things would be fine
if it was able to load the script.    It is built with the enhanced
VMXNET drivers and seems to be able to acquire a network address and
download the gPXE script file.   It fails after that because I didn't
specify a target.

Instead of cloning another system, I thought I would just change the
chainloaded bootimage of gPXE on an already working system to see if it
boots correctly.    That system is configured with the Flexible NIC that
emulates a PCNET32 NIC and switches to a VMXNET NIC if "VMWare tools" is
installed.    On this 2nd test system with the UNDIONLY version of gpxe,
it has a terrible time booting and never gets past the script load
phase.   Sometimes it times out trying to acquire an IP Address,
sometimes it gets past that phase and times out when trying to do an
http: load of the gPXE script.

The main difference between these two systems is the different NIC
although there are differences in the amount of RAM and the number of
CPUs.   So, I'm now going to try building a Windows Guest with the
Enhanced VMXNET NICs and see if UNDIONLY will work with it.   Since I
already have non-UNDI Variations that work for the flexible adapter, I'm
OK if UNDI doesn't work with it.   I'll be more worried if it doesn't
work with the E1000 NIC of VMWare.   Even though I have a solution for
the E1000/gPXE boot already, having UNDI fail on two different VMWare
NICs may be an indication that it could easily stop working for the
Enhanced VMXNET adapter if VMWare updates something.

I'll let you know how my tests of using UNDIONLY for the enhanced VMXNET
and E1000 adapters go.

As far as the pre-popularing a virtual machine with lots of adapters
goes, it doesn't help much in the pure Windows Server 2003 scenario
because the software iSCSI boot initiator from Microsoft requires me to
select which adapter will be used for booting.   I can't choose them all
and let windows figure it out.   Perhaps that issue goes away with
sanbootconf.   Even if it does, it seems like I'll have other unforeseen
headaches and confusion with a bunch of unused adapters out there.

Fortunately, I don't have to go that direction since I was able to get
the UNDIONLY version working.

I'd like some clarification on the difference between building a image
with .kpxe vs .pxe as an extension.   I have been building the other
chainloaded gPXE images for the PCNET32 and E1000 drivers with a .pxe
extension.

Thanks again Shao...

Bill


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