Azure deja de incluir la licencia de VMware: la cuenta de núcleos que nadie hace

Ayer la prensa técnica recogió que Microsoft cierra una de las últimas puertas para usar VMware sin firmar el paquete grande de Broadcom. La fecha del titular ya la contamos aquí el 3 de agosto. Lo que ha aparecido después es bastante más útil que la noticia: una página de referencia del licenciamiento portátil, fechada el 14 de agosto y actualizada el 17, con cuatro filas de fechas y varios ejemplos de aritmética que Microsoft resuelve con mucha educación. Eso es lo que conviene mirar antes de septiembre.

Cuatro fechas, y la que te afecta no es ninguna de ellas

Azure VMware Solution es VMware corriendo sobre hierro dedicado dentro de Azure: vCenter, vSphere, vSAN y NSX, con Microsoft de operador. Durante años venía con la licencia incluida en la factura, y eso lo convirtió en el sitio donde aterrizaron bastantes empresas que no querían sentarse a negociar con Broadcom. La tabla de fechas marca el final de ese arreglo en cuatro pasos: el 15 de octubre de 2025 quedó fijado el número de núcleos de cortafuegos vDefend que seguían cubiertos; el 1 de noviembre de 2025 los despliegues nuevos pasaron a exigir VCF portátil; el 31 de octubre de 2026 los despliegues de pago por uso con licencia incluida tienen que haber migrado para seguir siendo conformes; y el 30 de agosto de 2027 las reservas activas hay que cambiarlas por reservas BYOL o sacar esas cargas de Azure VMware Solution.

Fíjate en la segunda fila, porque no estaba en ningún titular de ayer y va antes que todo lo demás. Microsoft escribe en esa misma página que «as of November 1, 2025, Microsoft no longer includes a VCF license or subscription with new Azure VMware Solution node purchases» (desde el 1 de noviembre de 2025, Microsoft ya no incluye licencia ni suscripción de VCF con las compras de nodos nuevos). Cuando escribimos sobre esto a principios de agosto, la fecha que circulaba era la del cierre de 2026. Resulta que para los despliegues nuevos el modelo antiguo se cerró el otoño pasado: si montaste un clúster en marzo, lo montaste ya en el mundo nuevo.

Y debajo de la tabla hay un recuadro de aviso con una frase que se lee en tres segundos y cambia el calendario de todo el mundo: «If a reservation expires before August 30, 2027, its license-included benefits end when the reservation expires» (si una reserva vence antes del 30 de agosto de 2027, sus beneficios de licencia incluida terminan cuando vence la reserva). Agosto de 2027 no es tu fecha. Tu fecha es la de vencimiento de tu reserva, que puede caer en febrero, en mayo o en noviembre del año que viene. Casi nadie la tiene apuntada donde alguien la mire.

La cuenta de núcleos, hecha con la tabla de Microsoft

Lo que compras ahora son núcleos, y la documentación publica cuántos tiene cada tipo de nodo, así que aquí no hay que estimar nada. AV36 y AV36P, 36 núcleos por host. AV48, 48. AV52, 52. AV64, 64. Multiplicas por los hosts BYOL y ese es el número que tienes que tener comprado a Broadcom y registrado en la página «Portable VCF (BYOL)» de tu nube privada. Microsoft lo ilustra con tres nodos AV64: 3 × 64 = 192 núcleos. Y con una nube privada mixta de tres AV36P con licencia incluida más cuatro BYOL, donde hay 252 núcleos desplegados de los que solo se registran 144, porque los tres primeros ya están cubiertos.

Hasta aquí es una multiplicación. Un clúster de diez hosts AV36P, que es un tamaño de los de todos los días, son 360 núcleos de VMware Cloud Foundation. Lo interesante está en el apartado siguiente de la misma página.

Los otros 360, y a quién le tocan de verdad

El cortafuegos vDefend es un añadido aparte y su regla de conteo no se parece a la anterior. Para el cortafuegos distribuido de NSX se cuentan todos los núcleos de host de la nube privada. Todos: también los de los hosts que llevan la licencia incluida y que no cuentan para el registro de VCF. El ejemplo que da Microsoft son diez hosts AV36P y salen 360 núcleos de añadido.

Suma las dos cuentas y el mismo clúster de diez servidores necesita 720 suscripciones de núcleo: 360 de la plataforma y 360 del cortafuegos. Lo que dispara la segunda no es una compra ni una firma, sino una acción de consola: el cortafuegos distribuido «is considered enabled when you configure a nondefault Distributed Firewall policy or Distributed Firewall IPFIX profile» (se considera activado cuando configuras una política de cortafuegos distribuido no predeterminada o un perfil IPFIX de cortafuegos distribuido). Alguien de sistemas escribe una regla para segmentar dos redes y el derecho de uso que necesitas se ha doblado. El cortafuegos de pasarela se cuenta por otro lado —número de edges por sus vCPU, por cuatro—; Microsoft documenta que la segunda generación trae tres edges grandes por defecto, y cuatro cuando el clúster 1 tiene cuatro nodos o más, así que con la medida grande de su propio ejemplo, ocho vCPU, salen 96 núcleos en el caso corriente y 128 en un clúster como el de diez hosts de antes.

Con una condición que hay que decir en voz alta, porque cambia a quién le aplica esa cifra: esos 720 son los de una nube privada nueva y entera en BYOL. Si tus diez hosts están cubiertos por reservas con licencia incluida que siguen vivas, o son nodos de pago por uso desplegados antes del 15 de octubre de 2025, hoy no tienes que registrar nada. Y si activaste vDefend antes del 16 de octubre de 2025 con una reserva con licencia incluida activa, conservas esos núcleos de cortafuegos hasta que venza la reserva o hasta el 30 de agosto de 2027, lo que llegue antes. Los 720 no son tu factura de hoy: son el suelo del día que se acabe la prórroga.

Justo es decir también que esto solo aplica si activas esas funciones, y por lo que vemos hay despliegues que nunca tocan el cortafuegos distribuido porque la segmentación la hacen en otra capa. Pero para activarlo basta con una política; no pasa por compras, y esa asimetría entre lo barato que sale encenderlo y lo caro que sale tenerlo encendido es donde se generan las diferencias desagradables en una revisión.

Por qué no vas a encontrar aquí el precio por núcleo

Sería facilísimo cerrar el apartado anterior multiplicando 720 por una cifra en dólares y llevarse un titular redondo. No lo vamos a hacer. Los precios por núcleo de VMware Cloud Foundation que circulan por internet vienen de consultoras de licenciamiento, no de una tarifa pública de Broadcom que podamos abrir y verificar palabra por palabra, y meterlos aquí convertiría un cálculo sólido en una estimación con adornos. Los núcleos sí son un dato firme, porque salen de la tabla del proveedor de la nube. Multiplica tú por el número de tu oferta, que ese lo tienes.

Y ya puestos, lo decimos de frente: no somos resellers de VMware ni de Proxmox y no cobramos comisión por ninguna licencia de ninguna de las dos. Que este post lo firme una empresa que también hace migraciones a Proxmox no lo convierte en un anuncio.

Qué pasa si los números no cuadran

La documentación es explícita. En su apartado de preguntas frecuentes, sobre desplegar más núcleos de los que Broadcom te ha licenciado: «The private cloud becomes noncompliant and is at risk of suspension» (la nube privada pasa a no ser conforme y queda en riesgo de suspensión). Y en el apartado del cortafuegos lo dice más seco todavía: «Microsoft may suspend a noncompliant private cloud until the issue is resolved» (Microsoft puede suspender una nube privada no conforme hasta que el problema se resuelva). Lo que se para ahí es el servicio. Un desajuste administrativo entre lo que compraste en un portal y lo que registraste en otro deja el entorno en riesgo de parada.

Hay una pregunta más en esas frecuentes que merece la pena tener presente, porque es el escenario que más fácilmente se cuela: qué pasa si la suscripción de VCF caduca antes de que termine la reserva de Azure. La respuesta es que la caducidad de la suscripción no afecta a la reserva, pero deja los hosts BYOL como no conformes. Dos contratos con dos calendarios distintos y dos proveedores distintos, y el que se queda corto manda sobre el otro. Renovar el de Broadcom antes de su fecha y actualizar el registro necesita dueño y fecha en el calendario de alguien.

Hay otra línea en la misma página que a nosotros nos parece igual de reveladora y que casi nadie citará: Microsoft «reports BYOL registrations and associated customer data to Broadcom monthly to meet partner compliance requirements» (informa mensualmente a Broadcom de los registros BYOL y de los datos de cliente asociados para cumplir los requisitos de conformidad de socio). Existe un flujo de información periódico entre tu proveedor de nube y el fabricante del software, sobre tu entorno, del que tú no eres parte. Está en la documentación pública y es consecuencia lógica del modelo. Pero es el mismo patrón del que hablamos hace unos días, cuando contamos que la autoridad sobre tu infraestructura suele estar repartida entre empresas con las que tú no has firmado nada.

La prueba que se factura sola a los sesenta días

Detalle pequeño y con dientes, por si alguien está pensando en probar el modelo nuevo antes de decidir. Las pruebas de tres nodos duran 60 días y exigen una clave de prueba de Broadcom por delante, así que ni para mirar te ahorras la conversación con el fabricante. Antes de que termine el periodo hay que aportar una suscripción de Broadcom comprada que cubra los núcleos desplegados; si eso no pasa, dice la documentación, los hosts de prueba se convierten automáticamente en hosts facturados salvo que borres el despliegue antes de que acabe la prueba.

Cuándo no nos moveríamos de ahí

Toca la parte que no vende. Si tienes una reserva viva que llega hasta bien entrado 2027, NSX en producción con reglas que alguien escribió con cabeza y un equipo que sabe operar vSphere, cambiar de hipervisor este otoño es casi seguro peor negocio que sentarte a renegociar. Migrar una plataforma de virtualización son meses de inventario, red, copias, ventanas de parada y gente aprendiendo herramientas nuevas mientras sostiene el servicio.

Hay incluso un argumento a favor del modelo nuevo que casi nadie está haciendo: un derecho de uso que compras tú es tuyo. La documentación dice que puedes aplicar la suscripción portátil nube privada por nube privada, y repartir los núcleos de una misma clave entre varias mientras el total registrado no pase de lo comprado. Cuando la licencia venía soldada a la factura de Azure no había nada que llevarse a ninguna parte; ahora sí, y eso es palanca en una mesa de negociación. Reconocerlo no nos cuesta nada: hemos migrado empresas de VMware a Proxmox y también hemos recomendado quedarse en VMware cuando tenía sentido.

Lo que sí evitaríamos con bastante insistencia es hacer las dos cosas a la vez: negociar la renovación y migrar la plataforma en el mismo trimestre, con las mismas personas, sin haber escrito antes por dónde se vuelve si sale mal. De eso ya escribimos con detalle: el plan de vuelta atrás de una migración se escribe antes que el plan de ida.

Qué haríamos en septiembre

• Sacar la fecha de vencimiento de cada reserva. La de cada una, con su día y su mes. Está en el portal, tarda dos minutos y es la única que manda en tu calendario, porque si vence antes el beneficio de licencia incluida se acaba ese día.
• Contar los núcleos con la tabla y ponerlos al lado de lo comprado. Tipo de nodo por número de hosts, host a host, y comparar con el derecho que tengas registrado. Si el número de la izquierda es mayor que el de la derecha, ya estás fuera de conformidad aunque nadie te haya avisado.
• Averiguar si el cortafuegos está «activado» según la definición de Microsoft. Con la consola delante: buscar en NSX políticas de cortafuegos distribuido no predeterminadas y perfiles IPFIX, y lo mismo con las de pasarela. Es un rato de consola y evita una diferencia de cientos de núcleos.
• Comprobar el registro si vienes del modelo antiguo. Quien registró su BYOL por correo electrónico antes de noviembre de 2025 tenía que volver a registrar cada nube privada por el portal antes del 31 de marzo de 2026. Si esa tarea se quedó en la bandeja de entrada de alguien, hoy es un problema silencioso.
• Decidir el destino antes de diciembre. Comprar VCF y quedarse, mover las cargas a otro sitio o dividir el parque: las tres opciones son razonables y las tres necesitan meses. Si llegas a la fecha sin haber elegido, elige el calendario por ti.

Lo que ha cambiado aquí, más que el precio, es quién responde de qué. La conformidad de licencia venía dentro del servicio que contratabas y era problema del proveedor; ahora es tuya, se mide en núcleos registrados en un portal y se comprueba todos los meses. Es la misma clase de movimiento que vimos cuando el recargo por pago mensual empezó a llegar por calendario en vez de por negociación. Nadie te sube el precio de golpe; se mueve el suelo y te toca a ti volver a hacer las cuentas.

Fuentes (verificadas el 21 de agosto de 2026): las cuatro fechas (15-oct-2025, 1-nov-2025, 31-oct-2026 y 30-ago-2027), el aviso sobre las reservas que vencen antes, los núcleos por tipo de host (AV36/AV36P 36, AV48 48, AV52 52, AV64 64), los ejemplos de 192 y de 252/144 núcleos, la regla de conteo del cortafuegos vDefend y su ejemplo de 360 núcleos para diez hosts AV36P, la fórmula del cortafuegos de pasarela y el número de edges de la segunda generación, la definición de «activado» para el cortafuegos distribuido, la cobertura que conservan las reservas y los nodos anteriores al 15 y 16 de octubre de 2025, las condiciones de las pruebas de 60 días, la suspensión de una nube privada no conforme, el efecto de una suscripción de VCF caducada antes que la reserva, el informe mensual a Broadcom y el plazo del 31 de marzo de 2026 para los registros antiguos, de la referencia de licenciamiento de VCF portátil para Azure VMware Solution en Microsoft Learn, con fecha de artículo del 14 de agosto de 2026 y última actualización del 17. La cobertura periodística del 20 de agosto y el encuadre de que Azure era una de las últimas vías para usar VMware fuera del paquete, de The Register. La suma de 720 núcleos para diez hosts AV36P y los 96 y 128 del cortafuegos de pasarela son cálculos nuestros, hechos aplicando las reglas de conteo de esa misma página. Las citas se dan en su inglés original, con nuestra traducción entre paréntesis, para que se puedan verificar palabra por palabra. No incluimos precios por núcleo porque los que circulan no proceden de una tarifa pública de Broadcom.