Actualitzar un vCenter Server Appliance (VCSA) a través de VAMI hauria de ser un procés rutinari, però a la pràctica moltes organitzacions el converteixen en un esdeveniment de recuperació. La diferència no rau en el botó de pedaç, sinó en la preparació prèvia: des de la validació del cicle de vida fins a la verificació de còpies de seguretat, espai en disc, credencials i estat de serveis. Aquest article ofereix una guia operativa, contextualitzada per a entorns empresarials, i mostra com una planificació adequada pot evitar temps d'inactivitat innecessaris.
El primer error comú és assumir que l'actualització per VAMI és sempre la via correcta. En entorns VMware Cloud Foundation (VCF), SDDC Manager sol gestionar el cicle de vida, i aplicar un pedaç directament per VAMI pot generar desfasaments d'inventari. Per això, abans de tocar la pestanya 'Update', cal respondre: Aquest vCenter és independent o està gestionat per VCF? El pedaç està aprovat en el bill of materials? La URL del repositori continua sent l'heretada de VMware obsoleta? Broadcom ha canviat les adreces a dl.broadcom.com amb tokens d'accés específics. Ignorar això provoca fallades d'autenticació i missatges com 'Check the URL and try again'. Validar la connectivitat i la configuració del repositori abans de la finestra de manteniment és un pas que molts ometen.
Un altre punt crític són les credencials. El compte root expira cada 90 dies per defecte, i descobrir enmig del pedaç que la contrasenya ha caducat és frustrant. Amb chage -l root des d'SSH es pot comprovar l'antiguitat. A més, per a vSphere 7.x i 8.x es poden usar credencials d'SSO administrador en lloc de root, però cal assegurar-se que no estiguin bloquejades. Disposar d'accés a VAMI, a la consola d'ESXi on corre la màquina virtual de vCenter i, si escau, a SDDC Manager, és part de la llista de comprovació prèvia.
La validació de còpies de seguretat no pot ser un mer check binari. Broadcom recomana còpies de seguretat basades en fitxers a través de VAMI, i també snapshots offline mentre la VM està apagada. Però un snapshot no és un pla de recuperació; és un artefacte temporal que s'ha de documentar i eliminar després de la validació. És important no solapar snapshots amb còpies de seguretat actives, i programar les còpies quan vCenter no estigui sota càrrega alta. Una bona pràctica és verificar que es pot restaurar una còpia de seguretat abans d'aplicar el pedaç, no només que la còpia de seguretat existeix.
L'espai en disc és una altra font clàssica de fallades. Les particions com /, /storage/db, /storage/log o /storage/updatemgr poden omplir-se amb logs, core dumps o paquets d'actualització antics. Una ordre df -h revela la situació. Si una partició està a prop del límit (per exemple, menys de 30 GB lliures a l'arrel, que en vCenter 7.0+ no es pot redimensionar), cal alliberar espai abans de continuar. Esborrar fitxers a cegues no és recomanable; el millor és identificar la causa: logs rotats, bundles antics, fitxers de suport, etc.
L'estat dels serveis també s'ha de verificar. Des de VAMI (pestanya Services) o amb service-control --status --all es pot veure si algun servei crític està caigut. Aplicar un pedaç sobre un vCenter ja degradat no ho soluciona; al contrari, pot agreujar-ho. En entorns VCF, a més, es pot usar health.system.get des d'Appliance Shell per a una comprovació general. No s'ha de procedir si hi ha serveis en estat fallit a menys que el pedaç formi part d'una estratègia de remediació dirigida pel proveïdor.
VAMI ofereix dos modes operatius: 'Stage Only' i 'Stage and Install'. El primer descarrega el pedaç però no l'instal·la, cosa que permet validar la descàrrega sense afectar el servei. És útil quan la finestra de manteniment és ajustada o quan el repositori depèn de credencials temporals. Si s'escull l'opció combinada, cal tenir en compte que el precheck pot fallar per espai, per credencials SSO no vàlides o perquè la còpia de seguretat no s'ha confirmat. Durant la instal·lació, la interfície pot tornar-se intermitent i, en alguns casos, mostrar advertències enganyoses (Broadcom KB 415762 documenta un cas en vCenter 8.0 U1 on la UI diu que vCenter està caigut, però els serveis continuen). La clau és no interrompre el procés sense abans verificar l'estat real des de consola.
Després del pedaç, la validació no acaba. Cal confirmar que el número de build mostrat a VAMI coincideix amb la KB oficial de Broadcom, que el client vSphere respon, que les integracions amb NSX, VCF o còpia de seguretat es mantenen, i que no hi ha desfasament de versió. En entorns VCF que han aplicat un pedaç fora de banda, serà necessari sincronitzar l'inventari mitjançant una crida API POST a /v1/resources/version-syncs. Si no es fa, el sistema de gestió pot quedar cec respecte a l'estat real de vCenter.
El pla de rollback ha de ser realista. No sempre es pot revertir un snapshot: si els serveis han avançat massa o si el pedaç ha modificat la base de dades, restaurar pot ser més perillós que reparar. Broadcom recomana recollir logs abans de revertir: vc-support -l exporta un bundle a /storage/log. Aquesta evidència és crucial per a l'anàlisi post-mortem i per no repetir el mateix error a la propera finestra.
Des d'una perspectiva empresarial, gestionar correctament les actualitzacions d'infraestructura s'alinea amb la maduresa tecnològica de l'organització. A Q2BSTUDIO entenem que un centre de dades ben governat és base per a qualsevol iniciativa de transformació digital. Per això oferim aplicacions a mida i serveis d'intel·ligència artificial que s'integren amb entorns virtualitzats, així com consultoria en ciberseguretat en núvols públics, serveis cloud AWS i Azure, i solucions d'intel·ligència de negoci amb Power BI. El nostre equip pot ajudar-vos a dissenyar processos d'actualització que minimitzin el risc, utilitzant agents IA per monitoritzar l'estat dels serveis i automatitzar comprovacions prèvies. L'experiència demostra que una actualització planificada amb suport de programari a mida redueix la fricció operativa i evita costosos temps d'inactivitat.
En resum, VAMI és una eina potent, però no substitueix una gestió de canvis rigorosa. La diferència entre un pedaç exitós i un esdeveniment de recuperació està en els passos previs: ownership del cicle de vida, validació de repositoris, credencials, còpies de seguretat, espai i salut del sistema. Seguiu aquests principis i cada actualització serà previsible, documentada i segura.
