Esta semana he tenido la oportunidad junto con mi compañero Juan Vicente López de realizar una migración a vSphere 6.5 U1 desde la versión 5.5 U3d con la herramienta de migración de VMware. Me gustaría compartir con vosotros algunos aspectos aprendidos a la marcha y que os podrían sacar de un buen lío.
Para empezar, os aconsejo echarle un ojo al siguiente KB de VMware para abordar la planificación de vuestro Upgrade.
https://kb.vmware.com/s/article/2147686
Pues bien, os voy a contar nuestra experiencia sobre el Upgrade:
El primer día habíamos realizado el cambio de arquitectura necesario para poder realizar la migración de 5.5 a 6.5, externalizando el SSO 5.5 y creando un único dominio de SSO. Posteriormente migramos los SSO Externos 5.5 a PSC 6.5, reapuntando los Virtual Center en 5.5 a los PSC Externa 6.5. Hasta aquí todo correcto.
El segundo día, empezaba lo serio!! Teníamos que migrar los Virtual Center sobre Windows en versión 5.5 (cabe reseñar que tenía particionado en máquinas virtuales los servicios de Update Manager/Web Client, AutoDeploy, Syslog/Dump Collector), con BBDD Externa a VCSA 6.5 con BBDD embebbed. Como eran dos sites los que teníamos que migrar, nos pusimos manos a la obra con el primer site. Todo fue de 10!!!! Ya teníamos migrado un Site totalmente a versión 6.5 U1. Genial!!!!
Seguimos con la migración del otro Site y nos encontramos con el primer “Failed”. El error nos dió en la migración de vSphere Update Manager (en concreto en el registro de vmware.vcIntegrity), indicando que la BBDD estaba corrupta. Pues bien, como habíamos sido precavidos teníamos snapshots de todas las máquinas, por lo que tuvimos que realizar la vuelta atrás de ese Virtual Center. Revertimos snapshots y tuvimos que sacar/meter en dominio el Server. Una vez volvíamos a tener otra vez el Virtual Center 5.5 arriba. Nos pusimos a investigar la causa del error. Tras leer varios post y KB de VMware, decidimos realizar la desinstalación de Update Manager y desregistrar el componente y plugin del mob, más info aquí.
Bueno tras solventar ese problema, decidimos lanzar otra vez la herramienta de migración. Y pasados unos minutos, tras exportar la info. falla en el registro e inicio de servicios en el VCSA 6.5. El error era previo al error anterior de VUM. El error no erá muy aclarador “VMware Virtual Center failed firsboot registration failed with Component Manager failed”.
Como habíamos hecho antes, volvimos a realizar la vuelta atrás. Y comenzamos a investigar sobre este error. Encontrábamos poca información y la mayoría no aplicaba totalmente a nuestro problema. La mayoría se centraba en que el VCSA no era capaz de encontrar el servicio debido a que tenía habilitado ipv6. Por lo que si hacía un ping dentro del VCSA al localhost, te respondía por ipv6.
Pues bien, indicaban que en la migración tras el paso 1 (Despliegue de la máquina que será tu VCSA), mediante consola de VMware, accedas y añadas una línea a /etc/hosts. Pues bien, lo hicimos y nada! Volvimos a realizar la vuelta atrás y decidimos deshabilitar ipv6 en el Origen, en el Virtual Center Server 5.5 de Windows. Tampoco funcionó!! Llegados a este punto, abrimos caso con VMware y subimos los logs que volcaba la Migration Tool, pero mientras debíamos de seguir buscando una solución.
Pues después de mucho buscar, leer varios KBs, varios post, encontramos la información correcta e idónea. Gracias a Ken Umemoto por su post!!!!
Pues bien, leyendo el post indica que debemos de buscar en el log vpxd_firstboot.py_XXXXX_stdout.log volcado por la migration tool tras el fallo. Y encontramos el fallo que indicaba Ken en el post:
2017-08-2017T17:47:05.355Z Component Manager registration failed - {
"resolution": null,
"detail": [
{
"args": [
"Service already registered in Component Manager; url:http://localhost:18090/cm/sdk/?hostid=653dda22-3b38-4c5a-a7eb-025953797e2e, id:23790D50-6137-490E-A590-F4E04718FAD1"
],
"id": "com.vmware.cisreg.svc_already_registered",
"localized": "The service is already registered:Service already registered in Component Manager; url:http://localhost:18090/cm/sdk/?hostid=653dda22-3b38-4c5a-a7eb-025953797e2e, id:23790D50-6137-490E-A590-F4E04718FAD1",
"translatable": "The service is already registered:%(0)s"
}
],
"componentKey": "cm",
"problemId": "com.vmware.cisreg.svc_already_registered"
Pues bien, teniendo esa salida debemos quedarnos con el id del servicio que el Component Manager encuentra ya registrado. Ahora utilizaremos la herramienta que hasta hace unos días, desconocía de su existencia JXplorer. En el blog de Ken Umemoto podéis encontrar más info sobre la herramienta, aquí.
JXplorer mediante una conexión a nuestro PSC, nos permite consultar mucha información sobre servicios, host registrados, etc.
Pues bien, instalamos la herramienta y realizamos la conexión a nuestro PSC. Para ello:
Host: IP o FQDN de nuestro PSC
Protocol: LDAP v3
Base DN: dc=vsphere,dc=local
Level: User + Password
User DN: cn=Administrator,cn=Users,dc=vsphere,dc=local
Una vez conectados, veremos el árbol de componentes de nuestro PSC, podemos localizarlo si navegamos sobre el árbol, como vemos en la foto:
También podemos localizarlo realizando una búsqueda por el id que hemos apuntado antes del log:
Una vez localizado, clic en botón derecho y eliminamos el servicio malicioso registrado.
Posteriormente lanzamos por última vez la Migration Tool y terminó correctamente!!!!!
Espero que os sirva de ayuda al igual que a nosotros. En siguientes posts os contaré otras experiencias que tuvimos con el Upgrade y cómo lo solucionamos.
Muchas gracias por compartir 😉
Gran post si señor!