Spędziłem kilka ostatnich dni na wojnie podjazdowej z vSphere 5.5. Generalnie wydanie to będzie przez najbliższe kilka lat kojarzyć mi się z karmieniem gęsi przez rurę przy jednoczesnym robieniu jej lewatywy. Najgorsze wydanie chyba od… zawsze? Mnóstwo drobnych błędów, kumulujących się z czasem w taką lawinę, że trudno zorientować się co się dzieję i kto właśnie dźga nas w plecy.

https://flic.kr/p/4XWs1g

Trzeba jednak oddać honor dla VMware gdyż w wielu przypadkach błędy te nie wynikają z ich winy, a wszelkie wycieki pamięci, przepełniające partycję root to sprawka ich partnerów, oraz ich wyuzdanego oprogramowania. Dobrze zacznijmy jednak od czegoś mniej szatańskiego.

Jeżeli zdarzy ci się, że podczas rytualnej przechadzki przypomni ci się, że trzeba sprawdzić snapshoty zazwyczaj udajesz się do zakładki „Sotrage Views”. Bo szybko, schludnie i wygodnie. Rzadko ją sprawdzasz, bo przecież kto by się przejmował snapshotami… W zasadzie pierwszy raz od aktualziacji z 5.1 do 5.5 Twoje nobliwe, pełne zrozumienia oczy przebiegają delikatnie niczym jutrzenka o brasku po zamglonej łace zmierzając do wspomnianej zakadki… a tu, niespodziewanie, taki czeka na ciebie grzyb:

Untitled

Może objawić ci się on w różnych wydaniach. Dla przykładu:

The server „x.x.x.x” could not interpret the client’s request. The request failed because the remote server ‚x.x.x.x’ took too long to respond.
The server „x.x.x.x” could not interpret the client’s request. (the remote server returned an error: (400) Bad request.)
The server „x.x.x.x” could not interpret the client´s request. (The remote server returned an error: (404) Not Found.)
The server „x.x.x.x” could not interpret the client´s request. (The remote server returned an error: (503) Server Unavailable

Co robisz? Oczywiście wpisujesz w google, w rezerwuar pamięci, wiedzy i oświecenia XXI wieku. A tam odpowiedzi na Twój problem znajdują się w ciągu ułamka sekundy:

Podniecony jak kozioł na przednówku powracasz pośpiesznie do swojej infrastruktury i nagle orientujesz się, że przecież masz vCenter Appliance, a wszystkie opis, które znalazłeś są dla vCenter zainstalowanego na systemie Windows.

Takie chwile jak ta sprawiają, że trzeba odrdzewić stare, zmurszałe umiejętności rycia w konsoli i poszukać odpowiedników konfigów z Windows’a w Linuxie.

Zacznijmy więc od tego, co mogło się zepsuć. Plik proxy.xml. w którym został z poprzedniego konfiga zły port dotyczący miejsca, w którym znajduje się wrapper javy odpowiedzialny za publikację danych z serwisu vCenter Profile‐Driven Storage Service dla vClienta. Tak, więc jak otworzy plik…

/etc/vmware-vpx/proxy.xml

…za pomocą jednego z największych urządzeń do masochizmu – VI, plik znajdź tam linie podobne do tego:

<_type>vim.ProxyService.LocalServiceSpec</_type>
<accessMode>httpsWithRedirect</accessMode>
<port>8086</port>
<serverNamespace>/sms</serverNamespace>

Masz tam port 8086/8080 lub inny, zmień go na port 22000 – zdaje się, ze od wersji 5.1 U2 serwis vmware-sps działa właśnie na tym porcie. Tak, więc wpis ten powinien wyglądać następująco:

<_type>vim.ProxyService.LocalServiceSpec</_type>
<accessMode>httpsWithRedirect</accessMode>
<port>22000</port>
<serverNamespace>/sms</serverNamespace>

Jeżeli masz jeszcze chwilę, to zmien również port w <_type>vim.ProxyService.LocalServiceSpec</_type> z czegokolwiek tam znajdziesz na 21000.
Zrestartuj wszytkie serwisy odpowiedizalne za obsługę tego kawałka vCenter czyli:

/etc/init.d/vmware-vpxd restart
/etc/init.d/vmware-sps restart

Sprawdz na stronie https://vcenter.cmentarnapolka.pl/sms/health.xml czy widzisz plik. Pewnie nie, ale nie martw się ja też nie zobaczyłem. Wykonaj przerwę na kubełek Kentucky Fried Chicken. Odpal VI, zwymiotuj kurczaki i znajdź w końcu jakieś LOGi, a nie jak dziecko we mgle 😉 Logi serwisu SPS/SMS dostępne są w jakże intuicyjnym miejscu:

/var/log/vmware/vpx/sps/

Warto tutaj nadmienić, że większość usług, demonów w vCSA działa poprzez wrappery… tak, są napisane w Javie. Też ubolewam, ale przecież soft do 10 tryliardów urządzeń napisany jest w Javie i jakoś działają… Łącznie z robotami medycznymi wykonywującymi operacje – wyrażenie „broken pipe” tak często spotykane w logach Tomcata nabrało zupełnie nowego wyrazu, nieprawdaż? Porzućmy jednak te dygresje o suuuuabości Javy i wróćmy do naszych logów. Mamy dwa pliki w tym katalogu:

sps.log
wrappper.log

Nas w sumie będzie interesować ten drugi. W pierwszy możesz zajrzeć, ale raczej wszystko będzie ok. Natomiast drugi to istna Moria. Otwórzcie sobie drugie okno z ssh i w jedym z nich zapalcie…

tail –f /var/log/vmware/vpx/sps/wrappper.log

…w drugim natomiast przeładuje demona SPS/SMS:

/etc/init.d/vmware-sps restart

Jeżeli w logu dostaniecie coś takiego:

STATUS | wrapper | 2014/07/24 10:52:27 | <– Wrapper Stopped
STATUS | wrapper | 2014/07/24 10:52:34 | –> Wrapper Started as Daemon
STATUS | wrapper | 2014/07/24 10:52:34 | Java Service Wrapper Professional Edition 64-bit 3.4.1
STATUS | wrapper | 2014/07/24 10:52:34 | Copyright (C) 1999-2010 Tanuki Software, Ltd. All Rights Reserved.
STATUS | wrapper | 2014/07/24 10:52:34 | http://wrapper.tanukisoftware.org
STATUS | wrapper | 2014/07/24 10:52:34 | Licensed to VMware Global, Inc. for VMware vSphere Profile-Driven Storage
STATUS | wrapper | 2014/07/24 10:52:34 |
STATUS | wrapper | 2014/07/24 10:52:34 | Launching a JVM…

Jeżeli wyłoży Wam się tutaj z komunikatem:

Starup failed: Timed out waiting for a signal from JVM.
JVM did not exit on request, terminated.

To oznacza, że Twoja Java jak to Java niema zasobów. Tak jak ty pochłonołeś kubełek obrzydliwego kurczaka, tak on zżarła zasoby w vCSA. Teraz jest najedzona i zwolniła… musisz w pliku

/usr/lib/vmware-vpx/sps/wrapper/conf/wrapper.conf

Znaleźć linię:

wrapper.ping.timeout=30

Następnie ją zmienić i dopisać jeszcze jedną:

wrapper.ping.timeout=300
wrapper.startup.timeout=300

Sprawi to, że będziemy czekać na JVM nie 30 sekund a 300, a dodatkowo wystartujemy z 300 sekundowym opóźnieniem, po co? Aby np. po restarcie serwis ten startował po 30 sek, czyli po wszystkich poprzednich – np. po Web Client itp. Jeżeli już w logu wrappper.log zacznie widzieć takie rzeczy…

INFO | jvm 1 | 2014/07/24 10:52:35 | Picked up JAVA_TOOL_OPTIONS: -Xms16M -Xmx128M
INFO | jvm 1 | 2014/07/24 10:52:35 | WrapperManager: Initializing…

…dalej opcje są różne, albo będzie tysiąc logów z Javy i wszystko się magicznie uruchomi, lub, co bardziej prawdopodobne otrzymasz:

INFO | jvm 1 | 2014/07/24 11:50:32 | 20:56:42 ERROR opId= – Failed to connect inventory service

A całość będzie tak samo martwa. Co dziwne inventory działa, bo przecież vClient łączy się do serwera, wszystko jest dostępne przez Web Clienta. Nie tracisz jednak animuszu! Logi inventory-service znajdują się tutaj:

/var/log/vmware/vpx/inventoryservice/ds.log

Jeżeli znalazłeś tam wielokrotnie powtarzający się błąd:

inherited from com.vmware.vim.binding.vim.fault.InvalidLogin: Cannot complete login due to an incorrect user name or password.

To nie szukaj dalej. Podczas którejś z aktualziacji, albo użytkowania uszkodziła się wbudowana w vCSA baza danych DB2. Jest kilka sposobów naprawy, ale najwydajniejszy to reinicjalizacja. Proces ten usuwa wszelkie dane z vCenter, łączenie z licencją, więc sobie ją spiszcie przed jej wykonaniem. Jak już sobie wyeksportujecie wszystko, warto zrobić snapshot, jakby coś się wyłożyło. Re-inicjalizację bazy robi się nastepującoc (według KB 2013047)

service vmware-vpxd stop
/usr/sbin/vpxd –b

Powinno wam wyświetlić coś podobnego do tego:

—— In-memory logs start ——–
2012-02-01T15:13:50.019-07:00 [7FFFF3B09700 info ‚Hooks’] Hooks Initialized

—— In-memory logs end ——–
2012-02-01T15:13:50.071-07:00 [7FFFF3B09700 info ‚Default’] Initialized channel manager
2012-02-01T15:13:50.176-07:00 [7FFFF3B09700 info ‚Default’] Current working directory: /root
2012-02-01T15:13:50.176-07:00 [7FFFF3B09700 info ‚Default’] Log path: /var/log/vmware/vpx
2012-02-01T15:13:50.176-07:00 [7FFFF3B09700 info ‚Default’] Initializing SSL
2012-02-01T15:13:50.472-07:00 [7FFFF3B09700 info ‚Default’] Vmacore::InitSSL:doVersionCheck = true, handshakeTimeoutUs = 120000000
2012-02-01T15:13:50.542-07:00 [7FFFF3B09700 info ‚Default’] Registry Item DB 5 value is ”
2012-02-01T15:16:04.665-07:00 [7FFFF3B09700 info ‚Default’] [LdapBackup] Making sure LDAP instance VMwareVCMSDS is running
2012-02-01T15:16:04.665-07:00 [7FFFF3B09700 info ‚Default’] [LdapBackup] Checking service ldap for running
2012-02-01T15:16:04.689-07:00 [7FFFF3B09700 info ‚Default’] [LdapBackup] LDAP not started: 0x300
2012-02-01T15:16:05.789-07:00 [7FFFF3B09700 info ‚Default’] [LdapBackup] Started LDAP

Następnie:

service vmware-vpxd start
service vmware-vpxd status

… i zakładki działają. Natomiast żeby niezakonczyc to tak smutnie to w dwóch lokalizacjach pomogła zmiana portów, a w jednej zmiana zarezerwowanych portów w wrapperach. Na koniec aby sprawdzić czy usługa SPS działa należy wykonać komendę:

netstat -npea | grep 22000 & netstat -npea | grep 21000

Jej wynik powinien być podobny do tego:

[1] 21321
tcp 0 0 :::21000 :::* LISTEN 0 23527 6677/java
tcp 0 0 :::22000 :::* LISTEN 0 23491 6677/java
tcp 0 0 ::1:52265 ::1:21000 TIME_WAIT 0 0 –
tcp 0 0 ::1:56701 ::1:22000 TIME_WAIT 0 0 –
tcp 0 0 ::1:52230 ::1:21000 TIME_WAIT 0 0 –
tcp 0 0 ::1:56736 ::1:22000 TIME_WAIT 0 0 –

Jeżeli mamy coś co słucha na tych portach to jest dobrze. Następnie możemy sprawdzić co się kryje pod PID 6677. Jeżeli jest to wrapper to po sprawdzeniu strony https://vcenter.cmentarnapolka.pl/sms/health.xml powinniśmy dostać poszukiwany plik, a zakłada Storage Views magicznie ożyje.

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.

Leave a Reply