Cómo desplegar Prism Central (parte 1)

Vamos a ver el despliegue del Prism Central, tarea aparentemente simple, pero que si no está clara a nivel de networking, puede dar mucha guerra. Pues nada, ¡empezamos!

El primer paso es acceder a nuestra contola de Prism Elements (PE), y en el Dashboard principal, pinchamos sobre "Register or deployNew Prism Central"

Pulsamos  sobre la primera opcion, "I want to deploy a new Prism Central instance":

 

 La primera pantalla te pedirá el nombre de tu VM y te dará la opción de seleccionar la imagen a desplegar o, si no tienes ninguna, a subirla, si pulsamos sobre "Upload Installation Binary" 

 

Antes de continuar con la subida de archivos, un detalle importante: En la web de descarga de Nutanix debes descargar la versión "Prism Central 1 click deploy from Prism Elements"

Cuidado aquí: justo debajo de Download, hay un link, "Metadata", muy fácil de ignorar. Pincha también en él para descargar el archivo de metadata de la versión de Prism Central (PC) que estamos descargando:

 

Volvemos 2 capturas atrás, cuando pulsábamos sobre "Upload Installation Binary". Ahora ya tenemos los elementos necesarios para la subida. Agregamos cada uno en su sitio, y pulsamos Upload:

 

 Una vez termine de subir, estamos en disposición de seleccionar la versión descargada de PC, y continuar:

 

El siguiente paso será elegir las dimensiones de nuestro PC. Es importante tener en cuenta su consumo en base al despliegue elegido, puesto que puede requerir mas recursos de los esperados. En nuestro caso, desplegaremos una versión Small, aunque para instalaciones simples tenemos la Extra-Small

 

Llegamos a un punto critico por su importancia, aunque simple en su despliegue: la detección de red de nuestro PC. Ten en cuenta que debe estar en la red de management. Si no tenias una red separada para tu trafico de VMs, la creas. Pero eso es otra historia. Si no tienes nada creado, por defecto tu red de management seguramente esté untagged, sin VLAN ID, de manera que esta pantalla es solo para que veas un ejemplo de lo que te vas a encontrar. Sí que es cierto que no te va a funcionar en red default, en cuyo caso tendrás que crearte la management subnet sobre el mismo vSwitch que la red de tu clúster, y sin tagear. Ah, NO MARQUES IPAM, normalmente vas a tener una IP asignada:

 Unos detalles

 

 Y con esto, ¡hemos llegado al despliegue!.

El post sale un poquito largo, y hasta aquí hemos conseguido realizar el despliegue de la VM, así que en la segunda parte veremos cómo finalizarla, algo de troubleshooting,  y su unión al clúster.

Cómo eliminar una VM en Nutanix via CLI

Este post iba a ser originalmente "cómo eliminar un Prism Central" debido a un problema de redes en el despliegue del mismo. Spoiler: si el Prism Central se ha desplegado pero no se ha podido registrar con absolutamente nada por problemas de redes, se puede tratar como una VM normal y corriente. Esto le quita un poco de color a este articulo, pero bueno, siempre es interesante conocer cómo eliminar una VM via CLI, sin acceso al interfaz web.

Para ello, hacemos login en una CVM con permisos de administrador y ejecutamos el siguiente comando:

acli vm.delete "nombre de la VM" 

No tiene mas, hasta la sintaxis es intuitiva. Os dejo una captura de pantalla del proceso:

No es mala idea ejecutar un "acli vm.list" para verificar el borrado de la VM, aunque en este caso lo verifiqué via GUI.

Si bien pudimos tratar el despliegue fallido de PC como una VM común, es fundamental entender el flujo correcto cuando Prism Central ya ha estado en uso.
Si Prism Central se ha registrado previamente con uno o más clústeres, NO debe eliminarse simplemente como una VM. Antes de borrar la VM, debe des-registrar PC del clúster a través de los pasos recomendados por Nutanix para evitar que los clústeres queden huérfanos o con referencias inconsistentes.

Aun así, dejaré un par de enlaces del proceso:

Aquí se puede ver como des-registrar Prism Central, previo a ningún tipo de borrado:

https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e000000XeZjCAK

Este otro enlace es ya para el borrado de la VM en sí: 

https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e000000LKnuCAG

Así fue el .Next on Tour Madrid 2025

El pasado .NEXT On Tour Madrid, celebrado en el impresionante Estadio del Atletico, el Riyadh Air Metropolitano, fue sin duda uno de esos eventos que recuerdas durante mucho tiempo. Nutanix volvió a reunir a partners, clientes y entusiastas de la plataforma en una jornada llena de anuncios, sesiones inspiradoras y, sobre todo, una sensación de comunidad que cada año crece más.

Desde el primer momento se notaba que era un evento muy cuidado: organización impecable, ponencias muy bien preparadas y una asistencia masiva que reflejaba el gran momento que vive Nutanix en España. Tanto si trabajas con Nutanix a diario como si estás empezando a conocer el ecosistema, era imposible no salir del evento con nuevas ideas y mucha inspiración.

Y es que,¿puede haber un sitio mejor para un evento tecnológico que un estadio de fútbol de primer nivel? El Metropolitano ofrecía un ambiente espectacular y unas vistas que convertían cualquier pausa en una oportunidad para hacer networking… o simplemente para admirar el entorno.

Las charlas fueron el plato fuerte del día. Estuvieron divididas en dos sesiones principales, primero una para Partners y posteriormente tras un breve receso para un café con algo de repostería, la sesión para clientes, donde se trataron temas clave como la evolución del cloud híbrido, la estrategia de Nutanix para los próximos años, casos reales con clientes y mejoras en la plataforma que o bien ya son accesibles, o bien llegarán próximamente, como esa mayor compatibilidad con cabinas de discos externas.

Como siempre sucede con Nutanix, cada presentación estaba cuidada al milímetro. Contenidos claros, actualizados y centrados en aportar valor real.

No todo iba a ser tecnología, también hubo espacio para recargar energías con un catering estupendo. Un detalle que se agradece en un día lleno de sesiones y conversaciones.

Además, tanto en los pasillos como en la sala principal, había un ambiente magnífico: partners reencontrándose, clientes compartiendo experiencias y muchos profesionales descubriendo nuevas oportunidades dentro del ecosistema Nutanix. ¡Estaba tan lleno que habia gente del sector a la que no veia en años, y pude volver a verles de nuevo!

En resumen: el .NEXT On Tour Madrid 2025 no solo confirmó el excelente momento de Nutanix, sino también la fuerza de su comunidad en España (lo que me recuerda que se está levantando la comunidad de usuarios de Nutanix, accesible desde la web de www.nutanix4ever.com y desde la que podreis acceder a sus foros y canales de WhatsApp, para informaros de todo tipo de novedades, asi como participar en conversaciones sobre esta tecnología).
Un evento completo, bien organizado y que deja ganas de volver el próximo año. 

Si estuviste allí, seguro que coincides conmigo. Y si no… ¡no puedes faltar a la próxima edición! Como dice la foto, ¡Nutanix, gracias por todo!

Cómo cambiar la contraseña de root en todos los hosts AHV de un clúster Nutanix (de una sola vez)

Hay tareas que, aunque no se hacen todos los días, conviene tener bien documentadas para no sufrir más de lo necesario. Una de ellas es cambiar la contraseña de root en los hosts AHV.

Y si alguna vez has tenido que hacerlo host por host, sabrás que es fácil equivocarse, es repetitivo, se tarda un tiempo entre que vas saltando de CVM a CVM... y luego los imprevistos que saltan por motivos desconocidos, posiblemente los bogones (toquecito de humor viejuno, sorry, no pude evitarlo).


Por suerte, Nutanix nos permite ejecutar comandos de forma unificada desde una CVM, y con ello podemos actualizar la contraseña de root en todos los hosts del clúster con un único script.

Aquí está la magia:

echo -e "CHANGING ALL AHV HOST ROOT PASSWORDS.\nPlease input new password: "; read -rs password1; echo "Confirm new password: "; read -rs password2; if [ "$password1" == "$password2" ]; then for host in $(hostips); do echo Host $host; echo $password1 | ssh root@$host "passwd --stdin root"; done; else echo "The passwords do not match"; fi

 

He metido un "ls" para dar un poquito de colorido...

¿Qué hace exactamente este comando?

Vamos a desgranarlo paso a paso, para que tengas claro cómo funciona y por qué es tan útil.

1. Solicita la nueva contraseña: Te pedirá la nueva password para root de forma silenciosa (no se muestra en pantalla): Please input new password:
2. Pide confirmación: Para evitar errores humanos —que los hay, y muchos—, te solicita el mismo password nuevamente: Confirm new password:
3. Comprueba que ambas coinciden: Si las dos entradas coinciden, continúa.. Si no coinciden, aborta la operación y te lo dice claramente: The passwords do not match
4.  Obtiene la lista de hosts AHV: Utiliza el comando hostips desde la CVM, que devuelve todas las IP de los hosts del clúster.
5. Recorre host por host y cambia el password: Para cada host, ejecuta: ssh root@$host "passwd --stdin root" Esto envía la nueva contraseña directamente al comando passwd del host, sin interacción manual.

¡Y listo! En apenas unos segundos tendrás todos los hosts AHV sincronizados con la misma contraseña root, de forma limpia y automatizada.
 

 Precauciones importantes

Antes de lanzarte a ejecutar el script, considera:

• Asegúrate de tener acceso SSH sin problemas desde la CVM a los hosts.
• El usuario root debe estar habilitado en los hosts AHV.
• Si utilizáis un password vault corporativo, documenta la nueva contraseña.
• Si hay automatismos o herramientas externas que usen la password de root (monitorización, scripts, integraciones), recuerda actualizarlos.

En resumen, cambiar el password de root en un clúster AHV ya no tiene por qué ser una tarea tediosa o manual. Con este pequeño script, puedes mantener todos los hosts alineados en segundos, mejorar la seguridad y ahorrar tiempo.

Guárdalo bien: te aseguro que volverás a necesitarlo tarde o temprano.

Desbloquea el usuario y cambia el password admin de Nutanix

Seguro que te ha pasado —porque nos ha pasado a todos— que, tras una primera instalación de un clúster Nutanix, intentas acceder al dashboard de Prism y empieza la fiesta de combinaciones imposibles:

• Primero pruebas con aDMIN
• Luego con admin
• Después con la clásica Nutanix/4u
• Luego lo mismo, pero todo en minúsculas
• Más tarde te acuerdas de ese password que jurabas haber puesto la primera vez…
• Y finalmente recuerdas que ya lo habías cambiado hace semanas…

Y, para cuando te das cuenta, el usuario está bloqueado y tú te has quedado mirando la pantalla como si Prism fuese a tener piedad de ti.

La buena noticia: no hay necesidad de esperar al desbloqueo automático

Por defecto, el usuario admin se bloquea temporalmente tras varios intentos fallidos de autenticación. El bloqueo se levanta solo, sí… pero a veces no tienes tiempo para esperar, o simplemente no quieres estar mirando al infinito.

Asi que lo que vamos a hacer es conectarnos a cualquier CVM, y ya desde ahí puedes ejecutar un comando que limpia los intentos fallidos y desbloquea el usuario al instante:

allssh 'sudo faillock --user admin --reset'

En cuanto lo ejecutes, el usuario admin quedará desbloqueado manteniendo su contraseña actual, sin necesidad de cambiar nada más.

Y ya que estamos… quizá es buen momento para cambiar la contraseña

Si el bloqueo ha ocurrido porque ni tú mismo recuerdas la clave de admin, probablemente sea el momento perfecto para establecer una nueva.

Desde la CVM, simplemente ejecuta:

sudo passwd admin

Se te solicitará introducir la nueva contraseña dos veces. Solo recuerda que no puede ser la misma que la anterior (las políticas de seguridad de Nutanix no perdonan).

En la captura que acompaña este post podrás ver todos los comandos ejecutados paso a paso. Es realmente sencillo, pero te puede salvar de más de un susto en medio de una puesta en marcha o una noche de mantenimiento.

Consejo adicional

Aprovecha para documentar la contraseña en el sistema que utilicéis en tu empresa: gestor de contraseñas, vault, fichero seguro… lo que sea. Te ahorrarás este mismo episodio dentro de unos meses.

Editar la configuración de la IPMI cuando no tenemos acceso

 No se si os habrá pasado que se solicita una configuración de un cluster tageada para una determinada VLAN, y se pierden accesos por temas de tageo de switches, firewalls, y decisiones de quien lleva qué configuración. Finalmente, decidimos quitar la VLAN de la IPMI, pero, claro, no hay forma de acceder, aunque tenemos conexión con el cluster de Nutanix.

Solución: acceder a la IPMI via host. 

Para ello, lo primero que vamos a hacer es conectar via SSH a la CVM. Vale perfectamente con el usuario "nutanix", aunque será deprecado en futuras actualizaciones, ya que es el "por defecto" y al final se convierte en un fallo de seguridad". Que si tienes tu usuario root configurado del host, directamente te puedes saltar este paso.

De la CVM saltamos al host con un "ssh root@ip-del-host". Esto nos permite entrar como root al host y por tanto, con accesos a la red interna de Nutanix 192.168.5.x. 

Desde aquí, ya podemos lanzar el comando "ipmitool lan print 1" que nos mostrará la configuración de la IPMI.

Para cambiar la ip de la IPMI, estos 3 comandos son vitales:

"ipmitool lan set 1 ipsrc static" - Esto nos permitirá dejar la red con IP estática, que no reciba asignación por DHCP

"ipmitool lan set 1 ipaddr x.x.x.x" - Definimos la IP que tendrá nuestra IPMI

"ipmitool lan set 1 vlan id off" - Deshabilita la configuración de vlan. Si tenia una VLAN configurada, la quita. El mismo comando, reemplazando el "off" por el numero de VLAN, fija esa VLAN para la tarjeta

Se puede ver un listado completo de comandos en: https://portal.nutanix.com/page/documents/kbs/details?targetId=kA0600000008T3jCAE

DevOps, SecOps, acrónimos en general, o el 2x1 de IT

A diferencia de los artículos habituales, esta vez quiero dejar una reflexión sobre este nuestro mundillo de la informática, cada vez más extenso y a la vez especializado.

El dilema es universal: en TI, todo son acrónimos. Son rápidos, suenan modernos y prometen una integración mágica. Desde que DevOps nos vendió la promesa de la armonía, las ofertas de empleo se encuentran inundadas con DevSecOps, SecOps, FinOps, DataOps...

Pero seamos honestos: añadir una letra al título no es lo mismo que crear un súper-ingeniero. Es mas bien una excusa para la sobrecarga de trabajo.

Pregúntate esto: ¿Cuántos de estos nuevos roles están fallando en tu equipo y por qué?

El Mito del "Unicornio": Cuando la Especialización se Diluye

Buscamos al profesional que pueda escribir código de producción impecable (Dev), desplegarlo automáticamente (Ops) y garantizar su seguridad y cumplimiento normativo (Sec). Este perfil es el unicornio, y la utopía se rompe por una simple ley humana:

El Developer Nace para Crear, No para Custodiar: Su talento está en la lógica de negocio y la velocidad. Si obligas a un desarrollador a gestionar alertas de infraestructura de bajo nivel o a pelear con reglas de firewall a las 3 AM, su productividad —y la calidad del código— caerán en picada. El resultado: frustración y código pobre.

El Operations, Forzado a Ser Programador: El ingeniero de infraestructura, excelente gestionando la red o la virtualización, es ahora forzado a dominar Python o Go para IaC (Infraestructura como Código). Esto diluye su foco y genera automatizaciones frágiles y difíciles de mantener. ¿No te has preguntado por qué esa automatización siempre falla?

El Caso de SecOps: Vigilancia sin Autoridad

El acrónimo SecOps es un ejemplo clásico de la fragmentación que se intenta resolver. El equipo de seguridad se centra en el monitoreo y el compliance, pero...

Se les pide que vigilen el castillo, pero se les niega el permiso para abrir o cerrar las puertas.

Si tu SecOps identifica una brecha crítica en un clúster de vCenter o en la arquitectura de un storage, pero la gestión de la infraestructura subyacente sigue residiendo en un silo diferente ("Infraestructura Clásica"), la velocidad de reacción se anula. El costo de la "reacción inmediata" es devorado por la burocracia departamental.

La Verdad Oculta: La Utopía Falla por Liderazgo, No por Rol

Dejemos de culpar a los ingenieros. El fracaso de la fusión de acrónimos es un fallo estructural de cultura y liderazgo.

El mayor error es intentar resolver un problema de comunicación con una nueva etiqueta de puesto. Tu organización contrata a una "persona DevOps" y la convierte en el chivo expiatorio al que se le asigna la tarea que nadie más quería hacer.

DevOps no es un título; es un sistema de trabajo. Si tu cultura no promueve la confianza, la responsabilidad compartida y un tooling unificado, el mejor ingeniero DevSecOps del mundo seguirá siendo un solo hombre contra tres departamentos en guerra.

Conclusión: Dejemos la Nomenclatura, Abordemos la Colaboración

La respuesta a la complejidad de TI no está en un puesto de trabajo más largo. Está en la disciplina para reconocer y potenciar las especializaciones:

Dev debe centrarse en la Calidad del Código y el Valor de Negocio.

Ops debe dominar IaC, tratando la infraestructura como un producto de software.

Sec debe integrarse en el ciclo de vida (Shift Left), no actuar como el policía de aduanas al final del proceso.

El verdadero éxito no es que una persona lo haga todo, sino que los equipos usen herramientas y procesos comunes para que el flujo de valor sea la única métrica que importe. ¡Deja de buscar al superhéroe de los acrónimos y exige el liderazgo que consigue que los equipos colaboren sin esfuerzo!