Cómo Salir de VMware sin Sacrificar el Nivel de Servicio Actual e Iniciar una Relación con un Nuevo Socio Tecnológico
Introducción
Es una preocupación conocida en el mercado: la adquisición de VMware por parte de Broadcom generó un impacto significativo en el costo de mantener el ambiente actual de la empresa. Los cambios de políticas impactaron directamente en el TCO de los ambientes productivos.
Para la Pyme, sostener esa relación resulta casi imposible, y muchas empresas mantienen hoy sus licencias perpetuas sin soporte — algo de lo que, en algún momento, va a ser necesario salir. Las alternativas más escuchadas para estos casos son Proxmox y, por qué no, Hyper-V, que al fin del día puede que sea la más adecuada para este perfil de cliente.
Ahora, si estamos en un ambiente Enterprise, probablemente el camino seguro sigue siendo renovar VMware con las nuevas políticas. El panorama es agresivo: Broadcom tiende a ofrecer un producto High-End con todo lo que VMware puede hacer, lo necesites o no (ejemplo, Tanzu es parte de la licencia, aunque no haya necesidad de Kubernetes). También exige una cantidad mínima de 72 cores de licencia para empezar, y empuja a comprometerse a plazos de tres años para acceder a un precio razonable — corrompiendo, por así decirlo, la característica “on-demand” de los esquemas de nube. Es así, si querés ese nivel de servicio… hasta ahora.
La novedad: Nutanix abrió el juego junto con Dell, y ahora Acropolis (AHV) puede correr sobre PowerStore. (ver anuncio)
¿Por qué es necesario plantear un cambio, más allá del precio de la solución?
No toda adquisición de una empresa de tecnología busca lo mismo. Cuando EMC compró VMware en 2004 por unos 625 millones de dólares, la dejó operar de forma autónoma y siguió invirtiendo en su crecimiento — tres años y medio después, VMware salía a bolsa valuada en 19.100 millones de dólares, con EMC quedándose con la mayoría del capital. Fue una apuesta de crecimiento: el comprador ganaba haciendo crecer el valor del producto.
Existe otro patrón, documentado en varias adquisiciones de software maduro y líder de su mercado: comprar un producto con una base de clientes cautiva — clientes para quienes cambiar de plataforma es costoso y lento — y usar esa cautividad para elevar el ingreso inmediato, en vez de invertir en mejorar el producto. Es lo que se conoce como explotar a un “cliente cautivo”. El mercado tarda en reaccionar precisamente porque el costo de cambiar de plataforma es alto — y esa demora es parte del cálculo, no un efecto colateral.
Es una práctica conocida, no una sospecha: se documentó en la compra de CA Technologies (2018) y de la división enterprise de Symantec (2019) por parte de Broadcom, y buena parte del mercado viene señalando el mismo patrón en la compra de VMware por la misma empresa. No hace falta compartir esa lectura para entender el punto de fondo: cuando el dueño de una plataforma deja de necesitar ganarse al cliente, el cliente pierde la única garantía real que tenía — que a alguien más le convenga que la plataforma siga mejorando.
Tres soluciones, cada una resolviendo su propio frente tecnológico, que ahora se suman
Nutanix virtualiza y opera la infraestructura. PowerStore asegura el dato operativo. Veeam gestiona la continuidad de los datos.
Nutanix AHV, Dell PowerStore y Veeam son, cada uno por separado, productos maduros y probados en ambientes enterprise. Lo que cambió hace apenas unas semanas es que ahora pueden pensarse como un mismo stack: Nutanix sumó soporte de storage externo para AHV, y Dell fue el primero en integrar PowerStore sobre esa base.
Vale la pena explorar esta combinación — pero con honestidad: es una novedad de julio de 2026, y no toda la integración fina entre las tres partes está todavía documentada o probada en conjunto. Lo que sigue es la arquitectura y el razonamiento; más abajo señalamos puntualmente qué está confirmado y qué falta validar.
El escenario típico
Muchas organizaciones hoy sostienen su continuidad de negocio con una combinación conocida: VMware vSphere como hipervisor, un storage externo de gama alta, VMware Site Recovery Manager (SRM) para orquestar la recuperación entre sitios, y Veeam Backup & Replication para el resguardo diario. Funciona, pero tiene un costo creciente — de licenciamiento, de complejidad operativa, y de dependencia de una única pila de virtualización.
La pregunta que empieza a aparecer en las mesas de IT es directa: ¿se puede cambiar de hipervisor sin resignar el mismo nivel de protección y orquestación que hoy da un storage externo de gama alta?
La novedad: AHV ya puede correr sobre storage externo
Hasta hace muy poco, Nutanix AHV solo trabajaba con el storage distribuido propio de Nutanix (Nutanix Cloud Infrastructure). Eso cambió: con Nutanix Cloud Infrastructure (NCI) 7.6, Nutanix sumó soporte oficial de storage externo para AHV. Dell fue el primer socio en integrar esta capacidad, primero con PowerFlex (abril 2026, incluyendo replicación síncrona) y ahora también con Dell PowerStore, validado con ciclo de vida completo (Day 0 a Day 2), upgrades no disruptivos y escalado independiente de cómputo y storage.
En la práctica: los discos virtuales de las VMs en AHV se mapean a volúmenes en el PowerStore vía NVMe/TCP, con el servicio Stargate de Nutanix mediando el I/O. La gestión de snapshots, políticas de protección y replicación se hace desde Prism Central, con tres modalidades: Metro (RPO cero con failover automático), síncrona (RPO cero) y asincrónica (por intervalos programados) — las mismas opciones que Nutanix ya ofrece con su storage propio.
Esto abre una puerta concreta: el hipervisor y el storage dejan de estar atados entre sí. Se puede migrar de vSphere a AHV sumando PowerStore como storage externo — partiendo de un PowerStore que ya está en producción, o incorporándolo como parte del cambio.
Los tres pilares de la solución
Nutanix AHV aporta el hipervisor — más simple de operar y licenciar que vSphere, con Prism como plano único de gestión de cómputo, red (Flow) y ahora también del storage externo.
Dell PowerStore sigue siendo el storage: arreglo unificado NVMe all-flash (los modelos QLC como el 5200Q escalan hasta 25PB efectivos por clúster), con deduplicación y compresión en línea con una garantía de reducción de datos de 6:1, y snapshots inmutables por diseño. Desde PowerStore 3.5 existen además “secure snapshots”, que no pueden borrarse manualmente — ni por un administrador, ni por un atacante con credenciales comprometidas — hasta que vence su plazo de retención.
Veeam cubre el resguardo y la orquestación de la recuperación:
- Backup nativo y sin agentes de las VMs en AHV, mediante el Veeam Plug-in for Nutanix AHV, con soporte de snapshots consistentes a nivel de aplicación y restore granular de archivos individuales sin necesidad de levantar la VM completa.
- Veeam Recovery Orchestrator (evolución de Veeam Availability Orchestrator) como el equivalente funcional de SRM: planes de recuperación documentados, testing no disruptivo y automatización del failover/failback, sin atarse a la pila de VMware.
Ransomware: cambia el dominio de riesgo
Ningún ataque conocido logró cifrar el contenido de un vDisk cuando vive como volumen propio en el storage externo, aislado del datastore compartido que hoy es el blanco típico de campañas como ESXiArgs o DarkBit — casos documentados de cifrado masivo de archivos .vmdk sobre VMFS. Podrían eliminarlo, pero eliminar no es rescatable: no hay nada que negociar cuando no queda una clave que vender.
No existe la protección absoluta — ninguna disciplina de seguridad la promete, porque siempre aparece quien encuentra la vuelta. Lo que sí cambia acá es el dominio de riesgo (cuánto se puede tocar desde un solo compromiso) y la oportunidad de simplificar el aislamiento (un volumen por VM, no un datastore compartido), sumado a herramientas de recuperación veloces: snapshots deduplicados, retenidos semanas, invisibles para quien ya rompió el ambiente virtual.
En una empresa grande, bien entendido esto, un buen Socio Tecnológico, aunque caro, se paga con gusto: cualquier solución que resulta más barata que el problema justifica por sí sola su inversión. Después será elegir la más adecuada — o la más barata — para cada realidad.
Snapshots deduplicados como mecánica anti-ransomware
Un storage con deduplicación real, como PowerStore, cambia la ecuación de cuántas copias de recuperación conviene mantener. Como cada snapshot solo ocupa espacio por los bloques que cambiaron, sostener versiones diarias (o más frecuentes) durante semanas deja de ser una decisión cara. Combinado con la inmutabilidad de los “secure snapshots”, esto da una capa de recuperación ante ransomware que no depende de restaurar desde backup: se vuelve a un punto anterior directamente desde el storage, en minutos, con una copia que el atacante no pudo tocar ni borrar.
Un capacidad poco usada en Argentina, y muy poderosa: explorar dentro del snapshot
Veeam tiene una función nativa — Veeam Explorer for Storage Snapshots — que permite conectarse directo al storage y navegar qué hay adentro de un snapshot del arreglo, sin que ese snapshot tenga que ser un backup de Veeam. Se puede entrar a una VM que vive dentro de ese snapshot y sacar un archivo puntual, sin restaurar la máquina entera. Es una herramienta que casi no se usa en el mercado local, y que en ambientes enterprise es de gran valor para recuperaciones rápidas y quirúrgicas.
Hoy esta capacidad está documentada y probada sobre datastores de VMware vSphere integrados vía la Universal Storage API (la misma que usa el plug-in de Dell PowerStore). Para AHV encontramos una señal que apunta en contra: la documentación técnica del plug-in de Veeam para Nutanix AHV describe un mecanismo de “workers” que acceden a los discos de VM por iSCSI, usando el snapshot nativo de Nutanix — no la Universal Storage API. No es una confirmación oficial de Veeam, pero es una fuente técnica detallada y consistente, así que es probable que hoy esta función específica no esté disponible sobre AHV+PowerStore. Terreno muy nuevo — vale la pena confirmarlo con Veeam antes de prometerlo.
Lo que está confirmado y lo que falta validar
Confirmado hoy:
- AHV soporta PowerStore como storage externo (NCI 7.6), gestionado desde Prism, con replicación Metro/síncrona/asincrónica.
- Veeam hace backup nativo y sin agentes de VMs en AHV, con restore de archivos individuales.
- Veeam Recovery Orchestrator orquesta planes de recuperación de forma independiente de VMware.
- PowerStore ofrece snapshots inmutables, “secure snapshots” y deduplicación de alto nivel.
Por confirmar con Dell/Veeam antes de comprometerlo con un cliente:
- Si el backup de Veeam para AHV puede hacer offload/restore directo contra snapshots del propio PowerStore. Hay indicios de que hoy no es así: la documentación técnica del plug-in describe un mecanismo de “workers” que acceden a los discos por iSCSI usando el snapshot nativo de Nutanix, no la Universal Storage API que sí usa para vSphere+PowerStore. No es una confirmación oficial de Veeam, pero es una señal fuerte.
- Si Veeam Explorer for Storage Snapshots puede navegar snapshots de PowerStore cuando el hipervisor es AHV — misma incertidumbre que el punto anterior.
Bases de datos empresariales: Oracle y SAP HANA
Dos cargas típicas de un ambiente Enterprise merecen mención aparte, porque no se comportan igual frente a esta migración.
Oracle Database sigue siendo un dolor conocido del mercado, y migrar a AHV no lo resuelve. La política de particionamiento de Oracle nombra explícitamente a Nutanix AHV — junto con VMware vSphere y Hyper-V — como “soft partitioning”: no califica como hard partitioning, sin importar pinning, affinity rules o aislamiento de sub-clúster. En la práctica, Oracle pretende licenciar todos los núcleos físicos del clúster, exactamente el mismo problema que hoy tiene con vSphere. La única salida real sigue siendo Oracle Linux KVM (la distribución propia de Oracle, con hard partitioning reconocido oficialmente) — y ahí aparece una arquitectura interesante: una granja chica y aislada de Oracle Linux KVM, conectada al mismo PowerStore por iSCSI o Fibre Channel, mientras el resto del ambiente corre en AHV. Un solo storage, dos islas de cómputo, cada una resolviendo su propio problema de licenciamiento.
SAP HANA es un caso distinto: su restricción histórica fue siempre de certificación, no de licenciamiento, y esa certificación ya existe. El programa HANA-HyCI (HANA sobre infraestructura hiperconvergente) certifica formalmente combinaciones como Dell XC Family con Nutanix AOS y AHV como hipervisor — certificación vigente hasta octubre de 2028. El cliente SAP que hoy tiene HANA soportado sobre VMware ya invirtió en hardware certificado; migrar esa certificación a AHV no es un salto conceptual, es un camino real.
Por qué esto importa más allá de lo técnico
Esta integración no es exclusiva de Dell: Nutanix ya la resuelve también con Pure Storage FlashArray, y no sería raro que con el tiempo sumen NetApp, Nimble o cualquier fabricante de storage que tenga las capacidades de control a nivel de bloque — Change Block Tracking, snapshots nativos — que este modelo necesita. Es un camino parecido al que recorrió VMware con vVols: NetApp fue uno de los socios de referencia en el lanzamiento de 2015, y el resto del mercado de storage se fue sumando con los años hasta volverse compatible con casi cualquier fabricante serio.
Cuando VMware era un verdadero Socio Tecnológico, no nos importaba la dependencia implícita que traía cada API propia — VASA, VAAI, VADP, VAIO, PSA, y tantas otras que VMware fue creando porque, siendo líder, era quien primero se topaba con cada problema nuevo del mercado. Todo ese ecosistema estaba cómodo porque VMware acompañaba con una solución a medida para cada tipo de cliente.
Nutanix podría convertirse, con el tiempo, en un nuevo punto de dependencia. Pero no es la misma: AHV está construido sobre KVM, el mismo núcleo abierto que usan Proxmox, Red Hat/oVirt y OpenShift Virtualization, entre otros. Si algún día Nutanix deja de comportarse como un socio, la distancia hacia la próxima migración es mucho más corta que la que separaba a VMware de cualquier alternativa — no es empezar de cero, es cambiar de wrapper sobre la misma base.
La integración con storage externo por NVMe es hoy un diferencial real, y como todo diferencial, se paga. Pero ser el primero no lo vuelve permanente: la misma apertura que le permitió a Nutanix construir esta integración le va a permitir a otros jugadores llegar al mismo lugar con el tiempo.
Del lado del cómputo, esa apertura ya existe hace más de diez años: Nutanix corre igual sobre hardware Dell, Lenovo, HPE, Cisco o Fujitsu, además de su propia marca NX. Si el storage termina de sumarse a esa misma lógica, el resultado es una capa de software verdaderamente agnóstica de punta a punta: elegís el fierro que mejor te convenga, no te elige el fabricante.
Vale una aclaración para no caer en la misma trampa que venimos señalando en otros fabricantes: el hardware certificado que exige Nutanix no es lock-in en el mismo sentido. Es un compromiso de nivel de servicio — el ciclo de vida (LCM) de Nutanix necesita conocer el hardware para automatizar actualizaciones y sostener continuidad sin sorpresas. Se paga por eso, pero se paga por algo real: menos problemas operativos, no menos libertad de elegir el próximo paso.
Y esa libertad de elegir el próximo paso es, en el fondo, el motivo de fondo de esta Solución. Vengo viendo de cerca lo que pasa cuando una relación comercial deja de tratarse como una sociedad de largo plazo y empieza a administrarse como un activo financiero para exprimir: licencias perpetuas que se quedaron sin soporte, socios locales que dejaron de ser necesarios para vender, inversión en desarrollo que se redirige a donde mira el mercado de capitales hoy, no a donde el cliente lo necesita mañana. Más allá de que VMware todavía sea la mejor solución Enterprise de Virtualización, el mercado debería mirar una alternativa — y no necesariamente por costo, sino por mantener una relación de Socio Tecnológico en el tiempo.
Para quién es esta solución
Para organizaciones que hoy sostienen vSphere + storage externo + SRM + Veeam, y que están evaluando reducir su dependencia de VMware sin resignar el nivel de orquestación de DR que tienen hoy.
Transformación: el camino hacia contenedores, a futuro
Todo lo anterior describe lo que veníamos llamando Virtualización, y que hoy casi todo el mercado prefiere llamar “Private Cloud” — el nombre confunde un poco cuando la infraestructura es on-premise, pero es el término que se instaló. Esta arquitectura resuelve bien ese mundo tradicional. La transformación real, la que cambia cómo se construyen las aplicaciones, es otra: contenedores, CNCF, DevOps, Kubernetes. No es parte de esta Solución hoy, pero vale la pena dejar mapeado el terreno, porque todo esto puede sumarse con el tiempo sobre la misma base de AHV + PowerStore.
En VMware, la apuesta para eso se llama Tanzu — que sigue existiendo como Tanzu Platform tras la reorganización de Broadcom, aunque la pieza de Kubernetes-sobre-vSphere se rebautizó como vSphere Kubernetes Service (VKS). Nutanix, por su parte, tiene una oferta propia menos conocida en nuestro mercado: Nutanix Kubernetes Platform (NKP), heredera de la adquisición de D2iQ combinada con Nutanix Kubernetes Engine, pensada como alternativa completa a Red Hat/Rancher. No es tan de nombre instalado localmente como Tanzu u OpenShift, pero existe y compite en la misma categoría.
Más allá de la opción propia de Nutanix, sobre AHV se pueden correr casi todas las distribuciones relevantes de Kubernetes: Red Hat OpenShift tiene guía de despliegue oficial sobre AHV (Nutanix es hypervisor certificado por Red Hat), y SUSE Rancher y Canonical Charmed Kubernetes también son viables, con el mismo principio general de cualquier distribución de Kubernetes sobre cualquier hipervisor: mientras las cargas sean stateless, la instalación es prácticamente directa.
Donde empieza a requerir diseño es con datos persistentes (stateful). Ahí entra el Container Storage Interface (CSI): Nutanix tiene su propio driver CSI para exponer Volumes/Files como storage persistente a Kubernetes. Por encima de un CSI puede correr Kasten — hoy parte de Veeam, rebautizado Veeam Kasten for Kubernetes — que hace backup y mobility nativos de aplicaciones Kubernetes, y que soporta explícitamente el CSI de Nutanix, Portworx y el CSI de Dell PowerStore. Es una segunda forma en la que Veeam entra en esta arquitectura, esta vez del lado de los contenedores en vez del lado de las VMs.
Esta parte la conocemos hoy solo de laboratorio, no de producción: probamos Nutanix CSI + Kasten sobre AHV, y por separado Proxmox + Kubernetes vanilla + Portworx, en instalaciones chicas y no productivas. Sirve para saber que funciona y cómo encaja cada pieza, pero se presenta acá como funcionalidad a explorar y sumar en el tiempo, no como parte ya entregable de la Solución.
Marcelo Soria: https://www.linkedin.com/in/marcelo-soria-475aab1