L'API per declarar les teves VM ja és neutral; el proveïdor que la compleix, no

El 9 de novembre, Broadcom va anunciar que VM API entra al Sandbox de la CNCF: unes CRD de Kubernetes per declarar una màquina virtual amb el mateix YAML, tant se val quin hipervisor hi hagi a sota. L'endemà, al seu propi blog, hi ha la frase que ho matisa: «the specific features, performance, and operational outcomes will depend on the underlying provider executing that request». Les dues coses són al mateix document i totes dues són certes. El que viatja és la petició. El que no viatja és el resultat.

Escrivim això des d'una posició còmoda: no som resellers de cap plataforma —ni de VMware, ni de Proxmox— i les operem totes dues, a més de Kubernetes i Docker Swarm en producció. És a dir, d'aquest anunci no en traiem comissió per cap banda, i per això podem dir la part que no surt a les notes de premsa: que per a la majoria d'empreses que ens llegeixen, avui això no canvia absolutament res, i que l'interessant no és l'anunci sinó les costures que ja es veuen.

El que es va anunciar, amb les dates posades

L'expedient és més llarg que el titular, i convé tenir-lo sencer. La sol·licitud la va obrir un enginyer de Broadcom el 2 de setembre del 2026. El TOC de la CNCF va aprovar portar-la a votació el 22 de setembre amb dues condicions escrites: «that the project moves kubevm out of the vmware repositories and demonstrates the pluggability of at least two providers». La votació es va tancar a favor el 28 de setembre —72,73 % dels vots vinculants, vuit a favor, cap en contra—, la incidència es va tancar el 28 d'octubre en crear-se la d'incorporació, i l'anunci públic de Broadcom va arribar el 9 de novembre. Pel camí el projecte va canviar de nom: es deia KubeVM i el 8 d'octubre el seu autor va explicar que la CNCF desaconsella «kube» als noms, així que va passar a vm-api, «similar to cluster-api». Aquest detall administratiu explica de passada per què hi ha dos repositoris voltant. El projecte introdueix un recurs VirtualMachine al grup d'API vm-api.io, més primitives a sobre: VirtualMachineReplicaSets i VirtualMachineDeployments, que són exactament el que semblen. El patró el diu la mateixa sol·licitud sense giragonses: «the pattern is Cluster API's core-plus-providers split, applied to VM lifecycle rather than cluster lifecycle». Nucli genèric, proveïdors endollables, i un contracte d'estat entre tots dos perquè el nucli no importi codi de cap proveïdor. Com a decisió d'arquitectura és bona i convé dir-ho abans de posar-se crític.

Dos matisos de calendari que canvien com cal llegir tota la resta. El primer: Sandbox és la porta d'entrada de la CNCF, l'esglaó on s'accepten projectes joves; no és un segell de maduresa ni una recomanació d'ús. El segon: el repositori públic vm-api/vm-api es va crear el 30 d'octubre del 2026, amb llicència Apache 2.0, i l'API va per v1alpha1. Aquesta etiqueta no és decorativa: alpha a Kubernetes vol dir que els camps poden canviar o desaparèixer entre versions. El codi de fons no és nou —se sustenta en vm-operator, amb «more than six years of continuous enterprise development» dins de vSphere—, però el contracte portable que es discuteix aquí sí que ho és.

Les dues frases del mateix document

No cal anar a buscar cap crític per trobar la lletra petita: és a l'article que va publicar Broadcom el 10 de novembre, a unes línies de distància: una al paràgraf que explica l'avantatge principal i l'altra a la taula que ve just després. Posar-les l'una al costat de l'altra ja diu gairebé tot de l'anunci. El que falta és a les costures.

No resoldrem quina de les dues columnes pesa més, perquè això ho decideix el teu cas i no el nostre. Si el que et fa mal és que cada plataforma es demani d'una manera diferent i el teu equip de producte vol demanar una VM igual que demana un deployment, la columna de l'esquerra és una millora real. Si el que et fa mal és la factura o l'hipervisor de sota, la columna de la dreta et diu que allà no s'ha mogut res: la peça que converteix el teu YAML en una màquina encesa continua sent un producte comercial sobre VCF. L'estàndard obert és la petició; el que la compleix al teu ferro actual és d'algú.

On s'esquerda l'abstracció: la teva VM portable no porta màscara de xarxa

Una abstracció es jutja per les seves costures, i aquí n'hi ha dues de documentades per algú que ha anat a buscar-les amb les mans. El 7 d'octubre del 2026, un desenvolupador extern va obrir una incidència al repositori de vm-operator explicant que havia escrit un proveïdor per a Proxmox VE seguint la guia oficial, i de passada hi va deixar dues observacions sobre el contracte. La segona és la que convé llegir a poc a poc si alguna vegada has configurat una IP fixa a mà.

Les adreces de xarxa del recurs portable, diu, «are bare IPs with no prefix length and no gateway». I hi afegeix per què això n'hi ha prou en un lloc i no en un altre: «That is enough for platforms that hand out addresses (EC2, GCE) but not for ones that configure the guest directly». És exacte. A AWS o a Google tu demanes una màquina i la plataforma li reparteix l'adreça; el convidat se n'assabenta per DHCP i ningú no necessita escriure cap màscara. En un hipervisor que configura el convidat —Proxmox amb cloud-init, i el mateix autor sospita que vSphere és a la mateixa situació amb la seva guest customization— el paràmetre ipconfigN necessita CIDR i porta d'enllaç. Si el contracte portable no sap expressar-los, aquestes dues dades acaben en camps específics del proveïdor. És a dir: al lloc exacte on torna a començar l'acoblament del qual l'abstracció venia a alliberar-te.

La primera observació és més subtil i més interessant per a qualsevol que operi Proxmox. «Every Proxmox state change (clone, start, shutdown, stop, resize, destroy) returns a task UPID and completes later». Els dos exemples de la guia són una plataforma síncrona —demanes i et contesta— i una de consistent per consulta, estil EC2. Proxmox és una tercera forma: et torna l'identificador d'una tasca i la feina continua passant després, amb un estat «en transició» que pot durar minuts. El que cal vigilar no és l'objecte, és la tasca; i si tornes a conciliar mentre una tasca s'està executant, el correcte és adoptar-la, no llançar-ne una segona. Qui hagi automatitzat Proxmox amb pressa i s'hagi trobat dues clonacions de la mateixa plantilla sap exactament de què va això.

Convé ser justos amb això: són costures primerenques i normals en una cosa marcada v1alpha1, i estan escrites per algú que a més s'ofereix a redactar la secció que falta a la guia. No són un defecte escandalós. Són la mesura exacta de quanta portabilitat hi ha avui, que és diferent de quanta n'hi haurà.

Ja existeix un proveïdor per a Proxmox, i fa trenta-cinc dies que espera

El proveïdor d'aquella incidència no és una maqueta. Segons el seu autor, implementa el recurs VirtualMachine contra una VM QEMU clonada d'una plantilla, amb dimensionament, cloud-init natiu (claus SSH, nom d'equip, DNS, IPv4 per DHCP o fixa), encesa i apagada amb els tres modes de l'API, adreces obtingudes de l'agent convidat i esborrat. I està provat en tres nivells: unitàries contra un Proxmox en memòria, envtest amb nucli i proveïdor sobre un servidor d'API real, i d'extrem a extrem contra Proxmox VE 9.2 real, en arm64 i en amd64 sota KVM imbricat. El repositori és públic i Apache 2.0, creat el 6 d'octubre.

Les seves dues preguntes són de les que no es poden contestar sol: on haurien de viure els proveïdors de tercers, i si un proveïdor d'hipervisor els serveix ara mateix per sostenir l'argument que «l'API generalitza». A 11 de novembre, el fil no té cap resposta pública. Trenta-cinc dies. I la pregunta no és retòrica: la condició que va posar el TOC per portar el projecte a votació va ser, literalment, demostrar «the pluggability of at least two providers». Mentrestant, la taula de l'article de Broadcom llista «KubeVM Service (vSphere), Proxmox, KubeVirt, etc.» a la fila de proveïdors locals, amb una nota al peu que avisa que aquella taula «illustrates these potential options» i «does not represent all currently available providers». És a dir: Proxmox apareix com a possibilitat al dibuix, i qui ha escrit el proveïdor espera resposta.

Abans de treure conclusions, els contrapesos. La incidència és oberta al repositori vm-operator i no al nou vm-api, que ni tan sols existia quan es va escriure, de manera que pot ser senzillament a la bústia equivocada; el projecte ha passat aquestes setmanes canviant-se de nom i de casa; i el silenci a GitHub no és una negativa, perquè hi ha converses que passen a llistes, a Slack o en una trucada. Tampoc no és l'únic tercer que s'ha adreçat al projecte, ni el primer: això ve ara. El que diem és que a dia d'avui aquell fil concret continua obert i sense contestar, i que és una dada que qualsevol pot anar a comprovar.

La part de l'expedient que no va sortir a cap nota de premsa

L'11 d'octubre, dues setmanes després de la votació, dos autors de projectes de virtualització van entrar a la sol·licitud a dir que no estaven d'acord amb com se'ls havia descrit. El primer, autor de KubeSwift i VirtRigaud: «VirtRigaud is currently used in production, it does support extended lifecycle management of VSphere, LibVirt and Proxmox Hypervisors and VM Migration across hypervisors». És a dir, un projecte de tercers que ja porta Proxmox en producció i que a més mou màquines entre hipervisors. La seva queixa de fons: la sol·licitud descrivia aquells treballs com a intents «with limited adoption» davant d'una implementació «production-proven ... from the outset», quan el codi del sol·licitant vivia aleshores en una branca d'un altre repositori.

El segon, autor de banlieue i amic declarat de l'anterior —ho diu ell, no nosaltres—, va posar per escrit l'objecció que més pesa aquí, perquè és la mateixa que sosté aquest post des de l'entradeta: «My main concern is that the case for vendor neutrality rests on things that don't exist yet». I la sostenia en la mateixa sol·licitud: el controlador genèric era aleshores «the first milestone on the roadmap and is not yet written», i l'únic proveïdor en producció era VM Operator, que és alhora el pla de control del producte comercial de Broadcom. Un mes després, aquell controlador ja existeix i té repositori propi. L'objecció no era profètica; era una data.

Hi va haver respostes, i cal explicar-les igual d'alt. El sol·licitant va contestar el 13 d'octubre, es va disculpar per la tardança —«I apologize for not getting to the comments earlier»— i va explicar d'on venia la confusió. Dies abans, el 5 d'octubre, ja havia respost en públic a qui preguntava en què es diferencia això de Cluster API. I la CNCF va recordar que el solapament entre projectes no és motiu de rebuig, en línia amb el seu principi de «no kingmakers», i que la sol·licitud ja s'havia revisat pels seus mèrits. Així que la foto no és «ningú contesta a ningú»: es va contestar a les objeccions de fons i a la comparació amb Cluster API. El que continua sense contestar, al seu fil, és l'oferta d'un segon proveïdor, que resulta ser una de les dues condicions que va posar el TOC. Per a qui compra infraestructura això no és xafarderia de repositori: és la manera més barata que hi ha de distingir la neutralitat que s'afirma en una diapositiva de la que aguanta quan hi entren tercers a discutir-la per escrit.

L'altra pregunta sense contestar: i KubeVirt?

El 4 de novembre, amb la votació del TOC tancada a favor des del setembre, algú va obrir al repositori de VM API una pregunta incòmoda i ben feta. L'argument és sòlid, i el calendari l'ha reforçat sol. KubeVirt ja és una API de VM nativa de Kubernetes: va entrar al Sandbox el setembre del 2019, va passar a incubació l'abril del 2022 i la seva votació de graduació es va aprovar aquell mateix 4 de novembre amb un 81,82 % a favor, tres minuts abans que s'obrís la pregunta. La CNCF ho va anunciar en públic el 10 de novembre, al KubeCon de Salt Lake City, amb 2.088 contribuïdors de 520 organitzacions a l'esquena. Dit d'una altra manera: la setmana que VM API va entrar per l'esglaó de baix, el projecte amb què se'l compara sortia pel de dalt. I ja no està lligat a QEMU/KVM: hi ha feina explícita per desacoblar el nucli de la lògica específica de KVM, i una integració amb Hyper-V com a prova que pot suportar més hipervisors. La pregunta, doncs, és directa: per què cal una capa genèrica més, al costat o per damunt de la que ja existeix? I la ironia que la fa més esmolada: el mateix pla de ruta de VM API llista KubeVirt com un dels seus futurs proveïdors.

Setze minuts després, el mateix autor va declarar el seu conflicte d'interès —«I am actively involved in KubeVirt»— i va ampliar la pregunta cap a Cluster API, que és d'on ve el patró: si el disseny calca el contracte de Machine, què passa amb la propietat del cicle de vida quan una VM és alhora node d'un clúster? Una setmana més tard, aquell fil continua sense resposta del projecte. La pregunta general —en què es diferencia això de Cluster API— sí que es va contestar, i en públic, com acabem de veure; el que continua obert és aquesta variant concreta sobre qui és l'amo del cicle de vida. Aquí tampoc no prenem partit: la pregunta la fa una part interessada, i és perfectament possible que la resposta sigui bona i estigui sense escriure. Però dues API competint per ser el lloc on es declara una màquina virtual és, exactament, el problema que un estàndard venia a resoldre.

Què canvia això si tens quaranta màquines virtuals (avui, res)

Aquesta és la part que no interessa explicar a ningú que vengui alguna cosa. Si la teva empresa té un clúster de virtualització amb unes desenes de VM, un parell de persones que el mantenen i Kubernetes enlloc, posar les teves VM darrere d'un pla de control de Kubernetes no t'arregla cap problema que tinguis avui. T'hi afegeix un segon pla de control sobre el mateix hipervisor: una altra cosa per actualitzar, una altra cosa per vigilar, i un domini de fallada nou damunt d'un que ja existia. La pregunta de resiliència que cal fer-se abans que cap altra és què passa quan aquell clúster cau, i si les teves màquines continuen arrencant sense ell.

I hi ha un cost recurrent que gairebé ningú suma quan decideix això en una pissarra: el calendari. Kubernetes publica una versió nova cada quatre mesos, el suport de cadascuna dura catorze, i les actualitzacions no se salten versions; ho expliquem amb les dates a Kubernetes caduca cada catorze mesos i no es salten versions. Aquest és el preu real de tenir un pla de control, i es paga tant si tens quaranta VM com quatre-centes. Si la decisió de fons que tens damunt la taula és quin orquestrador necessites de debò, el criteri està escrit sense dogma a Docker Swarm no és mort: el que de debò estàs triant.

Quan sí que té sentit mirar-s'ho, doncs. Val la pena mirar-s'ho amb atenció si ja operes Kubernetes en producció i tens algú que el manté; si el teu equip de producte demana infraestructura per YAML i GitOps i les VM són l'excepció que es demana per correu; o si portes contenidors i màquines virtuals amb dos fluxos diferents i això et costa hores cada setmana. En aquest escenari, declarar totes dues coses igual és una millora de debò.

Les cinc preguntes abans que això entri en un contracte

Quan algú t'ensenyi una diapositiva amb una API neutral al centre i diversos hipervisors penjant, aquestes cinc preguntes serveixen per separar el que està estandarditzat del que està dibuixat. Valen per a VM API i valen per a qualsevol capa d'abstracció que et venguin després.

El que fem nosaltres amb un anunci així

El llegim, l'anotem i continuem. Operem Proxmox VE amb Ceph en producció, portem VMware des de versions antigues i desplegem tant Kubernetes com Docker Swarm, inclòs Kubernetes gestionat: som agnòstics d'orquestrador perquè no cobrem per cap. Quan una capa com aquesta maduri i un proveïdor seriós la compleixi sobre la plataforma que ja tens, serà el moment d'explicar-ho una altra vegada amb números. Avui l'honest és dir que està en v1alpha1, que la votació que el va posar al Sandbox es va tancar el setembre amb dues condicions i una continua oberta, i que la peça que la compleix sobre VCF és comercial.

Si tens aquesta decisió damunt la taula —o la de més avall, que és quin hipervisor vols per als propers cinc anys—, és exactament la feina de la nostra consultoria IT: posar números a les dues opcions sense cobrar comissió de cap. La capa de sota la muntem nosaltres, a infraestructura i cloud, i si el que mires és sortir de VMware, el camí per capes amb tornada enrere és a migració de VMware a Proxmox.

Fonts (consultades l'11-11-2026): l'anunci de la contribució i la data d'acceptació al Sandbox són de la nota de premsa de Broadcom del 09-11-2026. Les cites sobre intenció portable, resultats que depenen del proveïdor, KubeVM Service com a proveïdor comercial sobre VCF, la taula de proveïdors amb Proxmox i la nota «It does not represent all currently available providers» surten de l'article How VM API and KubeVM Service Deliver Open Standards and Enterprise Execution, publicat el 10-11-2026 al blog de VMware Cloud Foundation. La descripció del recurs VirtualMachine, el grup d'API inicial —que aleshores era kube-vm.io, abans del canvi de nom—, les primitives de rèpliques i desplegaments i la frase sobre el patró de Cluster API són de la sol·licitud de Sandbox de la CNCF (incidència 517), oberta el 02-09-2026 i tancada el 28-10-2026. D'aquell mateix fil surten les dues condicions del TOC del 22-09, el resultat de la votació del 28-09 (72,73 % a favor, vuit vots vinculants), el canvi de nom de KubeVM a vm-api del 08-10, les intervencions dels autors de VirtRigaud/KubeSwift i de banlieue de l'11-10, la resposta del sol·licitant del 13-10 amb la seva disculpa, la resposta de la CNCF sobre el principi de «no kingmakers» i la resposta del 05-10 sobre en què es diferencia això de Cluster API. El grup d'API vm-api.io l'hem comprovat al codi del mateix repositori (api/v1alpha1/groupversion_info.go). La graduació de KubeVirt, amb la votació tancada el 04-11-2026 al 81,82 %, és a la incidència 1822 del TOC, i l'anunci públic amb les xifres de 2.088 contribuïdors i 520 organitzacions, al comunicat de la CNCF del 10-11-2026. Les dues observacions de contracte, l'abast del proveïdor per a Proxmox i la seva matriu de proves contra Proxmox VE 9.2 en arm64 i amd64 són a la incidència 2013 de vm-operator, oberta el 07-10-2026; el codi del proveïdor és klarsmith/kubevm-provider-proxmox, Apache 2.0. La pregunta sobre KubeVirt, el seu historial a la CNCF i l'ampliació cap a Cluster API són a la incidència 13 de vm-api, del 04-11-2026. L'estat «sense resposta» d'aquelles dues incidències el vam comprovar nosaltres via API de GitHub l'11-11-2026 i pot haver canviat quan llegeixis això: la de vm-operator no tenia cap comentari i la de vm-api només en tenia un, del mateix autor. La data de creació i la llicència del repositori vm-api/vm-api (30-10-2026, Apache 2.0) són del mateix origen. El calendari de versions de Kubernetes està desenvolupat i enllaçat al nostre propi post. No som resellers de VMware, de Broadcom ni de Proxmox, i no venem llicències de cap plataforma. Fotografia: «Datacenter Server Racks», de Carl Lender, CC BY 2.0 via Wikimedia Commons, original de 6.000 × 4.000, retallada per nosaltres.