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!

Cómo apagar un único nodo de un clúster Nutanix

Puntualmente podemos encontrarnos en la necesidad de tener que apagar los nodos de manera individual, con el fin de realizar algún tipo de mantenimiento sobre el mismo, como por ejemplo, un incremento de RAM.

Para esto, no hace falta apagar el clúster, sino que simplemente pondremos el nodo en mantenimiento. El sistema se encarga de balancear las VMs a los otros nodos. Todo este proceso se realiza desde la consola de administración de Nutanix. En este caso, sobre un Nutanix CE, realizo los pasos sobre Elements.

En el menú superior nos vamos a "Hardware". Por defecto, entra en la pestaña Overview. Nos vamos a "Table", y ahí podremos ver nuestros hosts. Pinchamos sobre el que vamos a apagar, y veremos una serie de opciones en el menú inferior. Una de ellas es "Enter in maintenance mode. Pulsamos el botón, y aparecerá el mensaje que tienes en pantalla, donde avisa del balanceo de las máquinas en ejecución.

Este proceso no es instantáneo, hay que darle tiempo al clúster, y esperar hasta que veas que está sin actividad, algo así:

IMPORTANTE: poner en mantenimiento el host APAGA la CVM. Los servicios relacionados con Prism se delegaran a otra CVM, si diese la casualidad que la CVM del host que vamos a apagar estuviera funcionando como controller de Prism Elements.

Seguidamente, tenemos que detener el host. Para ello, nos conectamos via SSH a otra CVM del cluster.con nuestro usuario nutanix, por ejemplo. Cambiamos a Bash, y ejecutamos los siguientes comandos:

ssh root@IP_del_host_AHV

shutdown -h now

Con esto, se apaga el host de manera controlada:

Si lo tenemos virtualizado, como es este caso, donde trabajo sobre nested host en ESXi, aparecerá la VM apagada

Supongamos que trabajamos sobre un host físico: el proceso es el mismo, solo que podríamos apagar de manera controlada el hipervisor tirando de iDrac, ILO o IPMI.

Para arrancar de nuevo el host, encendemos la VM y esperamos a que nos muestre el prompt de login, y desde Prism sacamos al nodo de mantenimiento:

En cuanto veamos que nos da en Prism la IP de la CVM, podemos abrir una conexion ssh contra la CVm que tiene que haber levantado ya, accedemos con nuestro user nutanix, y escribimos "cluster status". Si todo fue bien, nos anunciará un "Cluster succeed"

¡Ya está! ¡No tiene mas!

Recapitulando: ponemos en mantenimiento el nodo, entramos por ssh a la CVM de otro nodo, nos conectamos al AHV del nodo que vamos a apagar, lanzamos un shutdown, hacemos lo que tenemos que hacer, arrrancamos el host, y sacamos de mantenimiento.

Así fue el evento del VMUG + VEEAM + OOTBI del 24 de septiembre

El pasado 24 de septiembre tuvimos la oportunidad de vivir una jornada muy especial en Madrid: un encuentro conjunto entre dos comunidades con mucho en común y con enorme energía, el VMware User Group (VMUG) Madrid y el Veeam User Group (VUG Spain). A esta cita se unieron además nuestros amigos de Object First, sumando conocimiento y entusiasmo a una agenda que resultó intensa, completa y, sobre todo, tremendamente enriquecedora.

Desde el primer momento, la respuesta fue espectacular: no es que se completara el aforo, ¡es que tuvimos que ampliar el número de asistentes previstos al evento! Y claro, esto hizo que el ambiente de networking fuera excelente desde el inicio. Profesionales de diferentes sectores, pero con intereses compartidos, llenaron la sala con preguntas, comentarios y muchas ganas de aprender.

Agenda y ponentes de lujo

La jornada comenzó con una sesión sobre las novedades de VMware Cloud Foundation (VCF), de la mano de Mario Pessini, quien nos ofreció una explicación clara, directa y práctica de hacia dónde evoluciona la plataforma y cómo impacta en el día a día de los entornos empresariales.

Después llegó el turno de Veeam Software, con Víctor Pérez de Mingo, quien nos introdujo las novedades de la última versión de Veeam y su enfoque en garantizar la resiliencia de los datos en un contexto cada vez más desafiante.

Tuvimos un invitado de honor de Veeam, Andrey Stadler, quien nos habló de Veeam One y trucos esenciales para su uso. Aunque es alemán, se entiende bien con el español, y está encantado de hablar con la comunidad para recibir feedback del producto:

Por último, cerró la agenda Miguel Tena Martín, que nos habló de Object First (OOTBI) como la solución perfecta de almacenamiento inmutable que complementa y potencia la estrategia de backup y recuperación con Veeam.

Lo que diferencia a un encuentro de comunidad

Uno de los puntos más valorados por todos los asistentes fue la cercanía: no se trató de un evento puramente comercial, sino de una ocasión para aprender, compartir y debatir en confianza. El formato permitió lanzar preguntas, comentar experiencias reales y obtener respuestas directas de expertos, algo que distingue de forma clara a los eventos impulsados por las comunidades frente a los dirigidos exclusivamente a clientes.

Sabemos que muchos de vosotros querréis volver a repasar las sesiones, así que hemos preparado los materiales del evento.

Aquí tienes las presentaciones de todos los ponentes para que podáis consultarlas y utilizarlas como referencia.

VCF 9.0 What's New Technical (VMUG)

VUG Madrid - VBR V13 What's New

VUG Madrid - 10 tips for Veeam ONE

Object First_VUG MAD

Desde el equipo de VMUG Madrid y el VUG Spain, solo podemos dar las gracias a todos los asistentes, a nuestros ponentes y a nuestros colaboradores. La participación y la energía fueron las que realmente hicieron que este evento fuera “simplemente brutal”.

¡Nos vemos en el próximo encuentro!

Por cierto, recordad que podeis uniros a la comunidad de VMUG Madrid por WhatsApp, desde este enlace: https://chat.whatsapp.com/Kys7MITZVK37I8vTiNwfYj?mode=ems_share_t

Actualiza tu perfil de Broadcom para poder ejecutar los HOLs

Estoy seguro que todos habéis visto las comunicaciones indicando que para acceder a los HOLs, ya no se podrán utilizar cuentas de correo de tipo Gmail y similares, sino que tendrás que utilizar tu cuenta de empresa con ese fin. Pero es que si tu cuenta ya era de empresa, aun así tienes que modificar tu perfil para obtener acceso a los Hands on Labs. Las instrucciones son las siguientes:

1. Step 1: Register or Login to Broadcom Support
2. Step 2: Enable Hands-on Labs AccessOnce Logged in, click your User Account [Upper Right]
• Click My Profile
• Click Yes, I want to Build my Profile
• Check Broadcom Software
• Click VMware Hands-on Labs
• Complete the form and click Submit

Muy resumidas, las instrucciones son:

Vete a support.broadcom.com y haz login. 

Vete a tu profile, y das a Build mny profile, aunque ya sepas que tienes el profile creado:

Prácticamente en la cabecera, veras que tienes "Broadcom Software, pero desmarcado "VMware Hands on Labs access". Marcamos la casilla, y abajo del todo, pulsamos en Confirm and Continue:

Tras confirmar, te dirá que ya está hecho, y veras que el acceso a los HALs ahora aparece en tu profile:

Recibirás un mail como este, confirmando tu acceso:

Las instrucciones con capturas paso a paso puedes encontrarlas AQUI.

Tras ver que se ha completado correctamente, podrás acceder a los HALs sin problemas.

https://labs.hol.vmware.com/

Expandir un cluster Nutanix con un nuevo nodo

 A la hora de crear un cluster con Nutanix CE, no queda otra que hacerlo via cli, ya que perdemos la capacidad de generarlo con Foundation. Pero, ¿Y si queremos expandirlo?

Nutanix CE permite crear un cluster de 1 nodo, un cluster de 2 nodos, y luego el cluster minimo recomendado, de 3 nodos. Pero puedes expandirlo hasta los 4 nodos. Y eso es lo que vamos a hacer ahora.

Aunque via cli, lo que encontramos en la documentacion de Nutanix es que "Expand cluster using ncli is disabled by default in AOS 6.1.1 or later", significa que poder, podriamos hacerlo, pero que es mas facil si lo hacemos via Prism. Para ello, entramos en nuestro Prism Elements, y nos vamos al icono de settings, a la derecha de la barra de menú:

En el apartado de la izquierda, veremos la opción "Expand Cluster". Pinchamos en ella.

Seleccionamos la primera opción de las 2 que nos da. La segunda seria para realizar la instalacion del hipervisor en un nodo no preparado todavia. Super cómodo en entornos reales, pero aqui lo que estamos haciendo es agregar una VM que ya preparamos previamente, y pulsamos Next:

Lo primero que nos pide es seleccionar el host. En este caso solo tenemos una preparada, asi que en el autodiscovery que hace solo localiza 1, pero de tener varias, verifica la que quieres agregar a partir de su serial number. En el CVM que vamos a agregar, nos basta hacer un "hostname" para averiguar el serial number, ya que es lo que pone por defecto al crear el nodo. Pulsamos Next

En el siguiente paso, seleccionamos el tipo de nodo. Vamos a generar un nodo tipo HCI, y Next

En el siguiente paso no tenemos que hacer nada, al estar ya todo en la misma red. Continuamos:

Finalmente, podemos ejecutar los checks iniciales, o ejecutar la adicion del host al cluster. Va a hacer los check igualmente, antes de agregarlo, asi que a tu eleccion. Lo peor que puede pasar en caso de fallo es que no se agregue el nodo y todo se quede igual que al principio, asi que dale sin miedo.

Como veis, el proceso ha variado ligeramente con respecto a hace unos años, pero en líneas generales, es fácil.

Cómo crear un cluster Nutanix CE nested

 ¡Vamos con un poco de cacharreo! Y qué mejor para cacharrear que montarte un entorno de laboratorio virtual? Vamos a ver cómo podemos montarnos un clúster de 3 nodos Nutanix con la Community Edition.

Lo primero de todo, tendremos que descargarnos los elementos necesarios para ello, y en este caso y yendo a lo simple, nos bastará con la ISO del AOS. De manera que hacemos login en my.nutanix.com (si no tienes cuenta, te la creas, es gratis) y pinchamos en el apartado Community Edition.

Os vais a encontrar las instrucciones de descarga e instalación, pero planteadas para un entorno físico. En este caso, nos descargamos de AQUI la ISO, y continuaremos de otra manera a la que indica la web.

Vamos a nuestro ESXi, y le copiamos la ISO. Seguidamente, creamos 3 VMs con las siguientes características: 

CPU: 8 cores

Memoria: 32 GB

Disco duro 1: 40 Gb

Disco duro 2: 200 Gb

Disco duro 3: 500 Gb

Yo le he metido más CPU y memoria. Realmente con 4 cores y algo menos de RAM debería valer. Lo que sí es importante, que el disco duro 1 tenga al menos 40 Gb. Si habéis visto otros tutoriales, normalmente dicen que 16 GB. Son insuficientes, y da problemas a la hora de realizar la instalación.

En Unidad de CD le ponemos el arranque con la ISO descargada previamente.

IMPORTANTE: vamos a las opciones de la VM y en "parámetros de configuración", pulsamos sobre "editar configuración"

Entra las variables que hay, pulsamos sobre "agregar parámetro" e introducimos en el apartado "Clave", "disk.EnableUUID" y en el apartado "Valor", "TRUE", la como se ve en la siguiente imagen:

En la pestaña de Virtual Hardware, CPU, expandimos el menú y marcamos "Expose hardware assisted virtualization to the guest OS".

Una vez creadas las VMs, arrancamos con la ISO cargada. Se verá una breve pantalla por un segundo con el arranque de la CE, y mucha pantalla negra con texto de carga, hasta que llegamos a la ventana de configuración    

Esta página es un chiste. Veis el EULA ese, que nadie se lee? Pues hay que hacer scroll hasta el final, o en la siguiente pantalla no podrás continuar con el proceso. ¡Avisados estáis! Asi que venga, a mantener pulsada la flecha abajo, hasta el final del documento. Después ya podéis marcar el Accept, y pulsar Start

Tómatelo con calma, el proceso de instalación no es rápido.

Finalizado el proceso, pedirá desmontar el disco y un reinicio. Cuidado con el reinicio, porque aparenta ser rápido, y te da el prompt en poco tiempo, pero internamente está levantando procesos, y le llevará mucho levantar completamente. Para verificar que está listo, accedemos por ssh a cualquiera de nuestras CVMs, con el user y pass por defecto, ya sabes: username nutanix y password nutanix/4u

Introducimos el siguiente comando: "watch -d genesis status". Necesitamos que aparezcan levantados 2 servicios: foundation y genesis.

Con estos servicios levantados, ya podemos iniciar la creación del clúster..

Aquí, la sintaxis correcta sería la siguiente: cluster -s <cvm_ip_1>,<cvm_ip_2>,<cvm_ip_3> –dns_servers 1.1.1.1 create

Incluso, además de las IPs de las CVMs y el servidor DNS, podemos pasar más info a la creación del cluster. Algo asi: cluster -s <cvm_ip_1>,<cvm_ip_2>,<cvm_ip_3> --dns_servers=<IP de los servidores DNS> --cluster_name=<el nombre del cluster> --cluster_external_ip=<la IP propia del cluster> create

Personalmente, me ha dado bastantes problemas hacerlo así, posiblemente porque el DC y DNS de pruebas para el entorno lo tengo "de aquella manera", y ni creando previamente los registros DNS acababa de funcionar correctamente, así que el comando que yo utilizo es solamente el siguiente:

cluster -s <cvm_ip_1>,<cvm_ip_2>,<cvm_ip_3>  create 

La creación del clúster es bastante rápida. Ahora, una sucesión de comanditos para ir creando los parámetros que en otros casos se dan en la misma creación del clúster. Empezamos con un "cluster start"

A continuación, definimos el nombre del clúster con un "ncli cluster edit-params new-name=cluster_name"

Seguidamente configuramos esa Virtual IP Address del clúster, con un "ncli cluster set-external-ip-address external-ip-address=cluster_ip_address"

Para agregar los servidores DNS, introducimos "ncli cluster add-to-name-servers servers=DNS_server_ip_address"

Y ya por ultimo metemos el servidor, o listado de servidores, NTP con "ncli cluster add-to-ntp-servers servers=NTP_server_ip_address" (de este comando se me pasó la captura, sorry).

Con esto, sólo queda que accedas a tu clúster a través de la virtual ip recien configurada, y, ¡a jugar!

PD: Como curiosidad, conéctate de nuevo a una CVM y vuelve a ejecutar el watch -d genesis status. Ahora verás una pila de servicios notablemente superior. Y muchos te sonarán, de la arquitectura de Nutanix, esos servicios que se describen en la Biblia de Nutanix para explicar cómo se comunican los distintos componentes de la solución. Bueno, pues aquí los tienes, en directo:

Ten en cuenta que provisionamos a estas VMs un almacenamiento decente para jugar, así que mi recomendación es empezar por algo facilito: creación de contenedores, y luego file servers.