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