La API para declarar tus VMs ya es neutral; el proveedor que la cumple, no

El 9 de noviembre, Broadcom anunció que VM API entra en el Sandbox de la CNCF: unas CRDs de Kubernetes para declarar una máquina virtual con el mismo YAML, dé igual qué hipervisor haya debajo. Al día siguiente, en su propio blog, está la frase que lo matiza: «the specific features, performance, and operational outcomes will depend on the underlying provider executing that request». Las dos cosas están en el mismo documento y las dos son ciertas. Lo que viaja es la petición. Lo que no viaja es el resultado.

Escribimos esto desde una posición cómoda: no somos resellers de ninguna plataforma —ni de VMware, ni de Proxmox— y operamos las dos, además de Kubernetes y Docker Swarm en producción. Es decir, de este anuncio no sacamos comisión por ningún lado, y por eso podemos decir la parte que no sale en las notas de prensa: que para la mayoría de empresas que nos leen, hoy esto no cambia absolutamente nada, y que lo interesante no es el anuncio sino las costuras que ya se ven.

Lo que se anunció, con las fechas puestas

El expediente es más largo que el titular, y conviene tenerlo entero. La solicitud la abrió un ingeniero de Broadcom el 2 de septiembre de 2026. El TOC de la CNCF aprobó llevarla a votación el 22 de septiembre con dos condiciones escritas: «that the project moves kubevm out of the vmware repositories and demonstrates the pluggability of at least two providers». La votación se cerró a favor el 28 de septiembre —72,73 % de los votos vinculantes, ocho a favor, ninguno en contra—, la incidencia se cerró el 28 de octubre al crearse la de incorporación, y el anuncio público de Broadcom llegó el 9 de noviembre. Por el camino el proyecto cambió de nombre: se llamaba KubeVM y el 8 de octubre su autor explicó que la CNCF desaconseja «kube» en los nombres, así que pasó a vm-api, «similar to cluster-api». Ese detalle administrativo explica de paso por qué hay dos repositorios dando vueltas. El proyecto introduce un recurso VirtualMachine en el grupo de API vm-api.io, más primitivas encima: VirtualMachineReplicaSets y VirtualMachineDeployments, que son exactamente lo que suenan. El patrón lo dice la propia solicitud sin rodeos: «the pattern is Cluster API's core-plus-providers split, applied to VM lifecycle rather than cluster lifecycle». Núcleo genérico, proveedores enchufables, y un contrato de estado entre ambos para que el núcleo no importe código de ningún proveedor. Como decisión de arquitectura es buena y conviene decirlo antes de ponerse crítico.

Dos matices de calendario que cambian cómo hay que leer todo lo demás. El primero: Sandbox es la puerta de entrada de la CNCF, el escalón donde se aceptan proyectos jóvenes; no es un sello de madurez ni una recomendación de uso. El segundo: el repositorio público vm-api/vm-api se creó el 30 de octubre de 2026, con licencia Apache 2.0, y la API va por v1alpha1. Esa etiqueta no es decorativa: alpha en Kubernetes significa que los campos pueden cambiar o desaparecer entre versiones. El código de fondo no es nuevo —se apoya en vm-operator, con «more than six years of continuous enterprise development» dentro de vSphere—, pero el contrato portable que se discute aquí sí lo es.

Las dos frases del mismo documento

No hace falta ir a buscar a un crítico para encontrar la letra pequeña: está en el artículo que publicó Broadcom el 10 de noviembre, a unas líneas de distancia: una en el párrafo que explica la ventaja principal y otra en la tabla que viene justo después. Ponerlas una al lado de la otra ya dice casi todo del anuncio. Lo que falta está en las costuras.

No vamos a resolver cuál de las dos columnas pesa más, porque eso lo decide tu caso y no el nuestro. Si lo que te duele es que cada plataforma se pida de una forma distinta y tu equipo de producto quiere pedir una VM igual que pide un deployment, la columna de la izquierda es una mejora real. Si lo que te duele es la factura o el hipervisor de debajo, la columna de la derecha te dice que ahí no se ha movido nada: la pieza que convierte tu YAML en una máquina encendida sigue siendo un producto comercial sobre VCF. El estándar abierto es la petición; lo que la cumple en tu hierro actual es de alguien.

Dónde se raja la abstracción: tu VM portable no lleva máscara de red

Una abstracción se juzga por sus costuras, y aquí hay dos documentadas por alguien que ha ido a buscarlas con las manos. El 7 de octubre de 2026, un desarrollador externo abrió una incidencia en el repositorio de vm-operator contando que había escrito un proveedor para Proxmox VE siguiendo la guía oficial, y de paso dejó dos observaciones sobre el contrato. La segunda es la que conviene leer despacio si alguna vez has configurado una IP fija a mano.

Las direcciones de red del recurso portable, dice, «are bare IPs with no prefix length and no gateway». Y añade por qué eso basta en un sitio y no en otro: «That is enough for platforms that hand out addresses (EC2, GCE) but not for ones that configure the guest directly». Es exacto. En AWS o en Google tú pides una máquina y la plataforma le reparte la dirección; el invitado se entera por DHCP y a nadie le hace falta escribir una máscara. En un hipervisor que configura el invitado —Proxmox con cloud-init, y el propio autor sospecha que vSphere está en la misma situación con su guest customization— el parámetro ipconfigN necesita CIDR y puerta de enlace. Si el contrato portable no sabe expresarlos, esos dos datos acaban en campos específicos del proveedor. Es decir: en el sitio exacto donde vuelve a empezar el acoplamiento del que la abstracción venía a librarte.

La primera observación es más sutil y más interesante para cualquiera que opere Proxmox. «Every Proxmox state change (clone, start, shutdown, stop, resize, destroy) returns a task UPID and completes later». Los dos ejemplos de la guía son una plataforma síncrona —pides y te contesta— y una consistente por consulta, estilo EC2. Proxmox es una tercera forma: te devuelve el identificador de una tarea y el trabajo sigue ocurriendo después, con un estado «en transición» que puede durar minutos. Lo que hay que vigilar no es el objeto, es la tarea; y si vuelves a conciliar mientras una tarea está corriendo, lo correcto es adoptarla, no lanzar una segunda. Quien haya automatizado Proxmox con prisa y se haya encontrado dos clonaciones de la misma plantilla sabe exactamente de qué va esto.

Conviene ser justos con esto: son costuras tempranas y normales en algo marcado v1alpha1, y están escritas por alguien que además se ofrece a redactar la sección que falta en la guía. No son un defecto escandaloso. Son la medida exacta de cuánta portabilidad hay hoy, que es distinto de cuánta habrá.

Ya existe un proveedor para Proxmox, y lleva treinta y cinco días esperando

El proveedor de esa incidencia no es una maqueta. Según su autor, implementa el recurso VirtualMachine contra una VM QEMU clonada de una plantilla, con dimensionado, cloud-init nativo (claves SSH, nombre de equipo, DNS, IPv4 por DHCP o fija), encendido y apagado con los tres modos de la API, direcciones obtenidas del agente invitado y borrado. Y está probado en tres niveles: unitarias contra un Proxmox en memoria, envtest con núcleo y proveedor sobre un servidor de API real, y de extremo a extremo contra Proxmox VE 9.2 real, en arm64 y en amd64 bajo KVM anidado. El repositorio es público y Apache 2.0, creado el 6 de octubre.

Sus dos preguntas son de las que no se pueden contestar solo: dónde deberían vivir los proveedores de terceros, y si un proveedor de hipervisor les sirve ahora mismo para sostener el argumento de que «la API generaliza». A 11 de noviembre, el hilo no tiene ninguna respuesta pública. Treinta y cinco días. Y la pregunta no es retórica: la condición que puso el TOC para llevar el proyecto a votación fue, literalmente, demostrar «the pluggability of at least two providers». Mientras tanto, la tabla del artículo de Broadcom lista «KubeVM Service (vSphere), Proxmox, KubeVirt, etc.» en la fila de proveedores locales, con una nota al pie que avisa de que esa tabla «illustrates these potential options» y «does not represent all currently available providers». O sea: Proxmox aparece como posibilidad en el dibujo, y quien ha escrito el proveedor está esperando contestación.

Antes de sacar conclusiones, los contrapesos. La incidencia está abierta en el repositorio vm-operator y no en el nuevo vm-api, que ni siquiera existía cuando se escribió, así que puede estar sencillamente en el buzón equivocado; el proyecto ha pasado esas semanas cambiándose de nombre y de casa; y el silencio en GitHub no es una negativa, porque hay conversaciones que ocurren en listas, en Slack o en una llamada. Tampoco es el único tercero que se ha dirigido al proyecto, ni el primero: eso viene ahora. Lo que decimos es que a día de hoy ese hilo concreto sigue abierto y sin contestar, y que es un dato que cualquiera puede ir a comprobar.

La parte del expediente que no salió en ninguna nota de prensa

El 11 de octubre, dos semanas después de la votación, dos autores de proyectos de virtualización entraron en la solicitud a decir que no estaban de acuerdo con cómo se les había descrito. El primero, autor de KubeSwift y VirtRigaud: «VirtRigaud is currently used in production, it does support extended lifecycle management of VSphere, LibVirt and Proxmox Hypervisors and VM Migration across hypervisors». Es decir, un proyecto de terceros que ya lleva Proxmox en producción y que además mueve máquinas entre hipervisores. Su queja de fondo: la solicitud describía esos trabajos como intentos «with limited adoption» frente a una implementación «production-proven ... from the outset», cuando el código del solicitante vivía entonces en una rama de otro repositorio.

El segundo, autor de banlieue y amigo declarado del anterior —lo dice él, no nosotros—, puso por escrito la objeción que más pesa aquí, porque es la misma que sostiene este post desde la entradilla: «My main concern is that the case for vendor neutrality rests on things that don't exist yet». Y la apoyaba en la propia solicitud: el controlador genérico era entonces «the first milestone on the roadmap and is not yet written», y el único proveedor en producción era VM Operator, que es a la vez el plano de control del producto comercial de Broadcom. Un mes después, ese controlador ya existe y tiene repositorio propio. La objeción no era profética; era una fecha.

Hubo respuestas, y hay que contarlas igual de alto. El solicitante contestó el 13 de octubre, se disculpó por la tardanza —«I apologize for not getting to the comments earlier»— y explicó de dónde venía la confusión. Días antes, el 5 de octubre, ya había respondido en público a quien preguntaba en qué se diferencia esto de Cluster API. Y la CNCF recordó que el solapamiento entre proyectos no es motivo de rechazo, en línea con su principio de «no kingmakers», y que la solicitud ya se había revisado por sus méritos. Así que la foto no es «nadie contesta a nadie»: se contestó a las objeciones de fondo y a la comparación con Cluster API. Lo que sigue sin contestar, en su hilo, es la oferta de un segundo proveedor, que resulta ser una de las dos condiciones que puso el TOC. Para quien compra infraestructura esto no es cotilleo de repositorio: es la manera más barata que hay de distinguir la neutralidad que se afirma en una diapositiva de la que aguanta cuando entran terceros a discutirla por escrito.

La otra pregunta sin contestar: ¿y KubeVirt?

El 4 de noviembre, con la votación del TOC cerrada a favor desde septiembre, alguien abrió en el repositorio de VM API una pregunta incómoda y bien hecha. El argumento es sólido, y el calendario lo ha reforzado solo. KubeVirt ya es una API de VMs nativa de Kubernetes: entró en el Sandbox en septiembre de 2019, pasó a incubación en abril de 2022 y su votación de graduación se aprobó ese mismo 4 de noviembre con un 81,82 % a favor, tres minutos antes de que se abriera la pregunta. La CNCF lo anunció en público el 10 de noviembre, en el KubeCon de Salt Lake City, con 2.088 contribuidores de 520 organizaciones a la espalda. Dicho de otra manera: la semana en que VM API entró por el escalón de abajo, el proyecto con el que se le compara salía por el de arriba. Y ya no está atado a QEMU/KVM: hay trabajo explícito para desacoplar el núcleo de la lógica específica de KVM, y una integración con Hyper-V como prueba de que puede soportar más hipervisores. La pregunta, entonces, es directa: ¿por qué hace falta una capa genérica más, al lado o por encima de la que ya existe? Y la ironía que la hace más afilada: el propio plan de ruta de VM API lista a KubeVirt como uno de sus futuros proveedores.

Dieciséis minutos después, el mismo autor declaró su conflicto de interés —«I am actively involved in KubeVirt»— y amplió la pregunta hacia Cluster API, que es de donde viene el patrón: si el diseño calca el contrato de Machine, ¿qué pasa con la propiedad del ciclo de vida cuando una VM es a la vez nodo de un clúster? Una semana más tarde, ese hilo sigue sin respuesta del proyecto. La pregunta general —en qué se diferencia esto de Cluster API— sí se contestó, y en público, como acabamos de ver; lo que sigue abierto es esta variante concreta sobre quién es el dueño del ciclo de vida. Aquí tampoco tomamos partido: la pregunta la hace una parte interesada, y es perfectamente posible que la respuesta sea buena y esté sin escribir. Pero dos APIs compitiendo por ser el sitio donde se declara una máquina virtual es, exactamente, el problema que un estándar venía a resolver.

Qué cambia esto si tienes cuarenta máquinas virtuales (hoy, nada)

Esta es la parte que no interesa contar a nadie que venda algo. Si tu empresa tiene un clúster de virtualización con unas decenas de VMs, un par de personas que lo mantienen y Kubernetes en ningún sitio, meter tus VMs detrás de un plano de control de Kubernetes no te arregla ningún problema que tengas hoy. Te añade un segundo plano de control sobre el mismo hipervisor: otra cosa que actualizar, otra cosa que vigilar, y un dominio de fallo nuevo encima de uno que ya existía. La pregunta de resiliencia que hay que hacerse antes que ninguna otra es qué pasa cuando ese clúster se cae, y si tus máquinas siguen arrancando sin él.

Y hay un coste recurrente que casi nadie suma cuando decide esto en una pizarra: el calendario. Kubernetes publica una versión nueva cada cuatro meses, el soporte de cada una dura catorce, y las actualizaciones no se saltan versiones; lo contamos con las fechas en Kubernetes caduca cada catorce meses y no se saltan versiones. Ese es el precio real de tener un plano de control, y se paga tengas cuarenta VMs o cuatrocientas. Si la decisión de fondo que tienes encima de la mesa es qué orquestador necesitas de verdad, el criterio está escrito sin dogma en Docker Swarm no está muerto: lo que de verdad estás eligiendo.

Cuándo sí tiene sentido mirarlo, entonces. Vale la pena mirar esto con atención si ya operas Kubernetes en producción y tienes a alguien que lo mantiene; si tu equipo de producto pide infraestructura por YAML y GitOps y las VMs son la excepción que se pide por correo; o si llevas contenedores y máquinas virtuales con dos flujos distintos y eso te cuesta horas todas las semanas. En ese escenario, declarar las dos cosas igual es una mejora de verdad.

Las cinco preguntas antes de que esto entre en un contrato

Cuando alguien te enseñe una diapositiva con una API neutral en el centro y varios hipervisores colgando, estas cinco preguntas sirven para separar lo que está estandarizado de lo que está dibujado. Valen para VM API y valen para cualquier capa de abstracción que te vendan después.

Lo que hacemos nosotros con un anuncio así

Lo leemos, lo anotamos y seguimos. Operamos Proxmox VE con Ceph en producción, llevamos VMware desde versiones antiguas y desplegamos tanto Kubernetes como Docker Swarm, incluido Kubernetes gestionado: somos agnósticos de orquestador porque no cobramos por ninguno. Cuando una capa como esta madure y un proveedor serio la cumpla sobre la plataforma que ya tienes, será el momento de contarlo otra vez con números. Hoy lo honesto es decir que está en v1alpha1, que la votación que lo metió en el Sandbox se cerró en septiembre con dos condiciones y una de ellas sigue abierta, y que la pieza que la cumple sobre VCF es comercial.

Si tienes esta decisión encima de la mesa —o la de más abajo, que es qué hipervisor quieres para los próximos cinco años—, es exactamente el trabajo de nuestra consultoría IT: ponerle números a las dos opciones sin cobrar comisión de ninguna. La capa de debajo la montamos nosotros, en infraestructura y cloud, y si lo que estás mirando es salir de VMware, el camino por capas con vuelta atrás está en migración de VMware a Proxmox.

Fuentes (consultadas el 11-11-2026): el anuncio de la contribución y la fecha de aceptación en el Sandbox son de la nota de prensa de Broadcom del 09-11-2026. Las citas sobre intención portable, resultados que dependen del proveedor, KubeVM Service como proveedor comercial sobre VCF, la tabla de proveedores con Proxmox y la nota «It does not represent all currently available providers» salen del artículo How VM API and KubeVM Service Deliver Open Standards and Enterprise Execution, publicado el 10-11-2026 en el blog de VMware Cloud Foundation. La descripción del recurso VirtualMachine, el grupo de API inicial —que entonces era kube-vm.io, antes del cambio de nombre—, las primitivas de réplicas y despliegues y la frase sobre el patrón de Cluster API son de la solicitud de Sandbox de la CNCF (incidencia 517), abierta el 02-09-2026 y cerrada el 28-10-2026. De ese mismo hilo salen las dos condiciones del TOC del 22-09, el resultado de la votación del 28-09 (72,73 % a favor, ocho votos vinculantes), el cambio de nombre de KubeVM a vm-api del 08-10, las intervenciones de los autores de VirtRigaud/KubeSwift y de banlieue del 11-10, la respuesta del solicitante del 13-10 con su disculpa, la respuesta de la CNCF sobre el principio de «no kingmakers» y la respuesta del 05-10 sobre en qué se diferencia esto de Cluster API. El grupo de API vm-api.io lo hemos comprobado en el código del propio repositorio (api/v1alpha1/groupversion_info.go). La graduación de KubeVirt, con la votación cerrada el 04-11-2026 al 81,82 %, está en la incidencia 1822 del TOC, y el anuncio público con las cifras de 2.088 contribuidores y 520 organizaciones, en el comunicado de la CNCF del 10-11-2026. Las dos observaciones de contrato, el alcance del proveedor para Proxmox y su matriz de pruebas contra Proxmox VE 9.2 en arm64 y amd64 están en la incidencia 2013 de vm-operator, abierta el 07-10-2026; el código del proveedor es klarsmith/kubevm-provider-proxmox, Apache 2.0. La pregunta sobre KubeVirt, su historial en la CNCF y la ampliación hacia Cluster API están en la incidencia 13 de vm-api, del 04-11-2026. El estado «sin respuesta» de esas dos incidencias lo comprobamos nosotros vía API de GitHub el 11-11-2026 y puede haber cambiado cuando leas esto: la de vm-operator no tenía ningún comentario y la de vm-api solo tenía uno, del propio autor. La fecha de creación y la licencia del repositorio vm-api/vm-api (30-10-2026, Apache 2.0) son del mismo origen. El calendario de versiones de Kubernetes está desarrollado y enlazado en nuestro propio post. No somos resellers de VMware, de Broadcom ni de Proxmox, y no vendemos licencias de ninguna plataforma. Fotografía: «Datacenter Server Racks», de Carl Lender, CC BY 2.0 vía Wikimedia Commons, original de 6.000 × 4.000, recortada por nosotros.