Migrar a Proxmox no toca tus licencias; el failover sí

En toda reunión de migración acaba saliendo la pregunta de las licencias de Windows. La respuesta corta decepciona a todo el mundo, incluidos los que esperaban un titular: cambiar de hipervisor no recalcula nada. La respuesta larga es la que mueve la cifra, y no está en Proxmox ni en VMware. Está en una frase de Microsoft sobre capacidad punta.

Antes de seguir, lo que nos toca declarar: no vendemos licencias de nadie. No somos resellers de Microsoft, ni de VMware, ni de Proxmox, y no cobramos comisión por ninguna de las decisiones que salen aquí. Tampoco somos asesores de licenciamiento. Lo que viene son las frases literales de la propia guía de Microsoft y de la documentación de Proxmox, leídas con la calculadora al lado; el contrato que te aplica a ti son tus Product Terms y tu acuerdo, no este artículo.

Empecemos por lo aburrido: el hipervisor no está en la fórmula

Windows Server se licencia por los núcleos físicos del servidor. La guía de virtualización de Microsoft lo dice así, y la excepción del principio importa para lo que viene después: «In either case, except when licensing by virtual core, all of the physical cores on the server must be licensed (subject to a minimum of 16 per server and eight per processor)». Con Standard, ese servidor licenciado te da derecho a ejecutar el sistema «on the physical server and in one VM or in two VMs»; con Datacenter, «and in any number of VMs».

La página enumera «virtualization technologies, such as Microsoft Hyper-V technology, or third-party virtualization solutions provided by VMware and Parallels», y ahí se acaba la lista. Proxmox no sale, y esa ausencia es buena noticia: el hipervisor no es una variable de la fórmula, así que no hace falta que lo nombren. Mismos servidores, mismos núcleos, mismas máquinas virtuales encendidas, mismo número de licencias antes y después de la migración.

La frase que sí cuesta dinero

Tres cosas en una sola frase. Cada servidor. Capacidad punta. Siempre. No «el servidor donde está corriendo ahora», ni «mientras dure». La licencia de Windows Server no viaja con la máquina virtual por la vía ordinaria, y la regla de reasignación de toda la vida acaba de cerrar el cerco: «This means licenses can be moved, but not more frequently than 90-day intervals», salvo que aplique alguna excepción — retirar un servidor por avería permanente de hardware es la más conocida, pero no la única, y en un momento llegamos a la que de verdad cambia la cuenta.

Traducido a tu clúster: todo nodo en el que una máquina virtual de Windows pueda llegar a arrancar tiene que estar licenciado, y tiene que estarlo antes, no en el momento en que arranque. En vSphere era exactamente igual. La diferencia es que mucha gente lo tenía resuelto sin recordar que lo tenía resuelto: alguien puso en su momento una regla que ataba esas máquinas a un rincón del clúster, la escribió una vez y no volvió a pensar en ella. Esa regla no viaja dentro de un OVA. Cuando montas el clúster nuevo, empiezas sin ella.

Quién decide en qué nodo acaba, y por qué no basta con decírselo

Del mecanismo ya escribimos hace dos semanas: cuando cae un nodo, el planificador de Proxmox elige el nodo de recuperación contando invitados activos, y las reglas de afinidad de nodo sirven para decirle otra cosa. Aquel post iba de dónde vuelve a arrancar tu máquina; este va de a quién le mandan la factura. Aquí solo necesitamos quedarnos con el par de frases de la documentación que definen la strict, porque es la que dibuja —o no— el perímetro:

La propiedad vale 0 por defecto. Si creas la regla como se crea de serie —ha-manager rules add node-affinity ha-rule-vm100 --resources vm:100 --nodes node1— lo que has escrito es una preferencia. El día que va bien, la máquina está donde querías y la regla parece funcionar; el día que va mal, que es el único en el que importaba, aterriza donde haga falta. Para convertirla en un límite hay que decirlo aparte: ha-manager rules set node-affinity ha-rule-vm100 --strict 1.

Y ahora el matiz que nos ahorraría discusiones si lo dijera más gente: esa casilla es un control, no una frontera contractual. Gobierna la colocación automática de los recursos dados de alta en el gestor de HA, y nada más. Un administrador puede migrar a mano una máquina a un nodo que no habías licenciado, y una máquina que no esté en HA no la mira nadie. En una auditoría no se revisa tu rules.cfg: se mira dónde se ha ejecutado cada cosa y a qué servidores tienes asignadas las licencias. La regla te ayuda a cumplir la decisión; no la sustituye.

El precio de ponerla a 1

Vuelve a leer la segunda cita: «the resource will be stopped». Si acotas una máquina a los dos nodos que has licenciado y esos dos se caen, la alta disponibilidad no la recupera en el tercero. La para. Has comprado un clúster de tres nodos y has escrito a mano que uno de ellos no cuenta.

Ahí está la decisión de verdad, y casi nadie la escribe en ningún sitio: con la regla laxa te arriesgas a un hallazgo de auditoría sin enterarte, y con la regla estricta te comes una caída a sabiendas. Nuestra opinión, por si sirve: ninguna de las dos es la respuesta. La respuesta es decidir a propósito cuántos nodos puede tocar cada máquina de Windows y licenciar esos nodos, porque ese número es una línea del presupuesto de la migración que normalmente aparece después de firmar. Lo decimos a menudo hablando de relojes de recuperación y vale igual aquí: el fallo es inevitable, la avería es una decisión de diseño. La licencia también.

La tentación evidente es encoger el clúster hasta que la cuenta salga. Tampoco es gratis: un clúster de Proxmox no es una lista de nodos intercambiables y cada nodo que añades tiene su propio coste — lo medimos con corosync y la aritmética no era intuitiva. Aquí ocurre lo mismo, mirando desde el otro lado.

La aritmética, con los supuestos declarados

Supuestos por delante, porque cambian el resultado: tres nodos, dos zócalos por nodo, dieciséis núcleos físicos por zócalo — treinta y dos núcleos físicos por nodo. Seis máquinas virtuales Windows en todo el clúster, de ocho vCPU cada una, y la premisa de que en una caída cualquiera de ellas puede acabar en cualquier nodo. No hay precios en lo que sigue: son recuentos de licencias, no euros, porque el euro depende de tu acuerdo y no lo conocemos.

Lo interesante no es el 96. Es que el 32 y el 96 describen exactamente la misma instalación, con las mismas máquinas atendiendo a los mismos usuarios, y que lo único que las separa es una cifra en un fichero de reglas y una decisión sobre cuánta disponibilidad quieres. Por eso pensamos que esta conversación no pertenece al departamento de compras: es de arquitectura, y acaba en una factura.

Hay una puerta para que la licencia sí viaje, y es de pago

Es la excepción que salía en la primera cita, la de «except when licensing by virtual core». La misma guía la describe con su peaje incluido: «Licensing Windows Server by virtual core requires the number of subscription licenses or licenses with active Software Assurance equal to the number of virtual cores in the VM (subject to a minimum of 8 licenses per VM)». Y entonces, solo entonces, pasa lo que casi todo el mundo daba por hecho desde el principio: «As an exception to this, when licensing Windows Server by VM, customers may move subscription licenses or licenses with Software Assurance at any time to another server within the same server Farm».

Con esa vía, el número de nodos deja de importar dentro de la granja y la strict vuelve a ser una decisión puramente técnica en lugar de un candado contable. Con los supuestos de antes: seis máquinas de ocho vCPU son 48 licencias, frente a las 96 de Datacenter repartidas en tres nodos. Con máquinas más gordas o más densidad por nodo la cuenta se da la vuelta, porque el cruce lo marca cuántos vCPU repartes sobre cuántos núcleos físicos y eso solo lo sabes mirando tu inventario. Si compensa pagar Software Assurance no te lo podemos decir nosotros: depende del precio que te hagan. Lo que sí podemos decirte es que el recuento cambia, y que casi nadie lo hace antes de decidir.

A estas alturas, en la reunión, alguien suele levantar la mano y hablar de los derechos de recuperación ante desastres: la lista de beneficios de Software Assurance abre ese apartado con un «Windows Server License is not required for the disaster recovery Server if the following conditions are met». Existe, es real y conviene leerlo — pero las condiciones que siguen son estrictas y describen un servidor de recuperación, no un nodo de un clúster que está atendiendo producción el resto del año. Léelas con tu reseller antes de contar con ellas.

SQL Server juega con otras reglas, y una cambió en 2022

Si en ese clúster va a vivir una base de datos, la cuenta es otra y el mínimo también: la guía de licenciamiento por núcleo habla de licenciar cada núcleo virtual asignado a la máquina, «with a minimum of four core licenses required per virtual machine». Cuatro, no los ocho de Windows Server. Pero antes del mínimo hay una puerta, y su redacción merece leerse entera: «If you have subscription licenses or licenses with active Software Assurance for SQL Server 2022, you can license by virtual machine», y a continuación, «If you use earlier versions with perpetual licenses, you also have this option».

Léelo despacio, porque es al revés de lo que suena: para las versiones anteriores con licencia perpetua la opción sigue ahí, y es en SQL Server 2022 donde licenciar máquina a máquina pasa a exigir suscripción o Software Assurance activa. Quien compró 2022 en perpetuo y sin SA se encuentra con que su base de datos hay que licenciarla por núcleos físicos — de cada nodo donde pueda acabar. Y ese es justamente el SQL que está en alta disponibilidad, porque era la máquina más crítica. Un detalle más, que aquí sí cambia el resultado: «For licensing purposes, a virtual core maps to a hardware thread». Contando núcleos físicos el hyper-threading no altera la cuenta; contando vCPU, sí.

El mito de AVMA, que no es tuyo si vienes de vSphere

Tan pronto como se habla de cambiar de hipervisor aparece alguien avisando de que vas a perder la activación automática de las máquinas virtuales. La documentación de Microsoft lo zanja en dos frases: «AVMA requires a Windows Server Datacenter edition with the Hyper-V server host role installed» y, por si quedaba alguna duda, «AVMA doesn't work with other server virtualization technologies». Si vienes de vSphere, nunca lo tuviste. Tus máquinas ya se activan contra un KMS, con MAK o por Active Directory, y van a seguir haciéndolo exactamente igual encima de Proxmox. No hay nada que perder porque no había nada.

Dicho eso, en esa misma página hay una frase que no es tuya y que vale como analogía, porque dice sobre la activación en clústeres de Hyper-V lo que las reglas de licenciamiento dicen de manera indirecta: «In a failover cluster, each virtualization server host in the cluster must be activated for guest VMs to stay activated, regardless of which server they run on». Regardless of which server they run on. No es tu regla; es la misma idea, escrita por una vez en voz alta.

Si vienes de Proxmox VE 8, tus grupos ya no se llaman así

Un aviso corto para quien ya tenía clúster y no viene de VMware sino de la rama anterior. La documentación dice que «HA Groups are deprecated and migrated to HA Node Affinity rules since Proxmox VE 9.0», y las notas de esa versión ponen la condición: «Existing HA groups will be automatically migrated over to node affinity rules once all nodes in the cluster run Proxmox VE 9». Es decir, la conversión no ocurre a mitad de una actualización rodante. Lo que antes era un grupo restricted pasa a ser la propiedad strict de la que va todo este artículo, así que si actualizaste hace meses y no has vuelto a mirarlo, esa es la comprobación de hoy.

Lo que miramos antes de mover la primera máquina

Nada de esto es un argumento a favor ni en contra de migrar. Es una línea del caso de negocio que suele aparecer tarde y que se calcula igual de bien el día antes de empezar que el día después de firmar, con la diferencia de que el día antes todavía puedes cambiar de idea. Si estás en ese punto, lo hemos contado por partes: probar una alternativa no es migrar, y hay casos en los que lo más honesto es no migrar.

Fuentes (verificadas el 26-09-2026): el licenciamiento por núcleos físicos con su excepción («except when licensing by virtual core») y los mínimos de 16 por servidor y 8 por procesador, las OSE de Standard y Datacenter, la regla de reasignación de 90 días, la frase sobre License Mobility across Server Farms y capacidad punta, y las dos citas sobre licenciar Windows Server por núcleo virtual (mínimo de 8 licencias por VM y movilidad dentro de la granja) — guía de virtualización de servidores de Microsoft. El mínimo de cuatro licencias de núcleo por máquina virtual en SQL Server, las dos frases sobre licenciar por VM en SQL Server 2022 y en versiones anteriores con licencia perpetua, y la equivalencia núcleo virtual ↔ hilo de hardware — guía de modelos de licenciamiento por núcleo. La reasignación entre granjas «not within 90 days of the last assignment» y el encabezado de los derechos de recuperación ante desastres — Product Terms, beneficios de Software Assurance. Comportamiento estricto y no estricto de las reglas de afinidad de nodo, valor por defecto de strict, órdenes de ha-manager y deprecación de los grupos HA — documentación de alta disponibilidad de Proxmox VE y página de manual de ha-manager; la condición de la conversión automática, en las notas de versión de Proxmox VE 9.0. Requisitos de AVMA y la nota del clúster de conmutación por error — Microsoft Learn. Las cifras del apartado de aritmética son recuentos de licencias calculados por nosotros sobre los supuestos declarados (tres nodos, dos zócalos, dieciséis núcleos por zócalo, seis máquinas de ocho vCPU); no son precios ni una oferta. Las páginas de guía de Microsoft son su propio resumen: el documento vinculante son tus Product Terms y tu contrato, y programas distintos (EA, CSP, OEM, SPLA) cambian condiciones. Foto de portada: Wikimedia Commons (CC0).