Migrar a Proxmox no toca les teves llicències; el failover sí

A cada reunió de migració acaba sortint la pregunta de les llicències de Windows. La resposta curta decep tothom, inclosos els qui esperaven un titular: canviar d'hipervisor no recalcula res. La resposta llarga és la que mou la xifra, i no és al Proxmox ni al VMware. És en una frase de Microsoft sobre capacitat punta.

Abans de continuar, el que ens toca declarar: no venem llicències de ningú. No som resellers de Microsoft, ni de VMware, ni de Proxmox, i no cobrem comissió per cap de les decisions que surten aquí. Tampoc no som assessors de llicenciament. El que ve són les frases literals de la guia de Microsoft i de la documentació de Proxmox, llegides amb la calculadora al costat; el contracte que t'aplica a tu són els teus Product Terms i el teu acord, no aquest article.

Comencem per l'avorrit: l'hipervisor no és a la fórmula

El Windows Server es llicencia pels nuclis físics del servidor. La guia de virtualització de Microsoft ho diu així, i l'excepció del principi importa per al que ve despré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)». Amb Standard, aquest servidor llicenciat et dona dret a executar el sistema «on the physical server and in one VM or in two VMs»; amb 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», i aquí s'acaba la llista. El Proxmox no hi surt, i aquesta absència és bona notícia: l'hipervisor no és una variable de la fórmula, així que no cal que el nomenin. Mateixos servidors, mateixos nuclis, mateixes màquines virtuals enceses, mateix nombre de llicències abans i després de la migració.

La frase que sí que costa diners

Tres coses en una sola frase. Cada servidor. Capacitat punta. Sempre. No «el servidor on corre ara», ni «mentre duri». La llicència de Windows Server no viatja amb la màquina virtual per la via ordinària, i la regla de reassignació de tota la vida acaba de tancar el setge: «This means licenses can be moved, but not more frequently than 90-day intervals», llevat que apliqui alguna excepció — retirar un servidor per avaria permanent de maquinari és la més coneguda, però no l'única, i d'aquí a un moment arribem a la que de debò canvia el compte.

Traduït al teu clúster: tot node on una màquina virtual de Windows pugui arribar a arrencar ha d'estar llicenciat, i ho ha d'estar abans, no en el moment en què arrenqui. Al vSphere era exactament igual. La diferència és que molta gent ho tenia resolt sense recordar que ho tenia resolt: algú va posar en el seu moment una regla que lligava aquelles màquines a un racó del clúster, la va escriure un cop i no hi va tornar a pensar. Aquella regla no viatja dins d'un OVA. Quan muntes el clúster nou, comences sense ella.

Qui decideix en quin node acaba, i per què no n'hi ha prou de dir-l'hi

Del mecanisme ja en vam escriure fa dues setmanes: quan cau un node, el planificador del Proxmox tria el node de recuperació comptant convidats actius, i les regles d'afinitat de node serveixen per dir-li una altra cosa. Aquell post anava d'on torna a arrencar la teva màquina; aquest va de a qui li envien la factura. Aquí només ens cal quedar-nos amb el parell de frases de la documentació que defineixen la strict, perquè és la que dibuixa —o no— el perímetre:

La propietat val 0 per defecte. Si crees la regla com es crea de sèrie —ha-manager rules add node-affinity ha-rule-vm100 --resources vm:100 --nodes node1— el que has escrit és una preferència. El dia que va bé, la màquina és on volies i la regla sembla funcionar; el dia que va malament, que és l'únic en què importava, aterra on calgui. Per convertir-la en un límit s'ha de dir a part: ha-manager rules set node-affinity ha-rule-vm100 --strict 1.

I ara el matís que ens estalviaria discussions si ho digués més gent: aquesta casella és un control, no una frontera contractual. Governa la col·locació automàtica dels recursos donats d'alta al gestor d'HA, i res més. Un administrador pot migrar a mà una màquina a un node que no havies llicenciat, i una màquina que no sigui a HA no la mira ningú. En una auditoria no es revisa el teu rules.cfg: es mira on s'ha executat cada cosa i a quins servidors tens assignades les llicències. La regla t'ajuda a complir la decisió; no la substitueix.

El preu de posar-la a 1

Torna a llegir la segona cita: «the resource will be stopped». Si acotes una màquina als dos nodes que has llicenciat i aquests dos cauen, l'alta disponibilitat no la recupera al tercer. La para. Has comprat un clúster de tres nodes i has escrit a mà que un d'ells no compta.

Aquí hi ha la decisió de debò, i gairebé ningú no l'escriu enlloc: amb la regla laxa t'arrisques a una troballa d'auditoria sense adonar-te'n, i amb la regla estricta t'empasses una caiguda sabent-ho. La nostra opinió, per si serveix: cap de les dues és la resposta. La resposta és decidir expressament quants nodes pot tocar cada màquina de Windows i llicenciar aquests nodes, perquè aquest nombre és una línia del pressupost de la migració que normalment apareix després de signar. Ho diem sovint parlant de rellotges de recuperació i val igual aquí: la fallada és inevitable, l'avaria és una decisió de disseny. La llicència també.

La temptació evident és encongir el clúster fins que el compte surti. Tampoc no és gratis: un clúster de Proxmox no és una llista de nodes intercanviables i cada node que hi afegeixes té el seu propi cost — ho vam mesurar amb corosync i l'aritmètica no era intuïtiva. Aquí passa el mateix, mirant des de l'altre costat.

L'aritmètica, amb els supòsits declarats

Supòsits al davant, perquè canvien el resultat: tres nodes, dos sòcols per node, setze nuclis físics per sòcol — trenta-dos nuclis físics per node. Sis màquines virtuals Windows a tot el clúster, de vuit vCPU cadascuna, i la premissa que en una caiguda qualsevol d'elles pot acabar en qualsevol node. No hi ha preus en el que segueix: són recomptes de llicències, no euros, perquè l'euro depèn del teu acord i no el coneixem.

L'interessant no és el 96. És que el 32 i el 96 descriuen exactament la mateixa instal·lació, amb les mateixes màquines atenent els mateixos usuaris, i que l'única cosa que les separa és una xifra en un fitxer de regles i una decisió sobre quanta disponibilitat vols. Per això pensem que aquesta conversa no pertany al departament de compres: és d'arquitectura, i acaba en una factura.

Hi ha una porta perquè la llicència sí que viatgi, i és de pagament

És l'excepció que sortia a la primera cita, la de «except when licensing by virtual core». La mateixa guia la descriu amb el seu peatge inclòs: «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)». I llavors, només llavors, passa el que gairebé tothom donava per fet des del principi: «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».

Amb aquesta via, el nombre de nodes deixa d'importar dins de la granja i la strict torna a ser una decisió purament tècnica en lloc d'un pany comptable. Amb els supòsits d'abans: sis màquines de vuit vCPU són 48 llicències, davant de les 96 de Datacenter repartides en tres nodes. Amb màquines més grosses o més densitat per node el compte es gira, perquè l'encreuament el marca quants vCPU reparteixes sobre quants nuclis físics i això només ho saps mirant el teu inventari. Si compensa pagar Software Assurance no t'ho podem dir nosaltres: depèn del preu que et facin. El que sí que et podem dir és que el recompte canvia, i que gairebé ningú no el fa abans de decidir.

A aquestes altures, a la reunió, algú sol aixecar la mà i parlar dels drets de recuperació davant de desastres: la llista de beneficis de Software Assurance obre aquest apartat amb un «Windows Server License is not required for the disaster recovery Server if the following conditions are met». Existeix, és real i convé llegir-ho — però les condicions que segueixen són estrictes i descriuen un servidor de recuperació, no un node d'un clúster que atén producció la resta de l'any. Llegeix-les amb el teu reseller abans de comptar-hi.

El SQL Server juga amb unes altres regles, i una va canviar el 2022

Si en aquell clúster hi ha de viure una base de dades, el compte és un altre i el mínim també: la guia de llicenciament per nucli parla de llicenciar cada nucli virtual assignat a la màquina, «with a minimum of four core licenses required per virtual machine». Quatre, no els vuit del Windows Server. Però abans del mínim hi ha una porta, i la seva redacció mereix llegir-se sencera: «If you have subscription licenses or licenses with active Software Assurance for SQL Server 2022, you can license by virtual machine», i tot seguit, «If you use earlier versions with perpetual licenses, you also have this option».

Llegeix-ho a poc a poc, perquè és a l'inrevés del que sona: per a les versions anteriors amb llicència perpètua l'opció continua allà, i és al SQL Server 2022 on llicenciar màquina a màquina passa a exigir subscripció o Software Assurance activa. Qui va comprar 2022 en perpetu i sense SA es troba que la seva base de dades s'ha de llicenciar per nuclis físics — de cada node on pugui acabar. I aquest és justament el SQL que és en alta disponibilitat, perquè era la màquina més crítica. Un detall més, que aquí sí que canvia el resultat: «For licensing purposes, a virtual core maps to a hardware thread». Comptant nuclis físics el hyper-threading no altera el compte; comptant vCPU, sí.

El mite de l'AVMA, que no és teu si vens de vSphere

Tan bon punt es parla de canviar d'hipervisor apareix algú avisant que perdràs l'activació automàtica de les màquines virtuals. La documentació de Microsoft ho tanca en dues frases: «AVMA requires a Windows Server Datacenter edition with the Hyper-V server host role installed» i, per si quedava algun dubte, «AVMA doesn't work with other server virtualization technologies». Si vens de vSphere, mai no el vas tenir. Les teves màquines ja s'activen contra un KMS, amb MAK o per Active Directory, i continuaran fent-ho exactament igual damunt del Proxmox. No hi ha res a perdre perquè no hi havia res.

Dit això, en aquesta mateixa pàgina hi ha una frase que no és teva i que val com a analogia, perquè diu sobre l'activació en clústers de Hyper-V el que les regles de llicenciament diuen 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 és la teva regla; és la mateixa idea, escrita per una vegada en veu alta.

Si vens de Proxmox VE 8, els teus grups ja no es diuen així

Un avís curt per a qui ja tenia clúster i no ve de VMware sinó de la branca anterior. La documentació diu que «HA Groups are deprecated and migrated to HA Node Affinity rules since Proxmox VE 9.0», i les notes d'aquella versió hi posen la condició: «Existing HA groups will be automatically migrated over to node affinity rules once all nodes in the cluster run Proxmox VE 9». És a dir, la conversió no passa enmig d'una actualització rodant. El que abans era un grup restricted passa a ser la propietat strict de què va tot aquest article, així que si vas actualitzar fa mesos i no ho has tornat a mirar, aquesta és la comprovació d'avui.

Què mirem abans de moure la primera màquina

Res d'això no és un argument a favor ni en contra de migrar. És una línia del cas de negoci que sol aparèixer tard i que es calcula igual de bé el dia abans de començar que el dia després de signar, amb la diferència que el dia abans encara pots canviar d'idea. Si ets en aquest punt, ho hem explicat per parts: provar una alternativa no és migrar, i hi ha casos en què el més honest és no migrar.

Fonts (verificades el 26-09-2026): el llicenciament per nuclis físics amb la seva excepció («except when licensing by virtual core») i els mínims de 16 per servidor i 8 per processador, les OSE de Standard i Datacenter, la regla de reassignació de 90 dies, la frase sobre License Mobility across Server Farms i capacitat punta, i les dues cites sobre llicenciar Windows Server per nucli virtual (mínim de 8 llicències per VM i mobilitat dins de la granja) — guia de virtualització de servidors de Microsoft. El mínim de quatre llicències de nucli per màquina virtual al SQL Server, les dues frases sobre llicenciar per VM al SQL Server 2022 i a les versions anteriors amb llicència perpètua, i l'equivalència nucli virtual ↔ fil de maquinari — guia de models de llicenciament per nucli. La reassignació entre granges «not within 90 days of the last assignment» i l'encapçalament dels drets de recuperació davant de desastres — Product Terms, beneficis de Software Assurance. Comportament estricte i no estricte de les regles d'afinitat de node, valor per defecte de strict, ordres de ha-manager i deprecació dels grups HA — documentació d'alta disponibilitat de Proxmox VE i pàgina de manual d'ha-manager; la condició de la conversió automàtica, a les notes de versió de Proxmox VE 9.0. Requisits de l'AVMA i la nota del clúster de commutació per error — Microsoft Learn. Les xifres de l'apartat d'aritmètica són recomptes de llicències calculats per nosaltres sobre els supòsits declarats (tres nodes, dos sòcols, setze nuclis per sòcol, sis màquines de vuit vCPU); no són preus ni una oferta. Les pàgines de guia de Microsoft són el seu propi resum: el document vinculant són els teus Product Terms i el teu contracte, i programes diferents (EA, CSP, OEM, SPLA) canvien condicions. Foto de portada: Wikimedia Commons (CC0).