Comprar licencias VMware/Broadcom: guía completa por cores (VVF/VCF), vSAN incluido, ediciones y cómo elegir

Resumen ejecutivo — cambios clave y qué significa para tu compra

1. Suscripción como norma: el modelo actual gira alrededor de suscripciones y bundles (VVF/VCF). Las licencias perpetuas dejaron de ser el camino principal.
2. Métrica por core: se licencian cores físicos (no hilos) con mínimo 16 por CPU. Si una CPU tiene 12 cores, se licencian 16.
3. Ojo con BIOS: los cores físicos se consideran aunque estén desactivados por BIOS.
4. vSAN incluido por core: VVF incluye 0,25 TiB/core y VCF 1 TiB/core como derecho de licencia.
5. vSphere “standalone” y vSphere 9: vSphere Standard/Enterprise Plus siguen como standalone hasta vSphere 8 (U3); las novedades de vSphere 9 llegan vía VVF/VCF.
6. Compliance reporting: en versiones 9+ hay reporting de cumplimiento (uso/licencias) que conviene tener controlado en operación.
7. Comprar bien = inventario + diseño: sin inventario fiable (hosts/CPU/cores) y sin una idea de almacenamiento/rendimiento, es fácil sobredimensionar o quedarse corto.
8. Regla práctica: si necesitas red/seguridad avanzada (NSX) y gestión del “stack”, mira VCF; si quieres un bundle sólido para virtualización on-prem con vSAN incluido, mira VVF.

Cómo se licencia: métrica por core y mínimos (explicado sin líos)

La mayoría de decisiones de compra se resuelven si respondes a esta pregunta: ¿cuántos cores físicos tengo que licenciar realmente? Porque, a diferencia de otros modelos, aquí no cuenta “cuántas máquinas virtuales tengo” ni “cuántos sockets”: se parte de los cores físicos por CPU, con un mínimo de 16 cores por CPU.

• Se licencia por core físico, no por hilos (Hyper-Threading no se licencia).
• Mínimo 16 cores por CPU: una CPU de 8, 10 o 12 cores se licencia como 16.
• Cores desactivados por BIOS: siguen contando como cores físicos a efectos de licencia.
• Se licencia el hardware donde corre el software (hosts ESXi / clústeres).

Checklist rápido para calcular cores (el que de verdad funciona)

1. Lista los hosts del clúster (o clústeres).
2. Para cada host: anota CPUs y cores físicos por CPU (no hilos).
3. Aplica el mínimo 16 cores/CPU.
4. Multiplica y suma para obtener el total de cores a licenciar.

Host; CPUs por host; Cores físicos por CPU; ¿vSAN? (sí/no); Comentarios
ESX-01; 2; 24; sí; Producción
ESX-02; 2; 24; sí; Producción
ESX-03; 2; 24; sí; Producción

Qué licencias existen hoy y para qué sirve cada una

Si simplificamos, hay dos “grandes caminos” para la mayoría de organizaciones: VVF si quieres un bundle potente para virtualización on-prem (con vSAN incluido), y VCF si buscas una plataforma más completa (con NSX, automatización del ciclo de vida y un enfoque SDDC). A partir de ahí, aparecen variantes y add-ons.

Si quieres profundizar en cada bundle en MSAdvance: guía VVF · guía VCF · vSAN por TiB · vSphere Standard · vSphere Enterprise Plus.

VVF vs VCF vs vSphere 8: comparativa realista (lo que suele decidir la compra)

Una forma sencilla de decidir es pensar en “qué problema quieres resolver”: virtualizar bien y simplificar (VVF), o plataforma completa con red/seguridad avanzada y gobierno del stack (VCF). vSphere 8 standalone, en cambio, suele aparecer cuando hay compatibilidades o una transición en curso.

Cálculos prácticos: cores a licenciar y vSAN incluido (con ejemplos)

Regla base: licencias los cores físicos de los hosts (mínimo 16 cores/CPU). Con esos cores licenciados, obtienes un derecho de vSAN incluido: VVF = 0,25 TiB/core y VCF = 1 TiB/core.

Si la capacidad incluida no llega, hay dos salidas habituales: (1) añadir vSAN por TiB, o (2) revisar si el escenario (crecimiento, FTT, rendimiento) pide un rediseño del clúster.

Cómo dimensionar vSAN sin sorpresas: incluido vs usable (lo que el usuario nota)

Aquí está uno de los puntos donde más se equivoca la gente: la capacidad de vSAN incluida por core es un derecho de licencia, pero la capacidad que “te queda” para datos depende del diseño y de la protección frente a fallos.

1) Define lo que necesitas en “usable”, no en “raw”

No es lo mismo “necesito 40 TiB para datos” que “tengo 40 TiB de discos”. Si proteges datos (por ejemplo, tolerar fallos), el usable baja. Por eso, antes de comprar, conviene alinear:

• Cuánto dato real necesitas hoy y en 12–24 meses.
• Si necesitas tolerancia a fallos (FTT) y con qué política.
• Si tu carga es sensible a IOPS (VDI, bases de datos) o más “tranquila” (ficheros, apps estándar).

2) La pregunta clave: “¿me llega lo incluido o necesito vSAN por TiB?”

En proyectos reales, la decisión suele caer por uno de estos motivos:

• Crecimiento de datos (no quieres quedarte justo en 9–12 meses).
• Protección (la política de fallos reduce usable).
• Rendimiento (a veces el diseño requiere más discos/nodos, y eso impacta coste total).

Casos típicos de compra (y qué suele encajar mejor)

1) Pyme con virtualización “clásica” y HCI moderada

Cuándo pasa: 3–4 hosts, cargas mixtas (ERP, ficheros, apps internas), equipo IT pequeño.
Suele encajar: VVF. Te da un bundle fuerte y normalmente simplifica licenciamiento y operación, con vSAN incluido por core.

2) Empresa con requisitos serios de red/seguridad y estandarización

Cuándo pasa: varios clústeres, entornos por equipos, necesidad de microsegmentar, más auditoría y control.
Suele encajar: VCF si NSX y el gobierno del stack te aportan valor real.

3) Edge/ROBO: dos nodos, sedes remotas, fábricas, retail

Cuándo pasa: footprint reducido, poco margen para “cacharreo”, se busca estabilidad.
Enfoque: revisar opciones edge y elegir por uso real (y por soporte). Muchas veces aquí pesa más el diseño y la operación que la teoría de catálogo.

4) Continuidad en vSphere 8 por compatibilidad

Cuándo pasa: aplicaciones legacy, hardware, integraciones, o un calendario de cambio lento.
Enfoque: mantener vSphere 8 (Standard/Enterprise Plus) y planificar la transición a VVF/VCF cuando el negocio lo permita.

5) Necesitas DR “en serio” (RPO/RTO exigente)

Enfoque: aquí no suele bastar con “tener un backup”. Se estudia el caso y se valora añadir add-ons de recuperación/orquestación según la estrategia de continuidad.

Términos clave: portabilidad, reporting y soporte (lo que conviene tener atado)

Uso on-prem vs nube

Antes de comprar, conviene alinear una cosa sencilla: dónde vas a usarlo. Algunos bundles están pensados principalmente para on-prem, y si tu objetivo es mover parte de la carga a nube, conviene revisar el enfoque para evitar compras que luego “no encajan”.

Compliance reporting: no lo dejes para “otro día”

En versiones 9+ existe un enfoque de reporting de cumplimiento (uso/licencias) que conviene incorporar a operación. No es “un trámite”: es algo que se programa, se asigna a un responsable y se revisa periódicamente.

• Recomendación: crea un recordatorio operativo (por ejemplo, cada 6 meses) y documenta el procedimiento.
• Entornos sin Internet: define desde el inicio el modo de reporte para entornos aislados (air-gapped).

Soporte y ciclo de vida

Si aún estás en vSphere 7, es importante revisar soporte y hoja de ruta: planificar upgrades reduce riesgos, evita prisas y ayuda a comprar con más margen.

Cómo comprar con MSAdvance: proceso y checklist (para que salga bien a la primera)

Proceso típico

1. Descubrimiento: inventario de hosts/CPU/cores, versión actual y necesidades (crecimiento, DR, seguridad).
2. Dimensionado: cálculo por cores + validación de vSAN incluido vs necesario (y si hace falta add-on por TiB).
3. Propuesta: opciones VVF/VCF/vSphere 8 + add-ons, escenarios 1/3/5 años y recomendaciones.
4. Suministro y activación: licencias oficiales y guía para dejarlo operativo sin bloqueos.
5. Implantación (opcional): despliegue, health-checks y mejora continua.

Solicitar cotización de licencias VMware/Broadcom

Errores comunes al comprar licencias por cores (y cómo evitarlos)

• Contar hilos (threads) como cores: licencias por core físico. Si tu cálculo venía de vCPU, revisa.
• Olvidar el mínimo 16 cores/CPU: es el “clásico” que encarece el presupuesto al final.
• Inventario poco fiable: si cambiaste hardware o mezclas generaciones, valida números antes de pedir precio.
• Creer que vSAN incluido = vSAN usable: el diseño (FTT/RAID/ESA/OSA) cambia el usable.
• No planificar el crecimiento: comprar “justo” suele salir caro cuando creces en 9–12 meses.
• Dejar el compliance reporting para el final: debe formar parte de operación desde el día 1.
• No validar HCL y firmwares: en virtualización, compatibilidad ahorra noches en vela.

Preguntas frecuentes (FAQ) — comprar licencias VMware/Broadcom

Recursos oficiales y enlaces externos (para verificar términos)

• VVF SPD (actual): condiciones, métrica por core, mínimos, vSAN incluido y compliance reporting: Página oficial SPD VVF · PDF VVF_SPD_February2026
• VCF SPD (actual): componentes, vSAN incluido, métrica y compliance reporting: Página oficial SPD VCF · PDF VCF_SPD_February2026
• vSAN SPD (suscripción por capacidad): Página oficial SPD vSAN · PDF VMware_vSAN_SPD_February2026
• Product Line Comparison (vSphere): comparación oficial de ediciones y disponibilidad: Documento oficial
• Licensing overview (VCF/VVF): TechDocs Broadcom
• HCL (compatibilidad de hardware): VMware Compatibility Guide

Servicios relacionados en MSAdvance: Suministro y venta de licencias · Todos los servicios.

Conclusión: qué comprar y cómo decidir sin arrepentirte

Comprar licencias VMware/Broadcom hoy no va de “elegir un nombre” (VVF o VCF), sino de cuadrar tres cosas: cores reales, capacidad vSAN (incluida vs necesaria) y operación (soporte, compliance, compatibilidad). Cuando se hace bien, la compra es clara y el TCO se vuelve predecible.

Si quieres, en MSAdvance te ayudamos a convertir tu inventario en una propuesta aterrizada y fácil de defender internamente: qué comprar, cuánto cubre, qué riesgos evitamos y cómo lo implantamos.