Zeer regelmatig kom ik de volgende meldingen tegen in vCenter (5.0) die ik niet kan verklaren:

Het lijkt op willekeurige momenten te gebeuren. Niet specifiek tijdens vMotions, of SvMotions. Alle hosts lijken er last van te hebben, naar alle mogelijke vmfs volumes op het SAN. Tot op heden zie ik er geen patroon in. Er lopen op dat moment ook geen replicaties op het SAN of backup jobs.

Situatie:
MER1: 2 hosts, ESXi 5.0 (4 * 1Gbit / host), via dedicated iSCSI switches (stack) geconnect naar 4 node Equallogic iSCSI SAN
MER2: 2 hosts, ESXI 5.0 (4 * 1Gbit / host), dedicated iSCSI switches (stack) met een 10 Gbit etherchannel naar de switches in MER1

Afstand tussen MER1 en MER2 is ongeveer 500 meter over glas.

Iemand een goed idee in welke richting ik moet moet/kan zoeken?

Altijd lastig dit soort problemen. Ik zou omdat je gebruik maakt van ISCSI beginnen te zoeken naar Duplex settings/ Nic drivers versie/ Multipathing issues etc. succes!

O, en de "flow control" optie op de fysieke switch, schoot me nog te binnen, als die aan slaat gooit ie volgens mij ook een switchpoort dicht.

flow control en switchpoorten dichtgooien
Denk dat je ergens iets door elkaar haalt.

In een non blocking en omgeving heb je geen flow control nodig, dan is het het beste om deze uit te zetten (alhoewel het dan theoretisch niet uitmaakt).
Anders kun je deze het beste aanzetten, helemaal wanneer er een hogere latency meespeeld (bijv. door geografische afstand).

Uit jouw gegevens haal ik dat je (max) 8Gbit (2x4x1) iSCSI verkeer over 10Gbit uplink op een dedicated switch met daarop nog eens 8 Gbit (2x4x2) naar een EQL SAN hebt. Ik weet niet welk model maar als het bijv. een PS6000 is dan heb je daar max 4Gbit op, in dat geval is je storage dus mogelijk blocked.

Er zijn veel switches die de combinatie jumbo (4k/8k) en flow control niet lekker verwerken (te kleine buffer groote).

Ach, flow control is performance gerelateerd. Ik denk dat Spanning tree hier beter op zijn plaats is. Ook even goed naar teaming en failover instellingen kijken.

Flow control is NIET performance gerelateerd, het moet alleen re-ordening tegengaan door packetloss bij volgelopen buffers.
Spanning tree lijkt mij geen issue op een een dedicated iSCSI netwerk.
Met iSCSI verkeer is het nooit verstandig gebruik te maken van teaming, dat doe je altijd door (native in het protocol) gebruik te maken van multi path.

Het kan wel verstandig zijn even je vSwitches en initiators op je hosts na te lopen of deze wel correct staan ingesteld. Hier heeft EQL (Dell) best practices voor op hun site.

Beetje laat antwoord:
Alles is ingericht volgens het best practices document van Dell Equallogic icm vSphere 5.
Path selection is voor alle datatstores 'DELL_PSP_EQL_ROUTED'.

Wij hebben al langere tijd precies hetzelfde op onze omgeving, vSphere 4.1 en 5.0 met een Dell EQL storage omgeving. Volgens onze leverancier komt deze melding door de multipathing van dell, waardoor hij soms overschakeld van het ene naar het andere kanaal. Hoewel de melding als "warning" verschijnt in vsphere, kunnen we hem blijkbaar negeren omdat het "as designed" is.
Ik zie de melding liever ook verdwijnen maar het schijnt dus geen storing te zijn.

Als de groep(en) maar uit 1 member bestaat kan je ook voor de native round robin kiezen, dan heeft het eql profile geen voordelen.

Helaas, er zitten 4 members in de groep.

Als alle members gelijk zijn (qua raid policy) en er geen preferences zijn ingesteld op de volumes dan is er inderdaad niets aan te doen.. het is jammer dat je van de warning dan geen notice kan maken.

Jammer inderdaad. Vooral irritant omdat ik dagelijks een vSphere Healthcheck draai (van http://www.virtu-al.net/). Door de hoeveelheid meldingen (4 hosts * 10 datastores = veel meldingen) zie ik de meldingen niet meer die er wel toe doen.

Precies, hier hetzelfde met 16 hosts en 30+ datastores. Misschien heeft het zin dit nog eens bij vmware neer te leggen...

Is dat een VMware dingetje, of is het gedrag dat komt door de driver van Dell/Equallogic?

Beiden.

Je zou alles kunnen verzamelen op een syslog server (wat VMware ook prefereerd) en daar de betreffende meldingen re-assignen als notice en/of weg filteren.