Todo sobre licencias VMware vSphere y vCenter

Entender cómo funcionan las licencias de VMware se ha vuelto bastante más complejo desde los cambios de modelo comercial y el fin de las licencias perpetuas clásicas. Si manejas entornos con vSphere y vCenter, es normal que te surjan dudas sobre qué pasa cuando expira la licencia, qué ocurre si no renuevas el soporte o cómo te afectan los ciclos de vida de versiones como v7 u v8.

En muchas empresas aún conviven licencias perpetuas antiguas con contratos de soporte activos o caducados, mientras que las nuevas instalaciones se mueven hacia modelos basados en suscripción. Esto genera un lío importante: ¿se apagan los hosts?, ¿pierdes el acceso a vCenter?, ¿las máquinas virtuales siguen funcionando con normalidad? Vamos a desgranarlo con calma, usando ejemplos prácticos y aclarando todos esos matices que no siempre quedan claros en la documentación oficial.

Modelo antiguo de licencias VMware: licencias perpetuas y soporte

Durante muchos años, VMware trabajó con un esquema muy sencillo: licencia perpetua + soporte opcional. Pagabas una vez la licencia de vSphere o vCenter (por CPU, por instancia, etc.) y esa licencia era válida indefinidamente para esa versión principal, por ejemplo, vSphere 7. Sobre esa base, se contrataba un plan de soporte y mantenimiento (SnS) de uno, tres o más años.

Con esa combinación, el comportamiento era claro: mientras el soporte estaba activo, tenías derecho a actualizaciones menores y parches (por ejemplo, de 7.0 a 7.0 Update 3) e incluso, según el contrato, a saltar de una versión mayor a otra (de 7 a 8) si el contrato de mantenimiento lo permitía. Además, podías abrir casos con el soporte técnico de VMware y recibir asistencia oficial.

Cuando el contrato de soporte caducaba, la licencia perpetua seguía siendo válida, pero ya no podías actualizar a nuevas versiones o aplicar ciertos parches que estuvieran ligados al mantenimiento. Tampoco tenías derecho a soporte técnico oficial, aunque el software continuaba funcionando normalmente dentro de la versión que ya tenías desplegada.

Muchos entornos actuales siguen en esta situación: empresas con licencias perpetuas de vSphere/vCenter 7 y un contrato de tres años de soporte que se acerca a su fecha de caducidad. Y aquí es donde empiezan las dudas sobre qué conviene hacer antes de que llegue ese momento, y qué efectos reales tiene dejar expirar el soporte.

Qué ocurre al actualizar de vSphere/vCenter 7 a v8 con licencia antigua

Un caso típico es el de quien dispone de licencias perpetuas de v7 con soporte activo y se plantea actualizar a v8 antes de que el mantenimiento caduque. El razonamiento suele ser: “si actualizo a v8 ahora, ¿podré seguir usando v8 hasta el final de su vida útil, aunque caduque mi soporte dentro de un par de años?”.

En el modelo clásico, mientras tu contrato de soporte esté vigente, puedes actualizar a una versión superior elegible según tu acuerdo (en este ejemplo, pasar de v7 a v8). Una vez hecho el cambio y aplicada la nueva clave o el upgrade correspondiente, tu licencia perpetua queda asociada a vSphere/vCenter 8.

Cuando ese mantenimiento se agote, te quedarás sin derecho a nuevas actualizaciones ni parches más allá de lo ya publicado y disponible mientras tu soporte estaba activo, con el riesgo de encontrar problemas de arranque tras parches. Sin embargo, el software no deja de funcionar. Podrás seguir utilizando vSphere/vCenter 8 hasta que termine oficialmente su ciclo de vida (EoL), siempre y cuando no incumplas otras condiciones del contrato de licencia.

La fecha de fin de vida de una versión mayor, como puede ser vSphere 8 en 2027 (a modo de referencia), marca el punto a partir del cual VMware deja de proporcionar parches, correcciones de seguridad y soporte, aunque tengas o no un contrato activo. Esto significa que, en la práctica, aunque tu licencia perpetua siga siendo válida, operar esa versión más allá de su EoL implica aceptar riesgos de seguridad, compatibilidad y falta total de ayuda oficial.

Por tanto, si tienes margen, una estrategia habitual es aprovechar el periodo de soporte para actualizar a la versión estable más reciente (por ejemplo, v8) antes de que caduque el contrato. De ese modo, maximizas la vida útil de tu entorno dentro de la licencia que ya has pagado, aunque dejes de tener soporte unos años antes del fin de vida oficial de la versión.

Qué pasa cuando caduca la licencia de vCenter Server

Uno de los puntos que más preocupa es entender qué ocurre exactamente cuando caduca la licencia de vCenter Server o termina el periodo de evaluación si estabas probando el producto. El comportamiento en este caso está claramente documentado y conviene tenerlo muy presente para no llevarte un susto.

Cuando la licencia de vCenter expira, el sistema interpreta que ya no tiene una clave válida para gestionar el entorno. Como consecuencia, todos los hosts ESXi gestionados por ese vCenter pasan al estado de desconectados dentro de la interfaz de vCenter. Verás que dejan de responder desde el punto de vista de la consola centralizada, aunque los propios hosts continúan en ejecución.

Es importante remarcar que las máquinas virtuales alojadas en esos hosts no se detienen. Siguen funcionando tal y como estaban antes de la caducidad: los servicios que prestan continúan activos, y los usuarios finales ni siquiera tienen por qué notar el cambio, siempre y cuando no necesites hacer operaciones de gestión centralizada desde vCenter; si necesitas replicar o clonar máquinas virtuales para pruebas, esa gestión habrá de hacerse a nivel de host.

Mientras vCenter permanezca sin licencia válida, no podrás administrar esos hosts desde la consola de vCenter: no tendrás acceso a funciones como vMotion, DRS, HA, plantillas centralizadas o snapshots coordinados desde el inventario de vCenter. Tampoco podrás usar de forma normal la vista de clústeres o realizar tareas orquestadas que dependan de vCenter.

La forma de seguir gestionando tu entorno mientras no renueves la licencia de vCenter es conectarte directamente a cada host ESXi a través de su propia interfaz (por ejemplo, el Host Client web). Desde ahí podrás encender, apagar o reiniciar máquinas virtuales, modificar recursos, montar datastores, etc., pero perderás todas las ventajas de gestión centralizada que ofrece vCenter para entornos de producción medianos o grandes.

Reactivación de vCenter y reconexión de hosts

La buena noticia es que, en cuanto asignas una nueva clave de licencia válida a tu instancia de vCenter Server, el comportamiento se revierte de forma bastante automática. Al introducir la nueva licencia (por ejemplo, renovando o actualizando tu contrato con VMware y aplicando la clave), vCenter vuelve a estar en modo plenamente operativo.

Después de esa reasignación, los hosts ESXi que aparecían como desconectados se reconectan al sistema de vCenter en la mayoría de los casos sin que tengas que hacer nada más. Retoman su estado de gestión previa, recuperan la pertenencia a clústeres y resurgen todas las funcionalidades asociadas a la gestión centralizada.

El inventario de máquinas virtuales también vuelve a mostrarse correctamente en vCenter una vez que los hosts quedan de nuevo conectados. Esto facilita retomar la administración diaria, la monitorización y las tareas de automatización que hubieran quedado interrumpidas durante el periodo sin licencia.

En escenarios complejos, puede ser necesario forzar manualmente la reconexión de algún host o revisar certificados y credenciales, pero desde el punto de vista de licenciamiento, la clave es disponer de una licencia válida de vCenter. Sin ella, el propio diseño del producto impide que se utilice como consola centralizada a largo plazo.

Esto deja claro que, aunque las máquinas virtuales puedan seguir funcionando incluso si la licencia expira, depender de vCenter sin licencia es inviable para cualquier entorno en el que la gestión central sea importante. Es perfectamente posible aguantar así de forma puntual, pero no es una solución estable ni recomendable a medio plazo.

Uso de los sistemas tras el vencimiento de la licencia o del soporte

Conviene distinguir bien entre caducidad de licencia y fin del contrato de soporte, porque sus efectos prácticos no son los mismos. Cuando lo que caduca es la clave de vCenter (por evaluación o por límite de uso), lo que sucede ya lo hemos visto: los hosts se desconectan de vCenter, aunque las máquinas virtuales sigan ejecutándose.

Si lo que finaliza es el contrato de soporte y actualizaciones (SnS) asociado a tu licencia perpetua, el software continúa funcionando de manera normal. No se desconecta nada, ni se apagan servicios, ni se desactivan características de golpe. Simplemente pierdes el derecho a nuevas versiones, a determinados parches y a la asistencia técnica oficial.

En ese escenario, puedes seguir utilizando tus sistemas vSphere/vCenter sin problemas, pero debes aceptar una serie de limitaciones: no podrás actualizar a nuevas build soportadas oficialmente si se liberan después de la fecha de fin de soporte para ti, y en caso de incidencias complejas no contarás con respaldo directo de VMware. Por tanto, conviene disponer de procedimientos para realizar backups de máquinas virtuales y mitigar riesgos operativos.

Por eso, para muchas organizaciones, la principal motivación para renovar es precisamente mantener el acceso a actualizaciones críticas y parches de seguridad. En infraestructuras donde la seguridad y la estabilidad son clave, operar con una versión antigua sin parches puede convertirse en un riesgo difícil de justificar a nivel de auditoría o cumplimiento normativo.

Además, si planeas integrar tu entorno con nuevos hardware o nuevas aplicaciones que requieran versiones recientes de vSphere o de las VMware Tools, es probable que, sin soporte activo, te veas atado a un stack desactualizado y tengas problemas de compatibilidad que no podrás resolver fácilmente.

Motivos para renovar o migrar a un modelo actual de licencias

Aunque la tentación de “aguantar con lo que hay” es comprensible, conviene sopesar bien los motivos para renovar licencias o adoptar el nuevo modelo de suscripción de VMware. Ya no se trata solo de tener o no soporte, sino de cómo encaja tu entorno dentro del ciclo de vida oficial de la plataforma.

Uno de los factores clave es el fin de vida (EoL) de la versión que estás utilizando. Llegado ese punto, incluso aunque tu licencia sea “perpetua”, la plataforma deja de recibir parches y revisiones de seguridad, y el fabricante no se compromete a ayudarte en caso de problemas graves. Operar en producción con un producto fuera de soporte siempre incrementa el riesgo.

Otro elemento a tener en cuenta es la compatibilidad con nuevas funcionalidades y con el resto del ecosistema VMware (NSX, vSAN, herramientas de backup, etc.). Muchas veces, para poder beneficiarte de mejoras importantes de rendimiento, seguridad o automatización, necesitas estar en una versión relativamente reciente, lo que suele exigir un contrato de soporte activo o una suscripción vigente.

Desde el punto de vista puramente operativo, muchas empresas optan por renovar licencias y soporte por una cuestión de tranquilidad: saber que, en caso de error grave, bug en una build concreta o incidente de seguridad, hay un fabricante detrás al que pueden escalar y obtener parches o soluciones temporales.

Por último, hay que considerar que VMware ha ido moviendo su estrategia hacia modelos de licenciamiento por suscripción, especialmente en entornos modernos o integrados con la nube. Esto hace que, a medio plazo, seguir anclado a licencias perpetuas antiguas pueda convertirse en un freno a la hora de adoptar nuevas soluciones o integraciones con otros servicios del fabricante.

Buenas prácticas para gestionar licencias vSphere y vCenter

Para evitar sorpresas y cortes de servicio en tu infraestructura, es recomendable aplicar una serie de buenas prácticas de gestión de licencias en entornos VMware, especialmente cuando combinas versiones antiguas y nuevas o distintos tipos de contrato.

La primera recomendación es llevar un control riguroso de las fechas de caducidad de licencias y contratos de soporte. Registrar esos hitos en tu herramienta de gestión (ITSM, CMDB, calendario corporativo, etc.) te permitirá planificar renovaciones o migraciones con suficiente margen, en lugar de reaccionar a última hora.

También resulta útil documentar claramente qué hosts y qué instancias de vCenter usan cada tipo de licencia, así como el estado de su mantenimiento. Esto facilita tomar decisiones informadas, por ejemplo, sobre qué clúster merece la pena actualizar primero a v8 o a una modalidad de suscripción más moderna.

Otro aspecto clave es probar en un entorno de laboratorio las actualizaciones de versión o los cambios de licenciamiento, para evitar encontrarte con problemas inesperados en producción y para practicar cómo crear máquinas virtuales ligeras que sirvan para pruebas rápidas. La actualización de v7 a v8, por ejemplo, puede implicar cambios de compatibilidad con ciertos plugins, herramientas de backup o integraciones de terceros.

Por último, conviene revisar periódicamente la política de ciclo de vida de VMware para las versiones que tienes desplegadas. Estar al tanto de las fechas de fin de soporte general o extendido te ayudará a no quedarte atascado en una release obsoleta justo cuando necesitas incorporar nuevo hardware o nuevas funcionalidades de plataforma.

Teniendo claros todos estos matices —desde la diferencia entre licencias perpetuas y suscripción, hasta el comportamiento concreto de vCenter al expirar su licencia— resulta más sencillo tomar decisiones equilibradas sobre qué hacer con tus licencias VMware. En la mayoría de casos, el objetivo es encontrar el punto medio adecuado entre coste, seguridad, estabilidad y capacidad de evolución tecnológica, sin perder nunca de vista cómo impacta todo ello en la continuidad de los servicios que tus máquinas virtuales están prestando.