Piszki Lab

Analiza przypadku w języku przodków…

Oporny upgrade vCenter 5.1 do wersji 5.1U2a.

| 0 comments

Niedawno na produkcji pojawiło się okienko serwisowe. Zupełnie niespodziewanie. Wystarczająco szerokie aby wykorzystać je do wykonania dawno odkładanego upgrade vCenter 5.1 do ostatniej wersji. Przeskok z 5.1U1 do wersji 5.1U2a wydaje się małym kroczkiem, hę? Nic bardziej mylnego! Dwudniowy horror jaki sobie zafundowaliśmy będę wspominał długo! Do tej pory w rozmowach z przedstawicielami VMware zawsze chwaliłem się że nie wiem o co im chodzi gdy mówią o problemach z SSO w 5.1. Aż do teraz. Będę pisał grzecznie i poprawnie, mimo targających mną emocji :-)

vm4

Akt pierwszy, upgrade SSO. Czy może być coś prostszego? Wkładamy płytkę, next, next, next, finish. Usługa nie wstaje. Symptomy zostały opisane w tym KB (Server daemon died!), niestety opisana solucja nie pomogła. SSO na javie wykopiowanej z pliku jre.zip startowało bez problemu, ale nie działało poprawnie, w logu vCenter (vpxd.log), pojawił się natychmiast wpis:

[01608 info ‚[SSO][SsoFactory_CreateFacade]’] Solution user set to: vCenterServer_2012.11.26_102929
[01608 info ‚[SSO][SsoFactory_CreateFacade]’] VC’s ServiceId in LookupService: {D3E3C386-3CCE-420E-AF3E-A72393D1A146}:9
[01608 info ‚[SSO][SsoFactory_CreateFacade]’] STS URI set to: https://PTSSO1.ptcloud.local:7444/ims/STSService
[01608 info ‚[SSO][SsoFactory_CreateFacade]’] Admin URI set to: https://PTSSO1.ptcloud.local:7444/sso-adminserver/sdk
[01608 info ‚[SSO][SsoFactory_CreateFacade]’] Groupcheck URI set to: https://PTSSO1.ptcloud.local:7444/sso-adminserver/sdk
[01608 info ‚[SSO][SsoFactory_CreateFacade]’] VC SSL certificate location: C:\ProgramData\VMware\VMware VirtualCenter\ssl\rui.crt
[01608 info ‚[SSO][CreateSsoFacade]’] [CreateUserDirectory] STS URI set to: https://PTSSO1.ptcloud.local:7444/ims/STSService
[01608 info ‚[SSO][CreateSsoFacade]’] [CreateUserDirectory] Admin URI set to: https://PTSSO1.ptcloud.local:7444/sso-adminserver/sdk
[01608 info ‚[SSO][CreateSsoFacade]’] [CreateUserDirectory] Groupcheck URI set to: https://PTSSO1.ptcloud.local:7444/sso-adminserver/sdk
[01608 error ‚Default’] Found dangling SSL error: [0] error:00000001:lib(0):func(0):reason(1)
[01608 error ‚Default’] Found dangling SSL error: [1] error:00000001:lib(0):func(0):reason(1)
[01608 error ‚[SSO][SsoFactory_CreateFacade]’] Unable to create SSO facade: vmodl.fault.SystemError.
[01608 error ‚vpxdvpxdMain’] [Vpxd::ServerApp::Init] Init failed: Vpx::Common::Sso::SsoFactory_CreateFacade(sslContext, ssoFacadeConstPtr)
–> Backtrace:
–> backtrace[00] rip 000000018018b86a
–> backtrace[01] rip 0000000180102ac8
–> backtrace[02] rip 0000000180103f9e
–> backtrace[03] rip 000000018008d22b
–> backtrace[04] rip 00000000003e5bdc
–> backtrace[05] rip 0000000000406652
–> backtrace[06] rip 00000001405cf001
–> backtrace[07] rip 00000001405c8e1c
–> backtrace[08] rip 00000001407ed8db
–> backtrace[09] rip 000007fefed7a82d
–> backtrace[10] rip 00000000776d59ed
–> backtrace[11] rip 000000007790c541
–>
[01608 warning ‚VpxProfiler’] ServerApp::Init [TotalTime] took 7784 ms
[01608 error ‚Default’] Failed to intialize VMware VirtualCenter. Shutting down…
[01608 info ‚vpxdvpxdSupportManager’] Wrote uptime information

Oczywiście VMware ma na wszystko KB, jednak i tym razem opisana solucja nie zadziałała. Na szczęście miałem do dyspozycji stary katalog jre z przed upgrade. Podmieniłem i o dziwo SSO wystartowało poprawnie. Także vCenter połączyło się poprawnie do SSO.

Akt drugi, upgrade Inventory Service. Instalator podmienia katalog jre na wersję nie działającą, usługa nie wstaje. Zastosowałem procedurę podmiany jre na starszą wersję i wszystko się uruchomiło. Niestety, w logach Inventory Service pojawiło się coś takiego:

wrapper.log:

INFO   | jvm 1    | 2014/10/29 08:09:35 | 2014-10-29 08:09:35 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor run
INFO   | jvm 1    | 2014/10/29 08:09:35 | SEVERE:
INFO   | jvm 1    | 2014/10/29 08:09:35 | java.lang.NoClassDefFoundError: sun/security/util/KeyUtil
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at com.sun.crypto.provider.DHKeyAgreement.engineDoPhase(DashoA13*..)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at javax.crypto.KeyAgreement.doPhase(DashoA13*..)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at com.sun.net.ssl.internal.ssl.DHCrypt.getAgreedSecret(Unknown Source)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientKeyExchange(Unknown Source)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(Unknown Source)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Unknown Source)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at java.security.AccessController.doPrivileged(Native Method)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Unknown Source)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:285)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:343)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:193)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1642)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
INFO   | jvm 1    | 2014/10/29 08:09:35 |     at java.lang.Thread.run(Unknown Source)

I tak restart za restartem. Wyłączamy SSO, podmieniamy Javę na wersję z pliku jre.zip, uruchamiamy Inventory Service. Działa! Czyli SSO działa na starszej wersji Javy a Inventory Service na nowej (a katalog jest wspólny). Ten problem też dało się rozwiązać. JRE zostało przywrócone stare, SSO wystartowało. Obok został wgramy JRE_NEW z pliku jre.zip a w pliku wrapper.conf w katalogu Program Files\VMware\Infrastructure\Inventory Service\conf została zmodyfikowana linia: wrapper.java.command=D:/Program Files/VMware/Infrastructure/jre_new/bin/java. Po takiej modyfikacji mamy dwie usługi działające na różnych wersjach Javy (to jeszcze ten typ instalacji gdzie SSO i Inventory Service są na osobnym hoście). Bardzo podobna procedura miała miejsce na vCenter, instalator za każdym razem uszkadzał katalog jre i trzeba było ręcznie podmieniać jego zawartość. W tym wypadku wszystkie usługi działające na Javie zainstalowane razem z vCenter działają poprawnie i na nowej i na starej wersji Javy.

Oceń ten artykuł:
[Głosów:0    Średnia:0/5]

Dodaj komentarz

Required fields are marked *.


.

Podobał się wpis? Wesprzyj Piszki Lab, kliknij w reklamę! :-)

.