La lista de alternativas a VMware no deja de crecer, y en los últimos meses una de las que más ruido hace entre administradores es ZSvirt. Tiene a su favor dos cosas que casi ninguna otra junta: viene de un producto comercial con años de despliegues detrás y se parece mucho a vSphere en el día a día. El repositorio pasa de 2.100 estrellas y la comunidad está activa.
Revista Cloud lo contaba ayer con las cifras que da la empresa y las dudas de modelo que deja una edición libre con hermana de pago. Aquí hemos ido un paso más allá: hemos leído el repositorio, la página de descargas, la documentación de instalación y actualización y las incidencias abiertas, y hemos buscado quién es el dueño de ZStack. Lo que sigue es lo que hemos encontrado y lo que significa si te planteas ZSvirt como sustituto de VMware.
ZStack se fundó en Shanghái en 2015 y vende software de infraestructura cloud: una plataforma de nube privada (ZStack Cloud) y una de virtualización (ZSphere), con más de 5.000 clientes en más de 30 países según su propia cifra. ZSvirt es la edición libre de ZSphere.
Conviene no confundirlo con el ZStack libre que ya existía. La empresa mantiene desde 2015 el repositorio zstackio/zstack, con licencia Apache 2.0, que es el motor IaaS de su nube privada y sigue activo. ZSvirt es otra cosa: el producto de virtualización, con su interfaz, su herramienta de migración y su modelo de uso, publicado en un repositorio nuevo (ZSvirt/zsvirt, creado el 14 de agosto) y con GPL 3.0, una licencia copyleft que obliga a publicar el código de cualquier versión modificada que se distribuya.
Lo que trae, según la documentación y el anuncio del proyecto:
La empresa afirma que el motor de ZSphere se ha validado en más de 1.000 despliegues en producción (banca, sanidad, educación, industria y transporte), que su plano de control llega a gestionar más de 10.000 hosts y que una VM puede tener hasta 768 vCPU. Son cifras de ZStack, de su producto comercial, y nadie las ha verificado de forma independiente.
Las cifras del anuncio cuentan una parte. El repositorio, consultado por la API de GitHub el 10 de noviembre, cuenta la otra.
| Dato | Lo que hay |
|---|---|
| Licencia | GPL 3.0 (núcleo e interfaz web) |
| Creado | 14 de agosto de 2026, dos días después del anuncio |
| Lenguaje principal | Java |
| Commits | Unos 860 |
| Estrellas / forks | 2.112 / 361 |
| Releases en GitHub | Ninguna. Hay una única etiqueta, v5.2.0, que es la numeración interna de ZSphere |
| Versión descargable | 1.0.0, del 12 de agosto. No ha salido ninguna 1.0.1 |
| Avisos de seguridad publicados | Ninguno |
| Dónde se desarrolla | En un GitLab interno de ZStack; GitHub recibe la sincronización y los cambios de la comunidad se integran de vuelta |
| Quién escribe el código | De los 300 últimos commits, 128 los firma la cuenta de sincronización y casi todos los demás, empleados de ZStack. Muy pocos vienen de fuera |
| Arquitecturas | Solo x86_64. El proyecto ha dicho que no hay planes de imágenes aarch64 |
Nada de esto es raro en un proyecto que acaba de nacer de un producto comercial. El propio documento de gobernanza lo describe como una «fase de vista previa» con decisiones en manos de los mantenedores. Pero cambia la lectura: ZSvirt es hoy código abierto, no un proyecto comunitario. Se puede leer, auditar y compilar, que no es poco, pero la hoja de ruta la marca ZStack.
Lo que más pesa para producción es otra cosa. Desde agosto, la rama principal ha recibido cientos de cambios, entre ellos correcciones de VMs que no se dejaban borrar, de rangos IPv6 y del SDK, pero ninguno ha llegado a una versión descargable. Quien instaló la 1.0.0 en agosto sigue con la 1.0.0.
La documentación de instalación tiene un capítulo de actualización, con procedimientos para un nodo de gestión y para el par en alta disponibilidad. Está heredado de ZSphere: los ejemplos usan la base del sistema H84r, el script zstack-upgrade y un «paquete de HA» que no aparece en la página de descargas de ZSvirt.
Un usuario lo preguntó en una incidencia a finales de octubre: dónde están esos paquetes. La respuesta del equipo fue que esos términos pueden venir de la documentación antigua de ZStack y que, de momento, se puede esperar a la próxima versión de ZSvirt antes de actualizar. Es una respuesta honesta, pero significa que hoy no hay un camino documentado y probado de la 1.0.0 a la siguiente.
En un hipervisor eso no es un detalle. El ciclo de vida es lo que se compra cuando se elige una plataforma para cinco años: cuánto tiempo recibe parches cada versión, cómo se pasa a la siguiente sin reconstruir y quién avisa cuando hay una vulnerabilidad. En Proxmox VE se sabe: cada versión mayor vive al menos lo que Debian mantiene su base, unos tres años, hay notas de versión y guías de actualización entre mayores, y los avisos de seguridad se publican en el foro oficial. En ZSvirt, por ahora, no hay nada publicado sobre esto.
En el anuncio, ZStack se compromete a varias cosas: mantener la licencia GPL 3.0 sin cambios, dejar en la edición comunitaria la virtualización de cómputo, red y almacenamiento, toda la API, ZMigrate, el proveedor de Terraform y los SDK, y no mover detrás de un pago lo que ya sea abierto. También promete publicar qué pertenece a cada edición.
Esa tabla de ediciones todavía no está. Lo más parecido es la página comercial de ZSvirt Enterprise, que describe lo que se añade: una consola para gestionar varios clústeres, regiones y plataformas a la vez (incluidos clústeres VMware y KVM ajenos), organizaciones, proyectos, cuotas y aprobaciones, catálogo de servicios, medición y facturación, servidores físicos y soporte del fabricante. No hay precios publicados; se pide una demostración.
La frontera es razonable y se parece a la de otros fabricantes: la virtualización es libre y lo que se paga es la capa de nube privada y gobierno encima. Lo que hay que tener en cuenta es que los 10.000 hosts del anuncio son una cifra del producto comercial. Con la edición libre, la gestión de varios centros de datos desde una consola existe, pero la gestión multiplataforma y la parte de organizaciones y cuotas, no.
Esto es lo que casi nadie está contando. Alibaba Cloud invirtió en ZStack desde su ronda A en 2017 y repitió en 2018 y 2020. El 20 de enero de 2026 anunció que había completado una nueva inversión estratégica y se quedaba con el control de la empresa, para montar un ecosistema conjunto «Apsara + ZStack» entre su nube privada de gran tamaño y la plataforma ligera de ZStack para el edge. No se publicaron ni el porcentaje ni el precio.
El documento de gobernanza de ZSvirt lo refleja: entre sus objetivos figura «apoyar la futura publicación bajo la organización de Alibaba en GitHub». Y el modelo de gobierno descrito deja las decisiones de arquitectura, de API y del proceso de versiones en manos de los mantenedores, que hoy son ingenieros de ZStack.
No es un motivo para descartarlo. El código es GPL, cualquiera puede auditarlo y bifurcarlo, y una empresa con Alibaba detrás tiene más músculo para mantener el proyecto que muchas de las alternativas pequeñas que han salido estos dos años. Pero para una organización con requisitos de soberanía, un organismo público o una empresa sujeta a ENS o NIS2, la pregunta de quién controla al proveedor de la capa que ejecuta todas sus cargas va a salir en el comité de compras, y conviene tener la respuesta antes. Lo explicamos con más detalle en soberanía del dato y CLOUD Act: el código abierto resuelve la auditoría, no la dependencia del soporte ni de las actualizaciones.
ZSvirt publica su propia comparativa con Proxmox VE. Es útil porque reconoce que la ha escrito una de las partes, y porque acierta en varias cosas: en ZSvirt hay más operaciones desde la interfaz gráfica (importar OVF, exportar OVA, convertir plantillas en VMs y viceversa, crear VMs en lote, papelera de reciclaje, asignar IP al crear la VM) y su planificador de carga está más desarrollado.
Pero también tiene errores. Dice, en su tabla de migración, que Proxmox VE solo hace importación en frío desde ESXi, cuando el asistente nativo tiene importación en caliente desde la 8.2 (lo contamos en el procedimiento paso a paso). Y presenta el cifrado de VMs como función actual de la edición comunitaria, mientras su propia hoja de ruta del segundo semestre de 2026 apunta como trabajo pendiente «añadir cifrado de disco de máquina virtual» y «cifrado de la migración». Antes de comparar, conviene comprobar qué está en la 1.0.0 y qué es plan.
La diferencia de fondo es de arquitectura:
| ZSvirt 1.0.0 | Proxmox VE 9.2 | |
|---|---|---|
| Licencia | GPL 3.0 | AGPL 3.0 |
| Modelo de gestión | Nodo de gestión separado (dos en HA) + hosts de cómputo | Todos los nodos iguales; cualquiera sirve la interfaz web |
| Estado del clúster | Base de datos MariaDB en el nodo de gestión | Corosync + sistema de archivos de clúster replicado en todos los nodos |
| Varios clústeres | Desde el mismo nodo de gestión | Proxmox Datacenter Manager, aparte |
| Contenedores | No | LXC integrado |
| Almacenamiento definido por software | Ceph como almacenamiento externo | Ceph integrado y gestionado desde la interfaz, ZFS |
| Copias | Integradas y con terceros (Veeam, Commvault, Veritas) | Proxmox Backup Server, Veeam y otros |
| Migración desde VMware | ZMigrate (en caliente, sin agentes) | Asistente de importación de ESXi (en frío y en caliente) |
| Arquitecturas | x86_64 | x86_64 y, desde agosto de 2026, arm64 |
| Versiones publicadas | Una (1.0.0, agosto de 2026) | Desde 2008; ciclo de unos tres años por versión mayor |
| Soporte comercial | ZStack, sin precios públicos | Suscripción por socket con precios públicos; 24/7 en Premium desde octubre |
Ninguno de los dos modelos de gestión es mejor en abstracto:
Para la mayoría de las empresas que salen de VMware con entre tres y treinta hosts, esa diferencia de escala no decide nada. Lo que decide es lo otro: cuántos técnicos conocen la plataforma, cuántas guías hay, cuánto tiempo lleva en producción en entornos parecidos al tuyo y si el fabricante ha demostrado que publica parches. Ahí Proxmox lleva casi veinte años de ventaja y ZSvirt, tres meses.
ZSvirt tiene una demo en línea sin registro y se descarga en tres formatos: ISO de instalación (5,4 GB), OVA (17 GB) y QCOW2 (24 GB) para montar el nodo de gestión como VM con virtualización anidada. ZMigrate se descarga aparte (8,9 GB). Todo con suma SHA256 publicada.
Los requisitos que publica son modestos. Para una demo, 4 núcleos y 8 GB de memoria; para el nodo de gestión en producción a pequeña escala, 8 núcleos, 16 GB y 240 GB de disco. Para los hosts de cómputo remite al soporte técnico. Recomienda separar la red de gestión (1 GbE) de la de servicio (10 GbE) y añadir una de almacenamiento si se usa NFS o Ceph.
Lo que comprobaríamos en una prueba de concepto seria, más allá de crear VMs:
admin / password y las imágenes OVA y QCOW2, con root / zsvirt.123. Son públicas.Para el laboratorio conviene hacerlo sobre hierro real y no dentro de otra plataforma: la virtualización anidada sirve para ver la interfaz, pero falsea el rendimiento y oculta los problemas de red y almacenamiento que son justo los que hay que encontrar. Un par de servidores bare-metal durante unas semanas cuestan menos que descubrirlos en producción.
ZSvirt es una buena noticia para el mercado. Una segunda opción libre basada en KVM, con un modelo de gestión al estilo vCenter y una herramienta de migración seria, da a los equipos que salen de VMware algo con lo que comparar, y obliga a todos a mejorar. Su comparativa con Proxmox, con sus errores, acierta en que la interfaz de Proxmox todavía manda a la línea de comandos en tareas que en VMware se hacían con dos clics.
Pero hoy es una versión 1.0 de un proyecto con tres meses de vida pública, desarrollado dentro de una empresa que controla Alibaba Cloud, sin versiones de mantenimiento, sin avisos de seguridad y sin un camino de actualización probado. Para laboratorios, pruebas de concepto y entornos que puedan reconstruirse, merece una evaluación. Para las cargas que no pueden pararse, la pregunta no es si ZSvirt tiene las funciones, que muchas las tiene, sino si dentro de dos años seguirá recibiendo parches de la versión que instales.
Si estás en ese punto de decisión, en Proxmox VE gestionado operamos la alternativa con más recorrido, sobre infraestructura en centros de datos en España, y si quieres comparar antes de decidir te ayudamos a montar la prueba de concepto, incluida la migración desde VMware. Y si el problema es que todavía no puedes salir de VMware, también lo hemos escrito: cuándo no migrar. El mapa completo de opciones está en alternativas a VMware en 2026.
La edición comunitaria y de código abierto de ZSphere, la plataforma de virtualización comercial de ZStack. Se publicó el 12 de agosto de 2026 bajo licencia GPL 3.0 y se basa en KVM, con un nodo de gestión central al estilo de vCenter.
Sí. La licencia GPL 3.0 permite usarlo en producción sin coste de licencia. El soporte comercial y las funciones de la edición Enterprise, como la gestión multiplataforma, las cuotas o la facturación, se contratan aparte con ZStack, sin precios públicos.
Sí. ZStack (Shanghai Yunzhou Information and Technology) se fundó en Shanghái en 2015, y desde enero de 2026 Alibaba Cloud tiene una participación de control en la empresa.
En la arquitectura de gestión. ZSvirt separa un nodo de gestión, que en producción se monta por duplicado en alta disponibilidad, de los hosts de cómputo, como hace VMware con vCenter. Proxmox VE funciona como un clúster de nodos iguales sin pieza de gestión dedicada. Proxmox además integra contenedores LXC y Ceph, tiene versiones para x86_64 y arm64 y lleva casi veinte años publicando versiones.
Con ZMigrate, la herramienta de migración del proyecto, que es gratuita y no instala agentes en las VMs. Permite migración en caliente desde vCenter o ESXi, importación de OVF y subida de discos VMDK. Se descarga aparte de la ISO de ZSvirt.
A 10 de noviembre de 2026 solo existe la versión 1.0.0. La guía de actualización publicada está heredada de ZSphere y el propio equipo recomienda esperar a la próxima versión de ZSvirt antes de actualizar, así que todavía no hay un procedimiento probado entre versiones.
¿Cuánto te costaría salir de VMware?
Dinos qué tamaño tiene tu entorno y cuándo renuevas. Te respondemos con una estimación de plazos y costes y con las opciones que tienes antes de esa fecha.
Peter Xu, de Red Hat, presentó en el KVM Forum 2026 su trabajo para que QEMU aproveche la memoria por niveles con NVMe. El kernel ya sabe hacerlo; lo que falla es la migración en vivo. Repasamos las tres soluciones, las cifras de sus pruebas y qué se puede hacer hoy en Proxmox.
Conectar Proxmox VE a Active Directory lleva diez minutos y parece resuelto en cuanto entra el primer usuario. Lo difícil viene después: que la contraseña no viaje en claro, que el filtro traiga a quien debe y que una baja en el dominio sea una baja de verdad. Porque desactivar a alguien en AD no le quita sus tokens de API en Proxmox. Te contamos cómo montarlo y qué dice el código sobre lo que pasa cuando alguien se va.
Recorded Future ha documentado GhostFrame, un marco de postexplotación para ESXi ligado al ransomware Settra. No explota ningún fallo: necesita root en el host. Explicamos qué hace, cómo detectarlo con esxcli y por qué la lección vale también para Proxmox y para las copias de seguridad.