Saltar al contenido
ES
Obtener NexCMP gratis

Migración · VMware

Migre máquinas virtuales de VMware a Apache CloudStack

Apache CloudStack puede importar máquinas virtuales desde VMware vCenter y, a partir de la versión 4.19, convertirlas a KVM. Hacerlo de forma segura aún requiere un inventario, una zona de destino, una prueba y un plan de transición por máquina. Durante los 30 días laborables de NexCMP Source, un ingeniero experto realiza ese trabajo con usted sin cargo adicional.

Obtener NexCMP gratisVer demo

Incluido con NexCMP Source ($499 pago único), no con NexCMP Free. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor y Apache CloudStack son marcas comerciales de sus respectivos propietarios. NexCMP es independiente y no está afiliado ni respaldado por ellos.

El problema: dejar VMware sin perder el control

Migrar a Apache CloudStack implica que cada máquina virtual cambia de plataforma: sus discos, tarjetas de red, controladores y, con frecuencia, sus direcciones. Si se hace con prisas, aquí es donde las máquinas no logran arrancar, los clientes pierden el acceso o las licencias dejan de funcionar.

CloudStack proporciona las herramientas de importación, pero no decide por usted qué máquinas van primero, cómo se mapea cada red, qué ocurre con los invitados Windows ni cuánto tiempo estará fuera de línea cada máquina. Esas decisiones, y las pruebas correspondientes, constituyen la migración.

Si vende las máquinas virtuales a clientes, la migración tiene una segunda parte: las máquinas deben quedar asociadas a los clientes, planes y precios correctos en su sistema de facturación. NexCMP es esa capa de facturación y portal de clientes sobre CloudStack, y el mismo ingeniero se encarga de ambas partes.

Lo que el propio CloudStack admite

Existen dos vías documentadas desde VMware. Cuál elegir depende de si los hosts VMware permanecen en su cloud.

  • A. Convertir a KVM con virt-v2v

    Lo que CloudStack documenta
    A partir de la versión 4.19, un administrador puede seleccionar una VM VMware en un centro de datos vCenter existente o externo e importarla a un clúster KVM, en Tools, Import-Export Instances. La VM se exporta, se convierte con virt-v2v y sus discos se importan como QCOW2. La documentación más reciente añade una vía de streaming basada en VDDK junto a la basada en OVF; la versión 4.22 añadió la conversión directa a un storage pool y la versión 4.22.1, la selección del SO invitado en función del SO invitado de origen.
    Límites indicados en la documentación
    virt-v2v no es instalado por el agente de CloudStack y debe instalarse en cada host KVM, o la conversión fallará. El éxito no está garantizado y depende del SO invitado y de los sistemas de archivos, por lo que la documentación recomienda realizar pruebas antes de su uso en producción. La VM importada recibe el tipo de SO invitado predeterminado CentOS 4.5 (32-bit) en 4.19 y debe editarse posteriormente.

    Source: Apache CloudStack — Importación de máquinas virtuales VMware a KVM · consultado el 2026-10-19

  • B. Importar in situ (unmanaged instances)

    Lo que CloudStack documenta
    Para clústeres vSphere cuyos hosts ya forman parte de CloudStack, listUnmanagedInstances lista las VM e importUnmanagedInstance las incorpora a la gestión de CloudStack. El listado de instancias VMware no administradas comenzó en la versión 4.14, la desadministración en la 4.15 y la importación en la UI en la 4.16.
    Límites indicados en la documentación
    La red de destino ya debe existir en CloudStack y el almacenamiento debe añadirse como almacenamiento primario. Los discos de datos deben asignarse a disk offerings, y los tipos mixtos de controladores de disco o tipos mixtos de NIC provocan un error. Una VM en ejecución solo puede importarse si la VLAN de red y la compute offering coinciden; de lo contrario, debe detenerse primero.

    Source: Apache CloudStack — Acerca de la importación y exportación de Instances · consultado el 2026-10-19

La ruta A se aplica cuando el destino es KVM. La propia documentación de NexCMP señala a KVM como el hipervisor probado, por lo que planificamos la ruta A a menos que su diseño mantenga los hosts VMware bajo CloudStack. Compruebe la versión de CloudStack que ejecuta: las páginas anteriores describen comportamientos diferentes entre la 4.19 y la versión más reciente.

Qué se migra y qué requiere atención

  • Discos

    Qué ocurre
    Se convierten a QCOW2 y se importan en el pool de almacenamiento primario del destino (ruta A), o se asignan a disk offerings de CloudStack (ruta B).
    Atención
    En la ruta B, no se redimensiona un disco si su disk offering es mayor. El almacenamiento temporal durante una conversión de la ruta A es almacenamiento secundario por defecto; solo puede utilizarse almacenamiento primario para ello si es NFS.

    Source: Apache CloudStack — Importación de máquinas virtuales VMware a KVM · consultado el 2026-10-19

  • Redes

    Qué ocurre
    Las redes deben existir en CloudStack antes de la importación. Un script de detección lista las redes de vCenter que tienen al menos una VM conectada, de modo que se puedan crear las redes correspondientes.
    Atención
    virt-v2v no puede reconfigurar la configuración de red de un invitado ni cambiar su dirección MAC. Si la subred de destino es diferente, el invitado necesitará cambios tras la conversión.

    Source: libguestfs — Manual de virt-v2v · consultado el 2026-10-19

  • Invitados Linux

    Qué ocurre
    Una VM Linux en ejecución puede importarse mediante la ruta A: CloudStack la clona antes de la exportación, por lo que se convierte en un estado crash-consistent.
    Atención
    La documentación de CloudStack recomienda apagar primero las VM Linux. virt-v2v no instala nuevos kernels ni controladores, y advierte si falta soporte para virtio, por lo que el huésped debe cumplir con las versiones mínimas antes de la conversión.

    Source: libguestfs — Manual de virt-v2v · consultado el 2026-10-19

  • Huéspedes Windows

    Qué ocurre
    Deben apagarse de forma ordenada antes de la importación mediante la ruta A. Los controladores virtio se obtienen del paquete virtio-win y se instalan en el primer arranque; Windows puede reiniciarse cuatro o más veces tras el primer arranque.
    Atención
    El inicio rápido o la hibernación impiden la conversión, y no se admite un disco de sistema en un disco dinámico. La importación de Windows requiere controladores virtio en el host de conversión.

    Source: libguestfs — Manual de virt-v2v · consultado el 2026-10-19

  • VMware Tools

    Qué ocurre
    virt-v2v intenta desinstalar VMware Tools.
    Atención
    El manual indica que la desinstalación no funciona de forma fiable en Windows, donde es posible que Tools deba eliminarse mediante otro método.

    Source: libguestfs — Manual de virt-v2v · consultado el 2026-10-19

  • Tipo de SO huésped

    Qué ocurre
    La VM importada recibe un tipo de SO huésped predeterminado.
    Atención
    En 4.19 es CentOS 4.5 (32-bit) y debe modificarse manualmente; la versión 4.22.1 puede mapearlo desde el SO huésped de origen si existen asignaciones.

    Source: Apache CloudStack — Importación de máquinas virtuales VMware a KVM · consultado el 2026-10-19

  • Facturación y clientes

    Qué ocurre
    Los planes, precios y cuentas de clientes se configuran en NexCMP, y cada máquina migrada se asocia al cliente correspondiente.
    Atención
    Se acuerda en la semana 1 para su versión de CloudStack. Este es un trabajo de NexCMP, no una función de CloudStack.

El plan, semana a semana

Esquema habitual, adaptado a su caso. Los 30 días laborables de trabajo continuo equivalen aproximadamente a seis semanas naturales.

  1. Semana 1 — Inventario y decisiones

    Con acceso de solo lectura a vCenter, inventariamos cada VM: SO huésped, discos, tarjetas de red, VLAN, snapshots, estado de energía y dependencias. Elegimos la ruta A o B, definimos las fases y anotamos las máquinas que requieren atención especial, como huéspedes Windows, discos de gran tamaño o sistemas con licencias fijas.

  2. Semana 2 — Preparación del destino

    Se verifica o implementa la zona de CloudStack: hosts KVM, almacenamiento y redes equivalentes a las de VMware. Instalamos virt-v2v en los hosts KVM (y nbdkit en los hosts Ubuntu), preparamos los controladores virtio para Windows y habilitamos las rutas de red entre los hosts de conversión, vCenter y ESXi. Si comercializa las máquinas, NexCMP se instala y se conecta a CloudStack durante esa misma semana.

  3. Semana 3 — Piloto

    Un grupo reducido de máquinas no críticas, una por cada tipo de huésped que tenga, pasa por el procedimiento real. Comprobamos que arranquen, tengan conectividad de red y los controladores adecuados, configuramos el tipo de SO huésped y medimos el tiempo de inactividad de cada máquina. El resultado define las ventanas de tiempo para las fases.

  4. Semanas 4 y 5 — Oleadas

    Las máquinas se migran por grupos en los horarios acordados. Se verifica cada grupo antes de iniciar el siguiente, y las máquinas originales de VMware permanecen apagadas pero conservadas para permitir un retorno si fuera necesario. Si comercializa las máquinas, los clientes, planes y precios se configuran en paralelo en NexCMP, y la facturación se ejecuta en paralelo antes de la transición definitiva.

  5. Semana 6 — Transición final y entrega

    Se migran las últimas máquinas, se ajusta la fecha de facturación si las comercializa y se aplican los cambios de DNS. Documentamos todo el procedimiento realizado, revisamos el hardening y los backups, y permanecemos disponibles para la migración hasta completar los 30 días laborables.

Solo a modo de referencia. El plan definitivo se define en la semana 1, y el único compromiso temporal de la oferta son los 30 días laborables.

Riesgos y cómo los mitigamos

Ninguna migración está exenta de riesgos y no prometemos cero tiempo de inactividad. A continuación se detalla qué puede fallar y cómo lo gestionamos.

  • Tiempo de inactividad por máquina

    Las máquinas Windows no se pueden convertir mientras están en ejecución, y una máquina Linux en ejecución se convierte en un estado crash-consistent. CloudStack no especifica cuánto tarda una conversión. Lo medimos durante la fase piloto y acordamos una ventana de parada para cada grupo de máquinas.

  • Una conversión no se completa con éxito

    CloudStack indica que el éxito no está garantizado y depende del huésped. Probamos cada tipo de huésped en la fase piloto antes de cualquier fase, y la máquina original permanece intacta hasta que se haya verificado la nueva.

  • Controladores y VMware Tools

    Las máquinas Windows reciben controladores virtio durante la conversión, las máquinas Linux requieren soporte virtio previo y es posible que VMware Tools deba eliminarse manualmente. Todo esto se verifica por cada huésped en el piloto.

  • Direcciones IP, direcciones MAC y DNS

    Los huéspedes conservan sus direcciones MAC y su propia configuración de red, por lo que una subred de destino diferente requerirá cambios dentro del huésped. Listamos cada dirección en la semana 1, reducimos los TTL de DNS antes de la transición y notificamos a sus clientes con anticipación.

  • Licencias de software del huésped

    Windows y el software comercial dentro de una máquina pueden estar licenciados para la plataforma anterior. Los incluimos en el inventario para que pueda confirmar las condiciones con cada proveedor antes de la migración.

  • Conversiones interrumpidas

    CloudStack indica que reiniciar los servidores de gestión durante una migración la interrumpe y la importación debe iniciarse nuevamente. Programamos las fases considerando el mantenimiento y evitamos reinicios mientras una fase está en curso.

  • Transición de facturación y rollback

    Si comercializa las máquinas, la fecha de migración de la facturación se acuerda con usted y ambos sistemas operan en paralelo primero. Las originales de VMware se conservan hasta que usted confirme que la migración ha finalizado, lo que brinda a cada grupo una vía de reversión.

Quién hace qué

  • Acceso de solo lectura a vCenter y una lista de las máquinas que considere críticas

    El experto realiza
    Realiza el inventario de cada VM y planifica las fases

  • Acceso al entorno de CloudStack y a los hosts KVM, o el hardware para implementarlos

    El experto realiza
    Prepara la zona, las redes y los hosts de conversión

  • Los paquetes VDDK y virtio que requiere la ruta elegida, en los casos en que los proveedores exigen que usted mismo los descargue

    El experto realiza
    Los instala y prueba en los hosts de conversión

  • Ventanas de parada acordadas y avisos a sus clientes

    El experto realiza
    Ejecuta la prueba piloto y las fases, y verifica cada máquina posteriormente

  • Sus decisiones de precios, en caso de comercializar las máquinas

    El experto realiza
    Configura planes, clientes y facturación en NexCMP y ejecuta el periodo en paralelo

Qué obtiene en los 30 días laborables

La migración forma parte de la actualización a NexCMP Source: un pago único de $499 que incluye el código fuente completo (servidor en Rust, portal y panel de administración en Vue, agente de nodo en Go, CLI, scripts de compilación), el derecho a modificar y compilar su propia versión sin límites, 12 meses de nuevas versiones del código fuente, todas las aplicaciones y 30 días laborables de trabajo continuo con un ingeniero experto.

En esos 30 días laborables, el experto realiza la migración de VMware a Apache CloudStack sin coste adicional. De forma alternativa o complementaria, este tiempo puede utilizarse para migrar desde WHMCS u otro sistema, o para una configuración completa de principio a fin y la compilación de sus aplicaciones. El cómputo comienza cuando inicia el trabajo con el experto y se muestra en su página de licencia. El soporte para la migración dura los mismos 30 días.

NexCMP Free no incluye esto. Free es gratuito durante un año con todos los módulos y sin soporte técnico, solo correcciones de errores del código fuente, y se renueva por $99 al año.

De VMware a CloudStack — preguntas frecuentes

¿Cuánto cuesta?
La migración forma parte de la actualización a NexCMP Source, un pago único de $499. El precio incluye el código fuente, 12 meses de nuevas versiones del código fuente, todas las aplicaciones y 30 días laborables de trabajo con un ingeniero experto. La oferta no tiene tarifas por hora.
¿Está incluido en NexCMP Free?
No. La migración se incluye únicamente con NexCMP Source. NexCMP Free cuenta con todos los módulos durante un año pero no incluye soporte técnico, solo correcciones de errores del código fuente, y se renueva por $99 al año.
¿Qué versiones de CloudStack y VMware son compatibles?
La documentación de CloudStack indica que la conversión de VMware a KVM está disponible a partir de la versión 4.19 y no especifica qué versiones de vSphere son compatibles; la página más reciente recomienda VDDK 8 para entornos vSphere 7 y 8. La documentación de NexCMP señala la 4.23 como su versión probada de CloudStack. Verifique la versión que utiliza; confirmaremos ambas durante la semana 1.
¿Tendrán tiempo de inactividad mis máquinas virtuales?
Sí, cada máquina estará fuera de servicio durante algún tiempo y no garantizamos un tiempo de inactividad cero. Las máquinas Windows deben apagarse de forma controlada antes de la importación. Una máquina Linux en ejecución puede importarse pero se convierte en un estado consistente frente a caídas (crash-consistent), por lo que normalmente la apagamos primero. La prueba piloto mide los tiempos y define las ventanas.
¿Se puede convertir cualquier VM?
No necesariamente. CloudStack advierte que el éxito no está garantizado y depende del SO invitado y de los sistemas de archivos. Algunos casos de Windows, como un disco de sistema en un Dynamic Disk o Fast Startup, están clasificados como bloqueos por virt-v2v. Por esa razón probamos cada tipo de sistema invitado antes de las fases.
¿Tengo que mantener VMware después?
No para las máquinas que se migraron. Mantenemos las originales apagadas hasta que usted confirme que la migración ha concluido; luego usted decide cuándo retirarlas. El licenciamiento del entorno VMware en sí corresponde a usted y su proveedor.
¿Qué debe proporcionar?
Acceso de solo lectura a vCenter, acceso al entorno de CloudStack y a sus hosts KVM, sus ventanas de parada acordadas y alguien que pueda responder preguntas sobre las máquinas. Cuando un proveedor requiera que descargue usted mismo un paquete como VDDK, usted lo proporciona.

Fuentes y notas

Las afirmaciones técnicas provienen de la documentación oficial de Apache CloudStack y del manual de virt-v2v. La documentación cambia entre versiones, así que compruebe la versión que ejecuta. La afirmación sobre la 4.19 proviene de la documentación de la 4.19, que inicia la página de VMware a KVM con «As of CS 4.19». VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor y Apache CloudStack son marcas comerciales de sus respectivos propietarios. NexCMP es independiente y no está afiliado ni respaldado por ellos.

Deje atrás VMware con un ingeniero a su lado

Actualice a NexCMP Source por $499 e inicie sus 30 días laborables, o consulte primero a [email protected] sobre su entorno.

Obtener NexCMP gratisContactar con ventasVer demo

Última actualización: