Thanks for your reply.
i have another ESXi 4. instllation. This one uses Tyan motherboard with 2 networks ports working no problem. Actually using Intel NIC.
The only problem is that in Tyan motherboard the second embeded NIC had stopped working anyway. Even if installing an O/S directly on the machine (without virtualization) wouldn't work.
By installing a second NIC Esxi sees both NICs.
Having said that it is possible that ESxi can't see the second NIC when it already has installed the same driver.
The question is would the second NIC be recognised if a standard O/S is installed or Microsoft VM is installed?
Hope you had a good break.
Unfortunately mine was taken up mainly by testing this motherboard. At least 4 days of testing.
Here are my results.
Before anything else i downloaded and installed the latest version of the firmware and deployment tool.
1) Boot up through set up is exteremly slow! Why?
2) Installing Window 2008- OS recognises only one NIC. The second NIC has to be installed manually but the latest NIC installation program fails with an error of not finding a file. Even though partially installed the set up didn't roll back the installation. Looking as though it was installed correctly!
3) Window 2003. OS didn't recognised any of the NIC.
4) VMware ESxi 4.0 recognised only one NIC.
5) Embedded software RAID even though installs and can be configured through depolyment yet for some reason presents the RAID drive as two OSs (ESXi) instead of one.
6) Could not override the onboard SATA controller to use another (Adaptec) SATA raid controller.
7) NICs latest release note indicates that it might crash or hang the system! Which it does hang the system.
OK, Intel channel has been pushing the SR1630GP, and the S3420GP board in their partnership with VMWare, its listed as 'certified in Q4'.. realizing there are a few more days, I have been pretty patient. Worked through VMWare in November trying to identify the issue, they said to 'talk to Intel', and have been trying to do that for some time. Have a ticket open with them, and the latest
reference http://communities.vmware.com/message/1429153#1429153 on this one, you can see that even patch ESX4update1 doesnt recognize the pci-id of the second controller, modifying the database still doesn't make it work properly. This is an issue with the e1000 drivers, I have the newest installed, and they don't recognize that controller...
[root@esx-production1 updates]# rpm -q -a | grep e100
Its quite frustrating that the distributors are pushing the VMWare-Intel alliance, and the blue-box servers for VMware, and its not working. The tech at Intel I just talked to said that the platform is certified, just that the second interface is not supported. I would not call this support, certified, etc. I have asked to talk to a manager to see if perhaps they are unaware how fully they are pushing this alliance, and yet have their main entry platform not being fully supported.
The ESX driver is of course based off the Intel Linux drivers, and and update is likely all that is needed.
Not sure where my reply went to, but its an issue that the second controller is not recognized by the version of the Intel e1000 driver that is in ESX 4.. even the most up to date patch update01a.
Intel and VMware are pushing this platform big time, and I have a ticket open re: this issue, hoping to get a knowledgeable response. The mainstream version of the Intel driver in RHEL recognizes it with no problem, so obviously just an issue to get the version ESX driver up to date.
[root@esx-production1 updates]# lspci
00:00.0 Host bridge: Intel Corporation Unknown device d130 (rev 11)
00:05.0 PCI bridge: Intel Corporation Unknown device d13a (rev 11)
00:08.0 System peripheral: Intel Corporation Unknown device d155 (rev 11)
00:08.1 System peripheral: Intel Corporation Unknown device d156 (rev 11)
00:08.2 System peripheral: Intel Corporation Unknown device d157 (rev 11)
00:08.3 System peripheral: Intel Corporation Unknown device d158 (rev 11)
00:10.0 System peripheral: Intel Corporation Unknown device d150 (rev 11)
00:10.1 System peripheral: Intel Corporation Unknown device d151 (rev 11)
00:19.0 Ethernet controller: Intel Corporation Unknown device 10ef (rev 05)
Thanks for the update.
Actually i have another box with ESXi 4 using a Tyan motherboard. It has 2 network ports working. ESXi sees it as E1000.
It seems the Tyan motherboard also has problems with 2 embedded NIC. But i can't say for sure as one of the networks port doesn't work any longer regardless of what is installed on it.
So i installed a PCI NIC adapter.
The other major problem is the embedded RAID which doesn't work correctly either.
Also the server hangs probably because of NIC as per release note.
All in all,
1) The NIC doesn't work correctly.
2) The RAID doesn't work.
3) The system hangs.
Makes me wonder.
Hi ChkNet -
What model Tyan board are you using. The SR1640GP and SR1630HGP are Intel barebone servers that comes with the Intel; S3420GPLC motherboard, this board has the intel 3420 chipset, and for some reason 2 different Intel network chipsets - the Intel 82574L and 82578DM, the latter seems to be the one that is recognized, and the former not. On your ESX box, can you do an lspci ?
for instance on the SR1630GP..
[root@esx-production1 ~]# lspci | grep -i ethernet
00:19.0 Ethernet controller: Intel Corporation Unknown device 10ef (rev 05)
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
You can see it finds the 82574L controller, but we make the assumption that the unknown ethernet controller is the
82578DM. We can code so that the ID is associated with the driver (see metomw post at http://communities.vmware.com/message/1429153#1429153 )... but its still not working.
Now the version of the intel driver that is running on RHEL 5 has no problem with both ethernets.
[root@mx1 src]# modinfo e1000e
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <email@example.com>
I don't know what version of the driver corrresponds to the version that is installed in ESX, the version numbers of the RPMS in ESX don't correspond...
[root@esx-production1 ~]# rpm -q -a | grep e100
but I assume its just not new enough.
This is very frustrating because Intel in cooperation with VMware have a big push for resellers, incentives, etc., and have listed this server/board as pending certification, and after almost 2 months of inquiry, the official response seems to be 'certified except for the second ethernet board'.
I have used the older intel socket 775 boxes, which this was supposed to replace for a long time, and we use a hardware RAID card, so don't have the option of adding in a controller... but the assumption would have been that the officially supported platform, the flagship, albeit the entry-level one, in a combined VMWare-Intel push, including incentives would be fully supported. I'm not taking the answer just yet, but if that's the case, I have a bunch of 2 month old SR1630GP's that will be getting returned for credit. Someone who is involve in the marketing push needs to get wind that they are pushing a product that's not fully supported.
Meantime, let me know what model you have, what your lspci results are.. BTW, I never made software RAID run on ESX.
Something else I noticed - the second NIC is an Intel 82578DM Gigabit Network Connection, which
says is not supported.
This requires further investigation.
You are right it is very frustating. For a small software company like us time is very precious and we have lost a lot of time over testing this motherboard.
My understanding is that SR1630GP was VMWare certified in Q4 not just pending.
You might need to click on motherboards certified.
When they certify a motherboard to work with VMWare then at least my assumption is that the fundementals should work. For a server motherboard, where resiliency is so important, to have its second network port not working and then they pass its certificates is a poor judgement on whoever issued the certitifcate. i certainly wouldn't have bought this motherboard if i knew the second network port was not working. my tests with MS 2003 and 2008 shows the NICs don't work with them either.
The worse problem is the system hanging as per Intel's release notes.
i am not trying to rub it in but the Tyan motherboard is an old motherboard i am not sure if they even sell it any more. It has been working fualtlessly for so long i haven't had to touch it or restart it for at lease a year. Even then it was for memory/firmware upgrade. i will try to find out the model and post it to you later.
Just going by memory, i think the Tyan motherboard is based on 82574 so what i did was to buy an Intel NIC with the same chip set just to keep ESXi happy. Both ports work fine no problems.
Actually i too was wondering why SR1630GP has two network chipsets? With 82578DM not supported as per Dan's response.
Makes me wonder why was the certificate ever passed ?
i will be requesting a refund but don't wish to be unduly unfair to our supplier after all it is not their fault. If at all possible we will keep the chasis and just change the motherboard.
Sorry Intel but Tyan S7002WGM2NR-LE looks pretty good.
Thanks for your posts Michael.
Tyan motherboard was Toledo i965R S5180. We got this for testing purposes but with the new firmware (with 4GB RAM) it became a nice little low cost server in its own right. It actually has 4 Win 2003s running on it.
It has been working 24/7 for a long time.
Just to save time.
Tomorrow i will be returning our SR1630GP and try to install ESXi 4 on Intels SR1630BC. This one was certified pre-Q4. So hopefully would have ironed out any problems by now. Will let you know if it works.
i am not sure if Intel would insert a dual NIC card to obtain the certificate only then to remove it afterwards.
It would be mis-representing their product.
My guess is that becuse Intel has invested in VMWare someone somewhere has allowed this certificate to pass through
without testing it proproly.
My humble suggestion to both Intel and VMWare is that certification procedures should be done by an independent department
autonomous from any marketing or investment issues. Serious mistakes like this could potentially damage their brand name.