VPLEX: Fel 0x8a2d9050 och resulterande scsi/162-händelser i fast programvara på standard-LUN Zero (DL0)
Sammanfattning: I den här artikeln beskrivs problemet med en ogiltig kvalificerare för kringutrustning och vad du ska göra för att lösa problemet.
Symptom
Felmeddelande:
Callhome-händelse Critical_0x8a2d9050
se scsi/162-händelseströmning i firmware.logs:
2019/05/08 17:05:24.39: information om scsi/162-kringutrustning anges som 0x3f. VPD-parametrar omfattas inte av VPD-standard
2019/05/08 10:50:33.79: information om scsi/162-kringutrustning anges som 0x20. VPD-parametrar omfattas inte av VPD-standarden
I båda fallen delar koderna för kringutrustnings-ID för 0x20 och 0x3F ogiltig kvalificerare för kringutrustning 001. En enhet som har den angivna enhetstypen är inte ansluten till den här logiska enheten. Enhetsservern har dock stöd för den angivna enhetstypen på den här logiska enheten.
0x20-kringutrustningstyp är en blockeringsenhet med direkt åtkomst.
0x3F-kringutrustningstyp är okänd eller ingen enhetstyp.
Orsak
Steaming scsi/162-händelser som anges ovan orsakas av designprincipen runt DL0:
- Användare zonplanerar ett nytt disksystem till VPLEX.
- Inga lagrings-LPU:er provisioneras (vilket är normalt).
- Om det inte finns några LU lägger SCSI-lagret till en LUN0 (och etiketterar den som DL0).
- LUN0-identifieringen leder till att disksystemsinformationen (leverantör, produkt och version) hittas.
- Disksystemet visas nu i VPLEXCLI.
- Användaren kan lägga till nya lagringsenheter och utföra en ny identifiering av disksystemet till att synkronisera VPLEX med disksystemets LUN-inventering.
- Några av VPD INQ-filerna (steg 4) returnerar ett ogiltigt fält för KVALIFICERANDE KRINGUTRUSTNING.
Det bör anges att DL0 även kan uppstå när en slutanvändare zonplanerar ytterligare disksystemportar till VPLEX som inte ingår i några lagringsdisksystem som maskerar vyn mellan disksystemet och VPLEX. Det innebär att DL0 fortfarande kan rapporteras även om det finns en riktig LUN0 i alla maskeringsvyer för lagringsdisksystemet.
Upplösning
Upplösning:
Problemet har åtgärdats i GeoSynchrony 6.2 Korrigeringsfil 5 och senare
Tillfällig lösning:
I stället för att använda DL0 etablerar du en riktig LUN0 för alla maskeringsvyer för lagringsdisksystem i alla lagringsdisksystem bakom VPLEX. Alla disksystemportar som har zonindelats till VPLEX ska också vara i en maskeringsvy för lagringsdisksystemet, eller så bör zonindelningen tas bort om portarna inte används. I annat fall inträffar DL0 trots att det har en riktig LUN0 i alla maskeringsvyer.
Överlag bör vi egentligen inte bearbeta någon enhet med en icke-, 0x00- eller kringutrustnings-ID-kod.
Fler anteckningar om LUN0-krav:
- LUN0 kan vara en befintlig LUN på lagringsdisksystemet. Det kan dock vara enklare att skapa en LUN och tilldela den som LUN0.
- LUN0 kan vara av vilken storlek som helst (minsta storlek 1 block eller 4 KB).
- LUN0 får endast finnas i maskeringsvyn, men VPLEX behöver inte göra anspråk på den här volymen.
Obs! Beroende på det disksystem som är anslutet till VPLEX kan du behöva kontakta disksystemleverantören och/eller supportteamet för att få instruktioner om hur du konfigurerar en LUN0 och presenterar den för VPLEX.
Ytterligare information
Obs! Om en slutanvändare använder ett lagringsdisksystem från Symmetrix-serien (VMAX eller PowerMax) ska de hänvisa till följande KB-artikel 000051855: Unisphere för Powermax: Så här tilldelar du HLU=0 i unisphere for PowerMax 9.0 som beskriver hur du tilldelar en LUN0 inom disksystemet Unisphere och ser till att alla disksystemsmaskvyer innehåller en LUN-adress på 0000 som löser LUN0-problemet.
I vissa VMAX-fall misslyckades INQ:er på en underuppsättning sökvägar med DL0. Den felaktiga sökvägen med VPID-VPD83T3:60000970000492600000000000000000 är vad som anses vara en spök-LUN. Det är vad scsi/162 utformades för att fånga.