Een ESXi 5.0 host van ons blijft een tijd lang hangen na het booten en uiteindelijk na lang wachten is hij weer up maar nog als "disconnected" in Vsphere client te zien.
Na een restart van het Management Network op de console is deze weer te managen.
Vervolgens blijkt hij alle paden naar de storage kwijt te zijn, na een rescan heeft hij deze weer terug en kan alle datastores weer bedienen.

Dit blijkt een known issue te zijn volgens vmware voor degenen die gebruik maken van ISCSI storage en hun switch failover instellingen hebben staan op "Link status only"
en daarbij de ene pnic op acvitve hebben en de ander op stand-by.

In eerste instantie zou Vmware hiervoor een fix hebben in de vorm van de nieuwste updates voor Vsphere 5.0 maar bleek bij ons toch niet te werken.

Een work-around is om de failover settings te zetten op "beacon probing" waarbij de ESXi host wel weer goed op komt na een reboot.
Voor ons is die instelling niet wenselijk en daarom wachten we op ESXi 5 update1 omdat in die versie die bug opgelost zou moeten zijn.

Ik vraag mij af of wij de enige zijn die hier tegenaan zijn gelopen en of er al iets meer bekend is over versie 5.1?

Kom daar niets over tegen in de KB. Heb het ook nog nooit meegemaakt.
Lijkt mij eerder een issue met verkeerde MPIO bindings.

Nee hoor, helaas is dit bekend. Zie voor een uitgebreid verhaal met details
http://vmtoday.com/2012/02/vsphere-5-ne ... nectivity/

@Dukebox: MPIO bindings? Waar kan ik daar meer over vinden?
@Wingman7512: Thanks voor die blog! Maar wij hebben dit issue ook met een VDS.

Hier was ik ook nog niet tegen aan gelopen nee

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Hier staat een mooi voorbeeld: http://blogs.vmware.com/vsphere/2011/08 ... ments.html
Meer info is te vinden in de whitepaper.

@Dukebox: Bedankt, volgens mij wijkt onze configuratie af van alle voorbeelden met ISCSI die ik tot nu toe heb gezien. Wij gebruikten aparte vswitches met ieder 1 nic, omdat het twee fysieke gescheiden switches zijn. Nu gebruiken we 2 aparte portgroups op een VDS met ieder 1 aparte actieve uplink. Maar het kan dus net zo goed 1 portgroep met 2 uplinks zijn waarvan er 1 standby is? Begrijp ik dat goed?

Dat is niet heel afwijkend, wanneer er guest based MPIO iSCSI connecties nodig zijn is dat ook de enige juiste oplossing mits de switches natuuurlijk zorgen voor de (fysieke) koppeling tussen beide netwerken.

Ik zou daar geen VDS voor gebruiken maar een normale portgroup (i.v.m. jumbo frames), ik mag toch hopelijk aannemen dat je storage in dezelfde netwerk locatie zit als je hosts ?

Nee, per VMkernel maar 1 pNic active, dus de failover niet op je portgroup regelen (die gewoon laten staan zoals je hem wilt gebruiken).

Doe anders eens een esxcfg-vswitch.pl --list van je netwerk config, dat geeft wat meer info.

@Dukebox: Als je geen gebruik maakt van jumbo frames zijn er dan nog steeds argumenten om een standaard switch te gebruiken ipv een VDS voor Storage?

Ja,

- minder overhead en daardoor meer queue ruimte
- verkeer gaat niet eerst door de vmware ivps heen, maar direct neer de pNIC (geen impact op latency).

Ai!

Bedankt voor je antwoord, is hier een KB van bij vmware waar dit uitgelegd staat?

Niet direct geënt op iSCSI maar er wordt wel ingegaan op overhead en latency in de whitepapers voor VDS.

Ik moet zeggen dat na het installeren van 5.00 update 1 het probleem weg is..

Heb je een update gedaan op bestaande vSphere 5 host of een herinstallatie?

Ben wel benieuwd, staat hier iets bekends tussen?

http://www.vmware.com/support/vsphere5/ ... lvedissues

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

^ Terug van vakantie ?