TODO POR UNA VLAN!!!

Que tanta importancia le damos a una VLAN faltante? Que impacto puede tener no tener un ID configurado? Son creo que una de las preguntas que nos vamos a hacer todos antes de morir. O despues de querer darle con la palma de tu mano en forma de caricia pero a la velocidad que hace el servicio Nadal....

Normalmente uno puede matarse buscando los motivos y/o encontrar las conclusiones de porque pasan las cosas en las infras que implementamos y están muy funcionando armónicamente hasta que te dicen.. debemos cambiar esto.. o llego esta parte y la quiero tener funcionando ya mismo. Y ahí es donde uno dice, pero tenemos que tener esto en cuenta... o la famosa frase tenemos que pedir ventana por las dudas.. y ahí es donde, Pero si la magia de la virtualización es que no necesitas gestionar cortes!!!.... y asi seguiríamos con miles de escusas y motivos...

Pero lo importante de esto es conocer esta experiencia vivida.

Hasta hace poco me llega un pedido de migrar servicios de MGMT, VMOTION y VSAN a los nuevos puertos de 10GB que llegaron y que satisfactoriamente lograron instalar en 4 host.

Y ahí es donde decís bueno hacemos el plan de acción y arrancamos.

Entonces empiezan los interrogantes y responsabilidades. Hay que configurar las VLANs.. decis, ya que estamos también configuremos los Port Channels y también pongamos LACP. Hasta que alguien dice.. dale conectémonos a la matrix.... ¬¬.

Desde el vCenter se empieza a crear el DVS correspondiente para los nuevos UPLINKs. Luego los DPG para las respectivas VLANS con sus correspondientes IDs. Luego de esto configuras tu LAGs con el failover. Luego te confirman que los puertos están configurados y las VLANs también. Entonces genial decis y comenzas a migrar los servicios. Empesas con lo mas fácil el MGMT, y migra si problemas y asi continuas con el resto de los demás host. Luego VSAN y migra sin inconveniente... peroooo aca esta el problema.... Un vmk de VSAN no tiene un rolback en caso de fallar y no te das cuenta hasta que todo tu cluster de VSAN se cae, y con su caída se caen las VMs entre ellos el vcsa que lo mejor de todo dan servicio a una granja de Horizon. Y por suerte solo fue eso ¬¬. Ahí es donde recordas la parte que les dijiste que lo ideal sería una ventana. Entonces.. como resolvemos esto que gran pregunta.

• Debemos recuperar el cluster de VSAN que perdió conectividad entre todos y como hacemos eso?.
• Logueandonos a todos los host por SSH y borrando el VMK dedicado a VSAN con el comando esxcfg-vmknic -d vmk_name
• Luego lo recreamos en los puertos que anteriormente funcionaba.
• Con esto todas las VMs y VCSA deberían re aparecer consolidados.
• Por ultimo reiniciar el VCSA, para que los servicios inicien adecuadamente.
• Ya tenemos el vCenter operativo. Y es donde comenzas a re verificar tus configuraciones del DVS, pero en conclusión te das cuenta que tu MGMT y VMOTION nunca se cayeron. Entonces apuntas a los switch físicos.
• Luego de dicha caída el servicio de Horizon se cayo automáticamente por perder contacto con el vCenter y con las VDI. Que debemos hacer?.
• Reiniciar la VM de Horizon
• Rehabilitar los grupos configurados en Horizon.

Pero este ultimo comienza a fallar, no pudieron re sincronizarse, ni aprovisionar nuevas VMs, Intentas hasta que descubre que las VMs de CP-PARENTS, CP-REPLICA y CP-TEMPLATES están en modo huérfano.

Lo mejor es que dichas VMs no son editables ya que poseen Disables Methos configurados, entre ellos no poder des-registrarlas para volver a registrarla. A lo que recordemos que dichas vms con snaps configurados por Horizon!!! Entonces cmo resolvemos esto!!!

A borrar el Desktops para que elimine las CP. Perfecto.. pero no... están huérfanas.. horizon no puede borrarlas, ni tampoco puedes hacerlo desde vCenter. Entonces aca es donde encontré la magia.

Primero, ya enviaste a borrar el desktop pool en horizon, pero este mismo se encuentra tildado digamos... y no desaparece. Entonces debemos seguir parte dicho workarround.

https://jacob.gardiner-moon.co.uk/2016/08/15/removing-vmware-horizon-view-desktop-pools-stuck-in-deleting-stage/

Es simple en mi caso solo tuve que conectarme por ADSedit realizar la conexión al dominio de horizon y buscar el CN del destop pool que se encuentra en la OU server groups y moverlo a la OU de LostandFound. Y Luego de esto su Desktop Pool desaparece de su consola de Horizon. Pero todavía nos queda algo. Que hacemos con las CP vms. Huérfanas. Como las borramos??.

• Nos conectamos por SSH a nuestro VCSA.
• Utilizamos la consola DCLI https://virtualvillage.cloud/?p=853 Cuando queremos borrala ahí nos va a decir que dichas VMs poseen el Method Horizon.daas entonces ahora debemos acceder a la DB de Postgres.
• Como accedemos a la BD https://www.vmwarearena.com/basic-commands-interact-vcsa-6-5-embedded-vpostgres-database/. Si como accedemos solamente... pero necesito borrar el Disabled Methods de las VMs.
• Acá esta la magia. En el punto 2 con DCLI tomamos los vmid de las VMs que deseamos borrar y con eso debemos ejecutar dicha línea:

delete from VPX_DISABLED_METHODS WHERE ENTITY_MO_ID_VAL = 'vm-'

• Luego de borrar los Disabled Methods de las VMs debes reiniciar los servicios con.... Service-control -stop -all y luego service-control -start -all.
• Volvemos al DCLI y ahí si podemos eliminar las VMs.
• Y por último nos quedó reconfigurar el nuevo Desktop Pool en Horizon para dejar nuevamente la infraestructura funcionando.

Que paso con la VLAN.. no había sido creada... ¬¬ por ende.. se dan cuenta que tan importante puede ser una VLAN?.

Gracias por tu Lectura!! Nunca dejes que reinstalar sea la primera opción!!!.. Que mejor que no sea ninguna de las opciones. Luego de cada experiencias encontraras mil fomas de resolver cada problema y complementaras tus conocimientos y la satisfacción sera mejor que borron y cuenta nueva!!!