Most volt időnk 4.1-re frissíteni a vSphere környezetünket. A vSphere Upgrade Guide elég jól összefoglalja a lehetőségeket, és leírja a lépéseket. Az Upgrading ESX 4.0 to ESX 4.1 KB cikkben pedig még vannak videók is a frissítés menetéről.
Egy-két buktatóba azért belefutottunk.
Fájl feltöltés hiba
Első lépésként az egyik teszt ESXi 4.0-ás gépet akartuk 4.1-re frissíteni a VMware Update Manager (VUM) segítségével. Ehhez először az upgrade zip-et kell feltölteni a VUM-ba, azonban az a következő hibát dobta:
“Failed to import upgrade. Error was: File Upload Error”
A VUM log fájlokat a C:\ProgramData\VMware\VMware Update Manager\Logs könyvtárban találjuk, a kapcsolódó részlet ez volt:
[2010-08-23 17:11:12,963 pool-1-thread-2 ERROR 'com.vmware.updatemanager.fileupload.ImportWorker'] Import File, exception
AxisFault
faultCode: ServerFaultCode
faultSubcode:
faultString: integrity.fault.HostUpgradeChecksumFailure
faultActor:
faultNode:
faultDetail:
{urn:integrity}HostUpgradeChecksumFailureFault:<reason>Invalid fault</reason>
Nem túl segítőkész:) Más is látott ilyet (Unable to create Update Baseline: HostUpgradeChecksumFailure). A gépet a vihostupdate CLI eszközzel sikerült frissíteni, nem az upgrade fájllal volt a gond végül, hanem azzal, hogy a 4.0-s VUM nem tudja a 4.1-es frissítést kezelni. Így tehát először a vCentert és az Update Managert kell frissíteni (mint ahogyan azt a leírásban is szerepel:)
AgentUpgradeChecker
A vCenter 4.1-es CD-van egy vCenter Agent Preupgrade Check Tool nevű eszköz, amivel a vCenterből a frissítés előtt le lehet ellenőrizni az ESX gépeket.
Itt csak arra kell figyelni, hogy Run as Administrator módban indítsuk el (helye: D:\vpx\agentupgradecheck\AgentUpgradeChekcer.exe).
Log fájla: C:\Users\user\AppData\Local\VMware\vpx\VMwareAgentUpgradeChecker-X-0000.log
“cbt loaded successfully” — majd utána semmi
Az egyik gépen jött elő (pont a HS22-es blade-en, ami ráadásul még fent is van a 4.1 hardver kompatibilitás listáján), az ESXi az újraindulás után a betöltés vége felé egyszerűen megállt a cbt loaded successfully kiírásnál. Ezután kéne tulajdonképpen a szolgáltatásait elindítani az alap meghajtók betöltése után, de nem történt semmi.
Túl sok információt nem találtam róla, csak ezt: After updating to ESXi 4.1, ESXi boot up hangs on “cbt loaded successfully”. Nekünk viszont szoftver linuxos iSCSI tárhelyünk van, ráadásul egy másik ESXi, ami egy teljesen más gyártójú gépen fut, gond nélkül elindult ugyanehhez a távoli tárhelyhez kapcsolódva.
Remélve, hogy tényleg itt is csak valami timeout gond lesz, megvártam, hogy elindul-e egyáltalán az ESXi, hogy legalább utána a logokat le lehessen szedni róla. 45 perc volt:) A /var/log/messages-ben utána ennyi szerepelt:
Aug 26 13:45:50 vmkernel: sysboot: Executing '/usr/sbin/esxupdate clearpending' Aug 26 13:45:50 inetd[4922]: authd/tcp6: socket: Address family not supported by protocol Aug 26 14:28:12 esxupdate: lock: DEBUG: Lock file /var/run/esxupdate.pid created with PID 492Van egy szép kis 45 perces várakozás:) Szerencsére úgy néz ki, hogy tényleg csak a frissítés tartott eddig, következő újraindításra már szépen 2 perc alatt elindult.
A frissítésekkel kapcsolatos hibákat egyébként az esxupdate.log (/locker/db/esxupdate.log) fájlban érdemes keresni. Ennek az elérésére viszont csak azt találtam, hogy vagy bemegyünk CHEAT módban az ESXi-re közvetlenül a konzolról, vagy vCenterből lehet a File / Export / Export system logs résznél egy diagnostic bundle-t generáltatni az adott gépről, és akkor abban ez is benne van (csak ez nem túl gyors). Jó lenne azért a VI Clientbe kivezetni, vagy mondjuk PowerCLI-ből lekérdezhetővé tenni.
PS/2-es billentyűzet
Ez a négyből csak az egyik ESX-en jött elő: frissítés után nem működött az átkapcsoló PS/2-es billentyűzete. Más is látott ilyet (Is or will the keyboard issues with ESXi 4.1 get fixed?), megoldás egyelőre nincs, USB-s billentyűzetet kell rádugni:(
Update Manager vs. tanúsítványok
Ez már régi fájdalmam volt, most a frissítés kapcsán újfent előkerült. Az Update Manager és a vCenter is kap egy-egy self-signed tanúsítványt telepítéskor, amiben a VI Clientet futtató gépek természetesen nem bíznak meg, így mindig feldob egy figyelmeztető ablakot. Természetesen lehet permanensen mellőzni a figyelmeztetést, de a szép megoldás az lenne, ha hiteles (vagy legalábbis egy saját CA által kiállított) tanúsítványokra cserélnénk ezeket le.
A vCenter tanúsítványának lecseréléséhez van hivatalos leírás: Replacing VirtualCenter Server Certificates
Az Update Managerhez én ilyet nem találtam, ott ez a blog bejegyzés segít: VMware Update Manager (VUM) 4.0 SSL Certificates
Ez így már majdnem jó. Azonban az Update Manager telepítésénél ki kell választani, hogy milyen néven azonosítsák a VUM szervert a kliensek. Itt a szerver IP címeit vagy host nevét lehetne választani. Az Update Manager Admin Guide javaslata szerint adjunk meg IP címet, ami viszont azért lesz kevésbé jó, mert így természetesen a névre kiállított tanúsítványt nem fogja majd elfogadni az SSL kapcsolatnál. Lehetne a gép nevét választani, nekünk viszont úgy van beállítva, hogy a vCentert egy aliason keresztül érik a kliensek és az ESX-ek is (ami szerintem szerencsésebb, mint a gépnév használata, nem is beszélve arról, hogy ha valaki pl. alkalmazás szintű fürtözést használ, akkor csak ez működik). Viszont a GUI-n nem lehet saját értéket megadni, csak egy legördülő listából választani.
A megoldás az, hogy parancssorból kell telepíteni, és ott már meg lehet ilyeneket is adni: Performing a Command-Line Installation of VMware vCenter Update Manager
Így már egyedül az upgrade bundle feltöltésekor dobott figyelmeztető ablakot, mert ott mindenképpen IP alapján akar csatlakozni, de azt már nem találtam meg, honnan szedi (azért kellően rusnya bestia ez a vSphere, konfigurációs beállításokat szed a registryből, konfig fájlokból, ráadásul van egy saját LDAP példánya is, és van ami csak ott módosítható).