¿De verdad es un drama la nueva política de licencias de VMware?

 El 10 de abril de 2025, VMware, ahora bajo el mando de Broadcom, actualizará las políticas de licenciamiento: mínimo 72 núcleos para nuevas compras y renovaciones. Esto ha levantado revuelo entre administradores de TI y pequeñas y medianas empresas (pymes), pero ¿es realmente un problema? Vamos a verlo con calma.

Los servidores de hoy ya cumplen

Si miramos el hardware actual, la mayoría de los servidores empresariales ya vienen con procesadores que suman o superan los 72 núcleos. Así que, para muchas empresas, este cambio ni se va a notar. En resumen: si ya tienes un servidor decente, lo más probable es que no tengas que hacer nada diferente. Y si no, ve pensando en la renovación de tu hardware, porque un clúster de portátiles como el que estoy utilizando para escribir este artículo, ya suma mas que esos 72 núcleos.

¿Y si mi infraestructura es pequeña?

Si tienes un entorno más modesto, tampoco es el fin del mundo. VMware ofrece opciones como VMware Workstation Pro y VMware Fusion Pro, que te permiten correr varias máquinas virtuales en una sola computadora sin necesidad de un servidor dedicado. Son perfectas para pruebas, desarrollo y formación. Y gratis.

Además, si lo de invertir en infraestructura propia no encaja en tu presupuesto, la nube es tu amiga. Servicios como VMware Cloud on AWS, Microsoft Azure y Google Cloud te permiten correr tus máquinas virtuales sin preocuparte por licencias de 72 núcleos. Es una opción flexible, escalable y sin dolores de cabeza por mantenimiento de hardware. ¿Que quieres algo más pequeño que lo que me ofrecen los clasicos? Tienes a OVH e IBM, que pueden ajustar su oferta a un único host mínimo, e incluso pagándolo por horas.

Aunque pueda parecer un gran cambio, la realidad es que la mayoría de las empresas ya cumplen con los nuevos requisitos o tienen opciones viables para adaptarse. Si tienes un servidor moderno, no notarás la diferencia. Y si eres una pyme con menos necesidades, puedes optar por soluciones más ligeras como Workstation Pro o directamente pasarte a la nube. Así que, lejos de ser un drama, esto es solo otro ajuste más en el mundo de la virtualización. 😉

Montando Holodeck para pruebas con VCF

Con Holodeck hay mucha tela que cortar, así que este artículo puede quedar un poquito más denso de lo habitual, de manera que si estás leyendo estas líneas, te pido paciencia, porque trataré que merezca la pena.

Lo primero de todo...¿qué es Holodeck? 

Holodeck es una herramienta relativamente nueva de VMware, no puedo darte la fecha exacta, pero la primera vez que escuché hablar de ello fue por 2023. Entonces iban por la versión 1.2, y no he encontrado versiones más antiguas, así que no debo ir desencaminado. Hoy día han avanzado muy rápido en su desarrollo, y van por la versión 5.2 con ESXi 8.03 en los despliegues.

Básicamente, Holodeck te despliega un VMware Cloud Foundation (VCF) anidado en un ESXi. Teniendo en cuenta que para un despliegue funcional de VCF requieres mínimo de 4 host sobre los que se instalará la infraestructura de la solución, lo que se conoce como "management domain", que para un laboratorio de pruebas "nested" sólo te consuma un ESXi, es una maravilla. Obviamente no rendirá como una solución de producción, pero para realizar pruebas y familiarizarte con este nuevo entorno de VMware, es perfecto.

Como indicaba anteriormente, Holodeck comenzó con la version 1.2, pero ahora mismo puedes descargarte 3 versiones distintas, la 2.0 con soporte para VCF 4.5 hasta 5.0, la 5.1.1 con soporte para VCF 5.1.1 y la 5.2, con soporte para VCF 5.2 y 5.2.1. En líneas generales, si tienes un ESXi 7.0x, yo me descargaría la última versión.

¿Cómo se despliega?

El despliegue de Holodeck realmente no es complicado. De hecho, las últimas instrucciones están muy bien explicadas, de manera que siguiendo al pie de la letra el manual, es fácil. 

Puedes encontrar el manual de instalación AQUI.

Resumiéndolo mucho, todo consiste en los siguientes pasos:

1. Preparar una Custom ISO para el despliegue de la Holo Console
2. Una pequeña configuración de redes en el ESXi sobre el que vas a desplegar la solución
3. Instalación del Holo Router
4. Montaje de la Holo Console con la ISO del paso 1.
5. Una vez montada la Holo Console, lanzamos el despliegue del entorno, con VLCGui, o con linea de comandos.

Después, es sólo sentarse y mirar como la automatización del proceso hace su magia.

VMware lo resume en 4 pasos, como ves en la siguiente imagen,

Pero he preferido indicarlo en 5, porque es mejor tener desplegado el Holo Router antes de montar la Holo Console con la Custom ISO

Para simplificar más las cosas, si vuelves a desplegar Holodeck de nuevo, porque quieres realizar cambios, montarte un Workload Domain en el proceso que no hiciste la primera vez, lo que sea, el proceso de creación de la Custom ISO es algo que no tendrás que repetir.

Si me apuras, tampoco el despliegue del Holo Router, si ha eliminado un despliegue previo, pero eso es otra historia...

Me voy al último paso: una vez arrancada la Holo Console, lanzaremos el VLCGui, la interfaz gráfica para la creación del entorno. Solo hay que seguir las indicaciones del manual, pero veremos esto:

Básicamente le indicamos el json para montar el lab, le decimos donde está la OVA de cloudbuilder que nos descargamos para preparar la Custom Iso con la que se ha creado la Holo Console, le decimos si queremos hosts adicionales para workload domain, y por supuesto en el apartado de la derecha de la ventana, le pasamos los datos de conexión al host físico sobre el que va a desplegar el laboratorio.

Ahora, un poco más en profundidad...

Para desplegar holodeck vamos a necesitar descargar una serie de componentes y modificar el script de creación de la custom ISO en base a los componentes descargados. Como siempre, es fácil y viene todo detallado en el manual, pero es importante tener en cuenta un detalle tonto: todas las rutas están para un SO en inglés. Así que mi consejo, ya que tarde o temprano tendrás que mover todo al ESXI es... móntate una VM con el Windows Server 2019 EN-US que tienes que descargarte, y sobre ella, vas descargando todos los elementos necesarios para la creación de la custom ISO. 

La custom ISO es un paso muy importante de todo el proceso. Si se crea correctamente, lo que hace el script es preparar una ISO que te levanta una VM que contendrá todos los elementos descargados previamente, en algunos casos instalados, y las carpetas para el lanzamiento del cloudbuilder, lo que realmente montará el lab, listas para su ejecución. Pero no solo eso, también te levanta un AD y un DNS, necesarios para el dominio de nuestro Management Domain.

NOTA: para la Custom ISO, no es importante únicamente el archivo createiso.ps1, también debes revisar los archivos additionalfiles.txt y additionalcommands.bat. Estos archivos gestionarán la instalación de software adicional, como la versión de PowerShell descargada, y si no tocamos estos documentos, PS no se instalará, y no podremos ejecutar el Cloudbuilder desde la Holo Console, de manera que es mejor poner cuidado ahora a tener que solventar esto instalándolo posteriormente a mano.

Sobre el Holo Router, no hay mucho misterio. Va a funcionar de enlace entre nuestra infraestructura virtual, y nuestro ESXi, posibilitándonos accesibilidad a, por ejemplo, la Holo Console, e incluso acceso a internet Si es que hace lo que dice su nombre, simplemente enruta ese switch virtual sin uplinks con el que funcionará nuestra infra, a nuestro ESXi.

Sobre el proceso de montaje del entorno: una vez se lanza el proceso con scripts o con la interfaz gráfica, sólo hay que tenr paciencia. Verás desde la ventana de Powershell en segundo plano, o desde las tareas de tu esxi, como se van ejecutando los procesos de creacion de maquinas, verás com ovan creandose los 4 ESXi de tu management domain, el Manamement NSX, el NSX Edge, etc...

Finalmente, terminará con el mensaje que ves en la imagen superior, indicando la ruta al SDDC Manager. No es necesario que la anotes, en el proceso de despliegue del Holo Console, si abres Chrome, verás que tienes en la barra de favoritos diversos elementos, como el acceso al SDDC Manager, al NSX Manager, e incluso una página conteniendo los usuarios y passwords de acceso a todos los elementos de nuestro Holodeck.

Si quieres saber un poco más del tema en el idioma de Cervantes, adjunto un enlace al video del evento de la comunidad de VMUG de España donde se explica qué es Holodeck, se explica el despliegue, y donde podréis ver el Holodeck ya funcionando, y el acceso al SDDC Manager:

https://www.youtube.com/watch?v=kVZnpCkN9ZQ&t=6s

Si te ha gustado el articulo, puedes invitarme a un café ;)

Unificar varios Collector en un mismo Sizer

 Un caso que nos podemos encontrar es el de una empresa con distintos vCenters, ya puede ser en la misma, o distintas ubicaciones. Las razones pueden ser varias, desde separaciones fisicas por temas de licenciamiento, a necesidades de versión por compatibilidad legacy, o bien por gestion en grandes entornos, donde un solo vCenter no puede soportar todas las VMs, y han decidido dividir la infraestructura en varios entornos, según funciones.

Pero todo evoluciona, y puede ser necesario unificar entornos por distintas razones, desde reducción de huella de carbono, a costes, o simplemente, aprovechar la potencia de nuevas generaciones para pasarse a un entorno hiperconvergente y de gestión más simple. El problema es que cuando ejecutas unas RVtools o, mejor, unas Collector de Nutanix, nos encontramos que apuntan a un vCenter. Uno solo. Dentro, puedes tener uno 10 o 100 clústeres, pero sólo te da los datos de ese único vCenter. 

¿Y si queremos unificar los vCenters? ¿Me veré obligado a introducir a mano todos los datos del entorno en el Sizer? ¡Pues no! Se pueden subir varias fuentes al mismo Sizer, y luego ahí ya te gestionas las VMs como pertenecientes a un clúster único, o te las divides en clústeres a tu gusto, tal y como te indiqué en este otro post.

Partimos de la importación de datos del Collector de un vCenter:

Aquí, cada uno tiene sus preferencias, a mi me gusta hacerlo con las siguientes opciones:

En Powered VMs, lo optimo sería Powered ON only, pero si no conoces las causas del apagado de las VMs, y para no pillarnos los dedos con la capacidad, prefiero seleccionar Powered ON and OFF. Más abajo, en Workloads, si mascas VMs podrás ver las cargas con las que trabaja el Sizer por VMs, hasta un máximo de 1000 VMs. Si no, se unificaran por carga en perfiles de VM (Small, Medium, Large, etc...). Si marcamos "retain to cluster mapping", en caso de haber varios clusters, las delimitará de esa manera. Si no, las meterá todas en un mismo cluster. 

NOTA: Cluster mapping falla mas que una escopeta de feria, si ves que el Sizer da fallos, desmarca esta opción. Te tocará crear los clusters manualmente.

Vale, ya tenemos nuestro Collector cargado, con 74 VMs, como podemos comprobar en la pestaña "Workloads". El trabajo que sigue para cargar otro vCenter es tan sencillo como, en la misma pestaña, a la derecha, y casi a la misma altura que "workloads", tenemos el botón "import". 

Lo pulsamos, y nos llevará a una pantalla familiar. Solo nos queda cargar el nuevo collector que queremos sumar.

Como se puede ver, este nuevo vCenter era mas pequeño, apenas tiene 12 VMs mas. 

Podemos ir a las pestaña "Solution" para ver cómo cambia la solucion configurada, pero me interesa que echéis un vistazo al texto en azul, "View Workload Source & Import history". Pinchamos sobre el enlace, y nos abrirá una ventana flotante que nos indica los archivos con los que está trabajando:

Podemos ver el nombre y fecha de los dos archivos que hemos subido: el archivo con el que creamos el Sizer, y el archivo subido posteriormente. Veréis también un botón de "Upload Source File" que a fecha de hoy, podría estar como podría no estar, ya que no funciona. Si lo pulsas hace el proceso de subir un Collector, pero no lo aplica, de manera que hay que subirlo de la misma manera que he explicado anteriormente.

Si te ha gustado el articulo, puedes invitarme a un café ;)

Configurar el Sizer para un Stretched cluster

 Un problema que nos podemos encontrar a la hora de tratar con el Nutanix Sizer, ya sea partiendo de unas RVtools o bien de un Collector, viene cuando se te presenta el dimensionamiento de un Stretched Cluster con vSAN. Ninguna de las dos herramientas de recolección de datos te va a separar las zonas, y tampoco vienen identificadas como dos clústeres distintos: precisamente de eso va la solución, ¿no? De esta manera, seremos nosotros los que tendremos que trabajar un poquito sobre el Sizer. ¡Vamos alla!

Partimos de unas RVtools (o Collector), que nos van a mostras algo similar a esto:

Vale, esto es raro, porque no debería ser necesario un Witness para el numero de hosts que tiene en cada extremo del clúster, así que supongo que habrán ampliado 1 nodo en algún momento. Pero ese no es el problema. El problema realmente es el modo en el que la herramienta dimensionará los requisitos de la solución. Lo hará como un único clúster en una única ubicación. ¡Esto cambia mucho la foto de los requerimientos! Tomamos como ejemplo la imagen superior. Partimos de un total de 6 host mas el witness, y lo que sizer nos da como solución es lo siguiente:

En N+1, una preciosa solución basada en 4 host. Sin entrar en cargas de trabajo, a priori, es una reducción importante de hardware. Pero falsa. De hecho, si quisiéramos mantener la solución de 2 zonas unidas por ejemplo con Nutanix Metro Cluster o Sync Replication, no tendríamos los nodos mínimos para conformar un clúster decente en Nutanix (recordemos, 3 mínimo. Que si, se puede con 2 e incluso 1, pero solo como ROBO, no valdría para lo que se plantea). Así que vamos a "forzar" el segundo cluster en el sizer. 

Para ello, pinchamos sobre "workloads":

Justo donde pone "Cluster1", todo a la derecha, veremos el símbolo de un engranaje con el texto "Modify", Si pinchamos ahí, nos saldrá una pantalla con los ajustes del clúster. Si vamos abajo del todo, veremos que todas las VMs se han configurado para funcionar en un solo clúster. Tendremos que configurarlo para que funcione en 2 clusters realmente. Para ello cerramos esta pantalla de configuración, y volvemos a nuestra pantalla de Workloads. A continuación, seleccionaremos las VMs que van al segundo cluster (si, a mano), marcando la casilla de selección de la izquierda. Una vez hayamos seleccionado tantas como consideremos oportuno, pinchamos sobre "add":

Veremos que ahora, si nos desplazamos hacia abajo, en la sección de clúster, tenemos la opción de crear uno nuevo:

Una vez creado el nuevo clúster, tenemos la opción de mover posteriormente más VMs, de manera más fácil, desde el botón "Bulk / Change" y seleccionando "Move Workloads". Cada vez que hagas esto, verás que la parte Solution tarda un poco, pues estará redimensionando la carga de los servidores, y evaluando los modelos que se ajustan a las necesidades. Es por ello que es importante dedicarle un poco de tiempo a seleccionar VMs, ya que si tienes, pongamos 10 VMs, no es lo mismo meter 10 que 50 al nuevo cluster, ni meter VMs ligeras que VMs con cargas pesadas...

Cambia tanto como las imágenes 3 y la siguiente, de este post. En la 3, sobre la que hemos trabajado el ejercicio, podemos ver que la solución pedía 4 host. En cambio, en la foto que veremos a continuación, vemos una solución más simple con 3 nodos en cada una de las ubicaciones:

Es por esto que es importante no solo realizar un export al Sizer, sino también analizar los datos con los que trabajamos, ya que la foto final puede variar muchísimo si no tenemos en cuenta la configuración real del entorno.

Si te ha gustado el articulo, puedes invitarme a un café ;)

VMUG Madrid retoma su actividad

 ¡Buenas noticias para la comunidad de usuarios de VMware de Madrid! El VMUG Madrid está de regreso y listo para retomar su papel como epicentro de intercambio de conocimientos, experiencias y networking para todos los entusiastas de VMware.

🌟 ¡Estamos de vuelta y más fuertes que nunca! 🌟

Tras un año lleno de cambios emocionantes en el ecosistema de VMware, ha llegado el momento de volver a conectar. VMUG Madrid regresa con energía renovada, nuevos objetivos y muchas ganas de crear un espacio donde podamos:

• 📊 Aprender de expertos y de las experiencias de otros usuarios.

• 🙌 Compartir conocimientos, ideas y buenas prácticas.

• 🚀 Crecer como profesionales y como comunidad.

🍻 vBeers para Celebrar el Relanzamiento 🍻

Y como toda buena reunión empieza con un buen brindis, te invitamos a unas vBeers informales para celebrar esta nueva etapa.

✨ 🗓️ Fecha: Jueves 20 de febrero, a partir de las 18:00
✨ 📍 Lugar: The Clover Irish Tavern, C/ Valle de Pinares Llanos 8, 28100 Madrid

Será la oportunidad perfecta para:

• 👥 Reencontrarnos con antiguos miembros.

• 🌐 Conocer a nuevas caras en la comunidad.

• 🔊 Ponernos al día sobre las últimas novedades de VMware.

🌟 ¡Queremos Escucharte! 🌟

Este relanzamiento no solo es para ti, sino contigo. Queremos conocer:

• 🚀 Tus intereses y temas favoritos.

• 💡 Tus ideas para futuros eventos.

• 📊 Tus necesidades para seguir creciendo en el mundo VMware.

Tu opinión es fundamental para que VMUG Madrid siga siendo una comunidad única y relevante.

✨ ¡No te pierdas esta oportunidad de ser parte activa del futuro de VMUG Madrid! ✨

Vuelve a conectar, aprende algo nuevo, comparte tus experiencias y, sobre todo, ¡disfruta de unas cervezas bien frías con la mejor comunidad tech de Madrid! 

¡Tendremos precio promocional para todas las consumiciones, por cortesía de The Clover!

...y por supuesto, ¡¡¡síguenos en @VMUGMadrid !!!

Enlace de registro, -->AQUI <--