Mínimos de núcleos de VMware con Broadcom: ¿16, 72 o 96?

Durante años, las licencias de VMware ocuparon ese rincón curioso de la informática empresarial donde nadie estaba entusiasmado, pero la mayoría conocía las reglas. Podías dimensionar un clúster, calcular los números, defender tu presupuesto y marcharte sin la sensación de haber pisado una mina financiera por error. En el momento en que Broadcom tomó el mando, esa previsibilidad se evaporó.

La confusión no estalló de golpe. Empezó como un rumor: una charla casual entre administradores que comparaban notas, un distribuidor que avisaba de que llegarían nuevos mínimos «muy pronto», un técnico de soporte que no tenía permiso para hablar pero quería advertir. Luego las historias se multiplicaron. Un ingeniero con un entorno modesto de 24 núcleos contó que le exigían licenciar 72 núcleos de todos modos. Otro aseguró que la propia documentación de Broadcom seguía fijando el mínimo en solo 16 núcleos por socket de CPU. Un tercero comentó que había oído que 96 era el suelo para los entornos de la versión 8.

El tono no era tanto de pánico como de cansancio, con profesionales veteranos de infraestructura intentando entender unas normas que parecían cambiar según con quién hablaran. De fondo se percibía algo familiar: la certeza de que a los clientes más pequeños los estaban arrinconando, sin margen para decidir nada. Junto a las reglas de licenciamiento, muchos se preguntaban si todavía tenían cabida en la plataforma.

La regla de los 16 núcleos que no resuelve nada

Si abres hoy la documentación oficial de Broadcom, la regla parece casi razonable: el mínimo de licencia son 16 núcleos por CPU física. Da igual si el procesador tiene 6 núcleos o 64; cubres al menos 16 y sigues adelante. Suena sencillo y predecible, salvo por un detalle: no es esa la cifra de la que hablan los clientes de VMware.

Los administradores a pie de obra afirman que el mínimo real es de 72 núcleos por compra, por muy reducida que sea tu infraestructura. Si tus servidores solo tienen 24 núcleos cada uno, mala suerte, pagas 72. Y si preguntas por qué existe la regla de los 16 núcleos por socket cuando el mínimo del paquete la anula, la respuesta suele ser: «Bueno… depende». Es lo último que alguien quiere escuchar cuando prepara una renovación de seis cifras.

Esa es la principal frustración que recorre los comentarios. Los documentos de Broadcom siguen mostrando la definición de 16 núcleos, pero quienes lidian con presupuestos y renovaciones aseguran vivir en un mundo muy distinto, donde el suelo se sitúa mucho más arriba y nadie en Broadcom parece tener prisa por poner esa cifra por escrito.

Dónde 72 se convirtió en la nueva normalidad

El mínimo de 72 núcleos no surgió de la nada. Broadcom eliminó el modelo tradicional de licencias a la carta de VMware y lo sustituyó por paquetes de suscripción. Ese cambio por sí solo obligó a miles de clientes a reaprender cómo funcionan los precios de VMware.

Dentro de esos paquetes se esconde una premisa: Broadcom no busca instalaciones diminutas. Su modelo comercial está pensado para clientes que consumen VMware a gran escala.

Por eso los usuarios en el hilo comentaban cosas como:

• "72 Core is the minimum purchase."
• "It is 72c minimum even if all you got is 24 cores."
• "You are too small for them, so they are making sure it is worth their time to sell to you."

Esa última frase resume el nuevo ambiente con total precisión. VMware solía adaptarse bien a pequeña escala. Los entornos modestos de dos nodos, los clústeres de prueba y los despliegues en el edge no eran las cuentas soñadas de Broadcom, pero VMware les permitía existir. Ahora la postura es otra. Si tu infraestructura baja de 72 núcleos, el mensaje viene a ser: puedes comprar 72 núcleos o puedes buscarte otra opción.

Como apuntó un usuario, consiguió que le eximieran de ese mínimo durante una renovación, lo que demuestra que la cifra es negociable. Eso solo funciona si eres un cliente al que Broadcom quiere retener y tu comercial tiene motivos para hacer la excepción, lo que refleja hasta qué punto ha cambiado el modelo.

Luego llegó la sorpresa de los 96 núcleos

Justo cuando la comunidad empezaba a asimilar el mínimo de 72 núcleos, apareció otra cifra: 96 núcleos.

Un comentarista dijo:

• "I thought it was 96 core minimum as of version 8?"
• "Yes. So VMware is 72 minimum but Broadcom now is making it 96. Just ran into this 3 weeks ago with new VMware stack on version 8."

Ese tipo de detalles hace dudar a cualquier administrador. Si el mínimo salta de 72 a 96 según estés en vSphere 7 u 8, el cambio de política se convierte en un auténtico abismo de costes. La diferencia perjudica a:

• Clústeres locales a pequeña escala
• Sedes de recuperación ante desastres (DR)
• Oficinas remotas
• Clientes que eligen deliberadamente procesadores con menos núcleos
• Despliegues en el edge que no necesitan una gran capacidad de cómputo

Como Broadcom no ha publicado nada claro que confirme ese mínimo de 96 núcleos, a la gente solo le queda intercambiar experiencias directas como quien descifra un enigma. No es ninguna exageración decir que Broadcom ha creado una situación en la que el conocimiento comunitario y no oficial resulta más detallado y preciso que la documentación oficial, y eso nunca es una buena señal.

La excepción del EEE que lo enreda todavía más

Un giro inesperado en la conversación llegó cuando alguien señaló que el mínimo de 72 núcleos no se aplica en todas partes.

Un usuario apuntó:

• "If you are in the EER, then no. For the rest of the world - yes."

Otro aclaró:

• "EER or more commonly EEA is the European economic area… They have different price books for EEA, EMEA NON EEA, China, and rest of world due to legal differences."

Esto añade otra capa de complejidad, porque el lugar donde opera tu empresa puede determinar lo dolorosa que resulte tu factura de VMware.

Si estás en el Espacio Económico Europeo (EEE), las normativas locales sobre licencias de software y competencia justa parecen limitar la capacidad de Broadcom para imponer el mínimo de 72 núcleos. Así, un cliente en Francia o Alemania podría encontrarse con un mínimo menor que otro en Estados Unidos por motivos regulatorios y no técnicos.

Esa disparidad descoloca a los equipos de TI. Dos empresas con un hardware idéntico pueden terminar con facturas de licencias totalmente dispares simplemente por su ubicación geográfica.

La perspectiva del cliente: asfixia por la incertidumbre

Lo que más destaca en las opiniones es el agotamiento, más que el enfado. Los equipos de infraestructura necesitan estabilidad. Precisan normas claras para planificar ciclos de renovación de hardware, cuadrar presupuestos y justificar decisiones ante directivos a quienes no les importa el número de núcleos, pero sí el dinero. El modelo de Broadcom ha cambiado esa certeza por pura ambigüedad.

Muchos administradores comentan que ni siquiera saben cuál es el precio real, y mucho menos si resulta desorbitado. Pueden remitirse a un documento de Broadcom que fija 16 núcleos por socket. Pueden citar a un comercial que pide 72 núcleos mínimos por clúster. Y ahora pueden mencionar a otro usuario que reporta 96 núcleos como base para vSphere 8.

Estas cifras confusas condicionan decisiones de peso:

• Si conviene posponer una renovación de hardware
• Si conviene quedarse en vSphere 7 para eludir los nuevos mínimos
• Si conviene dar el salto a Proxmox, Nutanix, Sangfor o Hyper-V
• Si conviene mover cargas a la nube para esquivar las licencias locales
• Si conviene retirar VMware poco a poco, clúster a clúster, antes de que llegue la renovación

Cuando un modelo de precios se vuelve impredecible, las empresas dejan de expandirse. Se frenan, analizan opciones y buscan vías de salida, que es justo lo que está ocurriendo aquí.

Por qué los mínimos por núcleo pegan más fuerte de lo previsto

La mayoría de fabricantes empresariales suben los precios. Es parte del juego, pero la forma de hacerlo importa.

Broadcom fue mucho más allá de una subida de costes y rediseñó la estructura completa. Las suscripciones sustituyeron a las licencias perpetuas. Los paquetes reemplazaron a los productos individuales. Los mínimos comerciales arrinconaron a las licencias modulares. Y los mínimos por núcleo se fijaron tan altos que las instalaciones pequeñas y medianas de VMware se vieron expulsadas de una plataforma que utilizaban desde hacía años.

El mensaje, deliberado o no, parece claro: «Queremos clientes más grandes y no nos importa perder a los pequeños».

Desde la perspectiva exclusiva de los ingresos, quizá tenga lógica. Desde el punto de vista de la comunidad, abre una brecha. VMware pasó dos décadas consolidándose como la capa de virtualización por defecto para todo el sector, desde despliegues modestos de dos nodos hasta enormes nubes corporativas. A Broadcom parece no preocuparle perder el 30% inferior de ese mercado.

Sin embargo, esos clientes más pequeños no se quedan callados. Hablan, comparten experiencias e influyen en compañeros, conocidos y socios, y sus historias circulan deprisa. Demasiados testimonios suenan ahora así:

• «No conseguimos una respuesta clara».
• «La documentación no coincide con lo que nos dijo el comercial».
• «No somos lo bastante grandes para que les importemos».
• «Estamos preparando la migración para salir de VMware».

No es precisamente el ambiente que una compañía desea alrededor de su plataforma estrella de virtualización.

Hacia dónde va todo esto

Es poco probable que los mínimos de licencias desaparezcan. Broadcom está orientando VMware de manera evidente hacia clientes de mayor tamaño, más predecibles y de mayor rentabilidad. Aun así, la falta de claridad se está convirtiendo en un problema añadido. Las empresas asimilan los cambios; lo que no toleran es la incertidumbre.

Si Broadcom quiere estabilizar su base de clientes, tendrá que publicar documentación clara y global sobre:

• Compras mínimas de núcleos
• Cómo varían esos mínimos según la región
• Qué versiones (v7 frente a v8) están asociadas a cada mínimo
• Si existen exenciones y quién puede solicitarlas
• Cómo se espera que operen los despliegues pequeños con el nuevo modelo

Hasta que eso ocurra, los clientes seguirán apoyándose entre sí para averiguar la realidad. Así es como acabamos en una situación donde 16 núcleos, 72 núcleos y 96 núcleos resultan correctos a la vez, según con quién hables.

Conclusión

Lo que empezó como una duda simple, ¿sigue existiendo un mínimo de compra de 72 núcleos?, ha llevado a los administradores a plantearse si VMware encaja en su futuro, y hoy por hoy las respuestas resultan difusas.

Entre el paso a suscripciones, los mínimos exigentes por núcleo, las excepciones territoriales y las versiones contradictorias desde el terreno, el esquema de licencias de VMware se ha convertido en un rompecabezas que muchos no tienen ganas de resolver. Cuando entender las licencias de una plataforma cuesta más que la propia tecnología, los clientes empiezan a sopesar alternativas.

Detrás de las cifras de 72 y 96 núcleos late la sensación de que VMware entra en otra etapa, donde el fabricante decide cuánto tienes que comprar en vez de decidirlo tú, y los clientes valoran hasta cuándo les compensa seguir la corriente. Para conocer el panorama presupuestario completo, incluido lo que cuesta realmente el precio por núcleo a un equipo de TI pequeño y qué alternativas tienes, consulta nuestro análisis de los costes de licencia de VMware en 2026.