VMware– SCSI NMP error

Czasem zdarzają się sytuacje, w których przy stosunkowo małym ruchu występują spore opóźnienia lub problemy w dostępie do macierzy. Sama diagnostyka zazwyczaj zaczyna się od analizy wykresów dostępnych w vCenter lub sprawdzenia wyników esxtop na konkretnym hoście. Na podstawie zebranych danych często próbujemy przenieść cześć maszyn na inne LUNy czy optymalizować konfigurację kontrolerów dostępnych na określonych macierzach. Podczas procesu optymalizacji warto lub nawet trzeba przeglądnąć log vmkernel. W logu tym zapisywane są komunikaty scsci device NMP error, które mogą nam ułatwić analizę problemów występujących w naszym środowisku.

Jak analizować błędy NMP?

Każdy wpis dotyczący błędów NMP zawiera kilka istotnych elementów:

1. 
   
   Data i godzina wystąpienia błędu, tutaj warto pamiętać, że hosty (ESXi) korzystają z czasu UTC.


2. 
   
   Identyfikator problematycznego LUNu (naaID). W celu pozyskania dodatkowych informacji na temat określonego urządzenia możemy skorzystać z vClienta lub narzędzi CLI. Np. esxcli storage core path list -d <naaID> zwróci nam dokładniejsze informacje o LUNie o okreslonym naaID.


3. 
   
   Status code – ogólny identyfikator problemu określający, który komponent/urządzenie zwróciło błąd:
   
   
   
   
   
   
   • 
     
     H – błąd po stronie hosta
   
   
   • 
     
     D – błąd zwrócony przez host docelowy
   
   
   • 
     
     P – błąd wygenerowany przez plugin NMP
   
   
   
   Kod 0x0 jest zwracany gdy nie zaobserwowano, żadnego błędu. Przykładowo H: 0x0 mówi nam, że po stronie hosta wszystko działa poprawnie. W zależności od problemów, możemy zaobserwować różne numery błędów:
   
   
   
   
   
   
   • 
     
     0x2 – nieudane wykonanie określonej komendy, więcej informacji znajdziemy analizując dodatkowy numer (4)
   
   
   • 
     
     0x8 – określone urządzenie jest zajęte i nie akceptuje komend SCSI.
   
   
   Więcej informacji na temat najczęściej występujących  statusów możemy znaleźć bezpośrednio na stronie vmware [KB1030381].


4. 
   
   Valid sense data: dodatkowe informacje na temat błędu zwróconego przez określone urządzenie. Przykładowo jeśli urządzenie docelowe zwróci nam status 0x2 oznaczający błędne wykonanie określonej komendy to Valid sense data pozwoli nam określić powód błędu.
   
   
   
   
   
   
   • 
     
     Pierwszy numer w ciągu to Sense Key, którego opis możemy znaleźć na stronie  [t10.org]
   
   
   • 
     
     pozostałe dwa numery to  Additional Sense Code/ ASC Qualifier. Dokładny ich opis można znaleźć na stronie [t10.org]. Przy czym postać 0xX 0xY zapisana jest w postaci X/Y

Przykładowa analiza

Na wyżej zamieszczonym zrzucie można zobaczyć, że na lunie o id naa.600cf….. wystąpił błąd o identyfikatorze H:0x0 D:0x2 P:0x0 – problem po stronie urządzenia docelowego. Status 0x2 – nie udało się poprawnie wykonać komendy po stronie macierzy. Dodatkowy kod 0x0 0x47 0x0   zgodnie z opisem na stronie [t10.org] wskazuje:

• 
  
  sense code 0x0 – brak jakiegoś specyficznego błędu, wymagane sprawdzenie dodatkowych pól


• 
  
  additinal sense code 0x47 / ACS 0x0 – 47/00 SCSI PARITY ERROR – w zależności od konfiguracji problem może być związany nie z samym kontrolerem lecz z kablami lub urządzeniami występującymi między hostem a macierzą.

Konkluzje

Tak, wiem, po co analizować tak głęboko logi i studiować dokumentacje? Przecież od tego jest wsparcie techniczne.

Primo – warto wiedzieć gdzie mamy zgłosić błąd (H: 0x0 D:0x2 P:0x0 – błąd po stronie macierzy, otwarcie zgłoszenia w na stronie VMware zakończy się odbiciem do producenta macierzy[: ) Zamiast marnować czas na odbijanie piłeczki, warto wiedzieć gdzie pisać w pierwszej kolejności.

Secundo – jeśli skończy się nam wsparcie lub proces rozwiązania zgłoszenia będzie zbyt długi, warto mieć podstawowe informacje na temat problemu. Będziemy wiedzieli kiedy konsultant gra na zwłokę, a może własnymi siłami uda się rozwiązać problem.