Ten dzień, gdy wchodzisz do basenu, a bąbelki masują ci skostniałe plecy. Lód skrapla parę wodną na szklance wypełnionej twoim ulubionym drinkiem. Słońce przebijając się przez falujące na delikatnym wietrze liście omiata ciepłem twarz. Ten moment, gdy dzwoni komórka, a metaliczny głos po drugiej stronie wyszczekuje łamanym angielskim, że partycja /root w wszystkich produkcyjnych ESX jest pełna. Ten dzień.

https://flic.kr/p/cpZtVY

Jak zapewne się domyślacie problem z VMware vSphere 5.5… a jakże! Jestem zafascynowany tym wydaniem i towarzyszącymi mu programami partnerów. Przyjemność obcowania z wersją 5.5 porównywalna jest tylko do podróży przez dżunglę w Birmie, piechotą, nago, wysmarowanym od stóp do głów miodem.

Wracając jednak do tematu. Większość producentów sprzętu serwerowego przygotowuje predefiniowane obrazy iso ESX. Wersję taką dostarcza Cisco, DELL, IBM i HP. Zazwyczaj wersje te zawierają odpowiednie do wydania sterowniki, są one przetestowane i mając sprzęt danego producenta powinny być naszym naturalnym wyborem podczas instalacji. Zazwyczaj… HP najwidoczniej zapomniało przetestować swojego ISO. Przeoczony przez nich błąd dotyczy wycieku pamięci w serwisie o tajemniczej nazwie hp-ams, który bez opamiętania loguje swoje własne błędy.

Czym się objawia wypełnienie /root? Otóż takie błędy wypluwane przez vSphere klienta mogą wam się zdarzyć:

Podczas próby vMotion: – „A general system error occurred:”

Podczas próby Storage vMotion: „/var/log/vmware/journal/xxxx error writing file. There is no space left on the device.”

Lub w pliku /var/log/vobd.log dostajemy błędy: „Cannot extend visorfs file /var/log/hpHelper.log because its ramdisk (root) is full”

Jeżeli doświadczacie jednej z powyższych sytuacji prawdopodobnie macie problem z plikiem hpHelper.log, który to z apetytem zjadł Wam całe miejsce na partycji root. Jak się upewnić? Zalogujcie się na serwer po SSH? Nie działa? W takim razie po kosoli iLO, przejdzcie za pomocą Alt+F1 na powłokę systemową i tam wydajcie komendę:

vdf –h

Ramdisk                   Size      Used Available Use% Mounted on

root                       32M        32M       0M  99% —

Jeżeli dostaniecie powyższy wynik, należy zajść do katalogu:

cd /var/log

ls –alh | grep hpHelper.log

Jeżeli plik hpHelper zajmuje około 30mb to znaczy, że odnaleźliście problem i należy go usunąć, uprzednio wyłączając serwis hp-ams.

/etc/init.d/hp-ams.sh stop

rm hpHelper.log

Następnie możemy albo ten serwis wyłączyć na dobre:

chkconfig hp-ams.sh off

Lub, drugą opcją jest aktualizacja sterownika, robi się zgodnie z opisem HP dostępnym tutaj -> http://bit.ly/1pq0v2P

Acha, bym zapomniał! Teraz możecie zrobić VMotion wszystkich maszyn z tego hosta na inny w klastrze i wykonać reboot… inaczej nie zadziała Wam, mimo usilnych prób restartu serwisu, serwer SSH.

Źródła:

 

About the author

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT. Specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.
2 Responses
  1. Tak tylko dodam że na 5.1 też może zdarzyć się ta przygoda. DCUI wcale nie musi działać, a wyświetla tylko magiczne can’t fork.

    ESXi dotknięty tą przypadłością nie może być celem vmotion więc prawdziwa zabawa zaczyna się jak cały klaster krzyczy can’t fork.

    Ja bym sugerował bardziej siłowe rozwiązanie
    esxcli software vib remove -n hp ams
    reboot

    Zwłaszcza że to nie pierwsza wpadka HP z tym modułem

Leave a Reply