ESXi netwerk valt na 10 min uit

[DutchTSE]

Ik heb vorige week een server geleverd gekregen op basis van de Supermicro X8SIL-F moederbord, 8 GB geheugen en 2 harde schijven zonder raid.

Nadat ik in de bios de intel raid controller had geselecteerd installeerde ESXi zonder problemen. Ook de E1000 netwerk driver wordt zonder problemen geladen.

Echter loop ik nu tegen het probleem aan dat de netwerkverbinding (zowel van de management console als van de virtuele servers die op de server draaien) na 10 minuten uitvalt. Nadat ik het netwerk herstart (in management console) werkt het netwerk weer, de VM's moet ik apart netwerk herstarten. Ik heb het idee dat de netwerkkaart "in slaap valt" en met een restart weer wakker wordt gemaakt. Dit wordt ook bevestigd als ik via een cronjob elke 5 minuten een ping commando draai, dan vallen de virtuele servers niet in slaap (ESXi ondersteund geen cronjob en daarmee kan ik het dus niet oplossen).

Ik heb zo ongeveer alle ACPI instellingen al getest, en andere stroombesparende technieken in de bios op disabled gezet maar het probleem blijft bestaan. Ook uitschakelen in ESXi zelf heeft geen nut.

(in de bios staat Intel Turbo Boost ook op disabled, wanneer dit aan staat kan er uberhaupt geen netwerkverbinding gemaakt worden).

Andere interessante feitjes:
- Geen TX/RX errors op de netwerkkaarten
- Er is helemaal NIETS te zien in de system logs van ESXi, zelfs niet dat een link down gaat/up komt.
- 1 iemand op heel internet met hetzelfde probleem: http://www.bluequartz.us/phpBB2/view...16d1f58787183c
Deze oplossing werkte niet voor mij (Ik kan de ACPI opties op disabled zetten, maar ACPI 1.0 is de laagste die ik kan selecteren. Ik heb via ESXi alle power management uitgezet maar het probleem blijft.)
- ESXi is helemaal up2date, ook de driver update voor e1000 netwerkkaarten is geinstalleerd.


Wie heeft het verlossende antwoord?

[pierce]

Alle updates geinstalleerd van ESXi?

[DutchTSE]

Alle updates geinstalleerd van ESXi?

Shit, dat punt stond in mijn interessante feiten lijstje, maar is verloren gegaan zo te zien

Ja alle updates zijn geinstalleerd, en ook de driver update voor de e1000 netwerkkaarten zijn geinstalleerd.

[pierce]

Ik dacht al iets te missen
Welke versie van ESXi draai je trouwens?

[DutchTSE]

Ik dacht al iets te missen
Welke versie van ESXi draai je trouwens?

ESXi 4.0.0 ReleaseBuild-193498 (= version 4.0.0 build 171294 welke beschikbaar is op de vmware site + de 5 patches die aangeboden worden via de host update utility)

[pierce]

Al een andere NIC geprobeerd, bijvoorkeur pci-e kaartje oid?

[DutchTSE]

Al een andere NIC geprobeerd, bijvoorkeur pci-e kaartje oid?

Server hangt in DC, dat is het hele probleem, heb dus alleen IPMI tot me beschikking.

Als ik handmatig binnen iedere 10 minuten een ping naar de gateway stuurt blijft het netwerk uren lang vrolijk doordraaien, maar zodra ik daarmee stop valt het netwerk na 10 minuten uit. De workaround is dus beschikbaar, maar heb het liever gewoon gefixt voor hij in productie gaat.

De nics staan ook gewoon op de supported lijst van vmware (825XXX) dus daar zie ik ook geen problemen.

[pierce]

Dat snap ik Maar als het een (tijdelijke) oplossing is...
Heb je al contact gehad met Supermicro hierover? Klinkt als een probleem van de onboard NIC..., al dan niet een verkeerde firmware oid.

[DutchTSE]

Dat snap ik Maar als het een (tijdelijke) oplossing is...
Heb je al contact gehad met Supermicro hierover? Klinkt als een probleem van de onboard NIC..., al dan niet een verkeerde firmware oid.

Tijdelijk of niet.. zodra de echte oplossing er zou zijn betekend dat weer downtime voor de klant. Dan wacht ik liever een paar uur/dag met opleveren. Verder is het een beetje een probleem dat ESXi geen cronjobs ondersteund, de management console valt dus uit OF ik moet remote een cronjob draaien die een verbinding naar de console maakt, commando uitvoert en uitlogt... niet echt een standaard oplossing

Onze leverancier heeft het probleem net na de topicstart geforward naar Supermicro. Afwachten dus.

[pierce]

Verder is het een beetje een probleem dat ESXi geen cronjobs ondersteund, de management console valt dus uit OF ik moet remote een cronjob draaien die een verbinding naar de console maakt, commando uitvoert en uitlogt... niet echt een standaard oplossing

http://www.google.nl/search?hl=nl&q=cronjob+esxi

[DutchTSE]

http://www.google.nl/search?hl=nl&q=cronjob+esxi

Heb duidelijk niet verder gekeken dan de 1e hit in google wat betreft deze workaround i'm sorry.

De 2e hit werkt ook niet.. de cronjob file is read only Verder zoeken gaat..

[DutchTSE]

Ik ben al iets verder in mijn tocht naar de oplossing.. het probleem ligt waarschijnlijk aan het punt dat de E1000 driver, in combinatie met ESXi, geen ARP uitzend, en dus na 10 minuten (de ARP timeout) zijn verbinding verliest. Ook de virtuele machines zenden geen ARP uit en hebben dus hetzelfde probleem.

[DutchTSE]

Maar even een update voor als iemand hier via google terecht komt:

Het is inderdaad een bug in de ESX(i) driver voor de E1000 netwerk kaart. Deze driver blokkeert ARP pakketjes op de 1e interface maar niet op de 2e interface. Wij hadden dit in 1e instantie opgelost door zowel de ESXi zelf als de virtuele machines iedere 5 minuten te laten pingen naar de gateway om zo de ARP cache actief te houden. Helaas bleek dat bij het toevoegen van een 2e IP aan dezelfde interface dit IP niet bereikbaar was, omdat de ping vanaf het 1e IP komt. Pingen vanaf het 2e IP naar de gateway loste dit probleem ook niet op.

Zoals ik al aangaf speelt het probleem alleen op de 1e interface. Wij hebben gisteren door wat te schuiven met vlans de kabels omgewisseld en frontend in de 2e lan poort gestoken. Een tcpdump in de niet-werkende situatie liet 1 ARP aanvraag per 5 minuten zien, de wel-werkende situatie liet vele ARP aanvragen per seconde (namelijk van het hele subnet, want broadcast) zien. Ook viel het netwerk na 10 minuten niet meer uit.

Wij laten vandaag de kabels fysiek omwisselen en gaan dan verder met testen. Het nadeel van dit probleem is dat de 1e lan poort dus onbruikbaar wordt voor "gateway verkeer". Nu is dat voor ons geen probleem omdat er enkel intern verkeer over de poort gaat.

Er blijkt voor ESX(i) 4.0 geen juiste driver beschikbaar te zijn. Deze bug heeft zich ook voorgedaan in andere linux distro's maar is daar al een hele tijd geleden gepatcht.

[The-BosS]

Bestaat er geen manier om de driver manueel te compilen en te installeren op je ESX, dan moet je niet wachten op updates van vmware. Ik heb tijd geleden ook zo iets gelijkaardigs tegen gekomen, alleen ging de nic in reboot mode (disconnect, connect) bij verkeer hoger dan ssh of icmp. Dit hebben we opgelost door een extra pci netwerkaart te gebruiken.

[DutchTSE]

Bestaat er geen manier om de driver manueel te compilen en te installeren op je ESX, dan moet je niet wachten op updates van vmware. Ik heb tijd geleden ook zo iets gelijkaardigs tegen gekomen, alleen ging de nic in reboot mode (disconnect, connect) bij verkeer hoger dan ssh of icmp. Dit hebben we opgelost door een extra pci netwerkaart te gebruiken.

Ik heb even gezocht naar de mogelijkheid om zelf te compilen, maar dit is volgens mij niet mogelijk in ESXi. Verder ontbreekt de kennis om de driver zo aan te passen dat het wel werkt (simpelweg de driver source downloaden en die patchen met de beschikbare patch gaat niet werken).

Inmiddels zijn de kabels omgewisseld, ESXi geconfigureerd en ik heb nu al een half uur een ondoorbroken ping op zowel frontend (nu poort 2) als backup netwerk. Voordeel van het backup netwerk is dat het verkeer niet langs de gateway hoeft en er dus geen ARP issues zijn.