De vSphere a Proxmox: qué se mueve de verdad

Toda guía de migración para dejar VMware empieza por el disco, porque el disco es la parte que tiene un fichero. Convertir el VMDK, importarlo, arrancarlo, listo.

El disco es la parte fácil. Lo que hace funcionar a una máquina de vSphere está en otros cuatro sitios, ninguno de ellos dentro del VMDK: cómo identifica la plataforma a la máquina, cómo se configura el huésped en el primer arranque, para qué hardware virtual tiene controladores el huésped, y qué agente dentro del huésped responde a las preguntas sobre él. Cada uno es un problema distinto en Proxmox, y solo uno de ellos se anuncia cuando sale mal.

Esto es lo que encontramos al construir caminos de lectura y de escritura contra los dos, medido contra vCenter 6.7.0 build-24323669.

El disco, y la llamada que no está

Hay dos formas de disco virtual en juego. Una VM de vSphere en marcha tiene un VMDK plano más un pequeño descriptor. Un OVA o una imagen de nube descargada tiene un VMDK stream-optimized: comprimido, secuencial y no arrancable tal cual.

El camino de conversión evidente es CopyVirtualDisk_Task con una especificación de destino que nombra el formato de llegada. Esa llamada existe en un host ESXi independiente y no existe en vCenter: responde «The requested operation is not implemented by the server». Es un buen ejemplo de una trampa más amplia de esta API, en la que la misma operación existe a un nivel de gestión y no a otro.

Dos cosas sí funcionan, y conviene conocerlas en este orden:

• CopyVirtualDisk_Task sin especificación de destino funciona en vCenter 6.7 y copia un disco conservando su tipo. En este vCenter exige el argumento datacenter; la forma que solo lleva una ruta de almacén de datos se rechaza.
• El camino de importación OVF (CreateImportSpec → ImportVApp → HttpNfcLease → HTTP POST → HttpNfcLeaseComplete) acepta un disco stream-optimized y convierte por el camino. Solo necesita el descriptor .ovf, no el OVA entero: un OVA es un archivo tar con el descriptor al principio, recuperable con una única petición de rango de 128 kB.

Del lado de Proxmox el equivalente es qm disk import, que toma un VMDK y lo escribe en el almacenamiento de destino con el formato propio de ese almacenamiento. Esa parte sí es genuinamente sencilla.

El aprovisionamiento se modela de forma distinta en cada lado. vSphere tiene dos banderas, thinProvisioned y eagerlyScrub, y no son una elección entre tres: lo fino excluye la puesta a cero inmediata, así que los estados válidos son fino, grueso con puesta a cero diferida y grueso con puesta a cero inmediata. Cualquier cosa que modele esto como un solo enum de cuatro valores acabará enviando una combinación imposible.

Identidad: el identificador que se tiene no lo es

Esta muerde meses después, no el día de la migración.

Un objeto de vSphere se direcciona con una referencia a objeto gestionado, algo como vm-101. Parece un identificador y no lo es: es una clave en la base de datos de ese vCenter concreto. Si esa base de datos se reconstruye o se restaura, la referencia no sigue a la máquina, y se vuelve a repartir a una VM distinta. Lo que se guardó hace seis meses apunta ahora a la máquina de otra persona, y la operación que se iba a ejecutar es un apagado.

El identificador duradero es config.instanceUuid. Guardar ese, y resolver la referencia en cada operación mediante FindByUuid.

Proxmox tiene la forma opuesta. Una VM es un vmid: estable, legible por una persona, visible en cada comando, único por clúster. Es más agradable de manejar, y tiene su propia consecuencia para una migración. Se están eligiendo identidades nuevas, así que todo sistema externo que se refiriera a una máquina por su identificador de vSphere hay que reapuntarlo.

El modelo de ubicación también difiere. Con DRS activado, el host en el que corre una VM cambia sin que nadie lo pida, así que a un clon se le da un grupo de recursos y vSphere elige. En Proxmox el nodo es la unidad y moverse entre nodos es explícito. Un inventario que registraba «en qué host» para un clúster con DRS estaba registrando algo que cambia solo.

Personalizar el huésped es otro mecanismo, no otra sintaxis

Las dos plataformas pueden configurar un huésped en el primer arranque. Lo hacen de maneras que no comparten una línea de código.

En vSphere, la ruta que funciona sin depender del huésped es guestinfo: cuatro claves en extraConfig, leídas por la fuente de datos VMware de cloud-init.

Las claves .encoding no son opcionales. Si se omiten, cloud-init lee el texto base64 como si fuera el contenido en sí, y la máquina arranca con un nombre de host de cuarenta caracteres sin sentido. Ningún error, solo una respuesta equivocada.

La alternativa, el propio CustomizeVM_Task de VMware, necesita VMware Tools en el huésped y, en plantillas de Linux antiguas, un perl que funcione, que es el tipo de requisito que se descubre cuando un aprovisionamiento se queda colgado a mitad.

En Proxmox, la personalización es una unidad de cloud-init conectada a la VM, configurada con un pequeño conjunto de claves: ipconfig0 hasta ipconfig3, nameserver, searchdomain, ciuser, cipassword, sshkeys, citype, ciupgrade.

Una de ellas tiene una trampa que sigue invisible hasta que un cliente se queja. ciupgrade tiene default = 1 en el esquema de Proxmox, así que omitirlo no significa «no actualices los paquetes en el primer arranque»; significa «actualiza». Una casilla sin marcar hay que enviarla como un ciupgrade=0 explícito o la casilla miente. Tampoco existe antes de PVE 8.1, donde enviarlo es directamente un error grave y no una clave que se ignora.

Otras dos cosas salen mal de la misma forma en los dos lados. El identificador de instancia tiene que cambiar cuando una máquina recibe una identidad nueva: el iid-local01 de la mayoría de los ejemplos hace que una máquina clonada conserve la configuración de la plantilla. Y la interfaz no tendrá el nombre que se espera: ens160 en VMware, otra cosa en KVM. Netplan con match: {name: "e*"} en lugar de un nombre de dispositivo adivinado es lo que hace que una misma imagen sirva en los dos.

Hardware virtual para el que el huésped tiene controladores

vmxnet3 es la tarjeta de red sensata por defecto en VMware, y tiene una condición previa: necesita VMware Tools en el huésped. Si se instala una plantilla sin Tools y se le pone una tarjeta vmxnet3, el sistema operativo no ve tarjeta de red alguna.

Eso importa dos veces. Antes, porque una plantilla que arranca bien en ESXi puede necesitar e1000e en su lugar. Y después, porque la opción de alto rendimiento de Proxmox es virtio, que necesita sus propios controladores: presentes en Linux moderno, en absoluto en una imagen de Windows de serie. e1000 es la opción lenta, aburrida y que funciona en todas partes en las dos plataformas, y es el primer arranque correcto para una máquina que se está moviendo.

El controlador de disco tiene la misma forma de problema: en Proxmox el camino rápido es virtio-scsi, que otra vez es una cuestión de controladores. No hemos medido qué le hace a un huésped ya instalado cambiarle el tipo de controlador, y es una causa habitual de una máquina que migra limpiamente y luego no arranca.

El agente dentro del huésped cambia de nombre

Una cantidad sorprendente de lo que muestra un panel no viene del hipervisor en absoluto.

En vSphere, guest.ipAddress viene de VMware Tools. También el uso real de disco, a través de guest.disk: la cifra summary.storage.committed a nivel de almacén de datos es la del aprovisionamiento y se lee mal para un disco fino. Que Tools no esté en marcha significa que esos campos están vacíos, y vacío significa «no lo sé», nunca «la máquina no tiene dirección».

Después del traslado la misma información viene de qemu-guest-agent, otro paquete con otro nombre, que hay que instalar. Una flota que migra sin él parece, en el inventario propio, una flota que perdió sus direcciones.

Una advertencia más sobre esa dirección: llega por el canal propio del hipervisor hacia el huésped, no por la red. Puede ser perfectamente exacta para una máquina cuya tarjeta no está conectada a nada. Lo único que demuestra que se puede alcanzar es alcanzarla.

La red, y la conexión que en silencio no lo es

vSphere tiene dos clases de respaldo de red y no se parecen. Una Network estándar se referencia por su nombre; un DistributedVirtualPortgroup, por el UUID de su conmutador más la clave de su propio grupo de puertos.

Si solo se construye la primera forma, en cualquier entorno con un conmutador distribuido se obtiene una tarjeta conectada a nada. vCenter no lo rechaza, porque el nombre sí existe como objeto de red. La máquina arranca sin conectividad y el error está dentro del huésped.

Proxmox es más simple: una NIC nombra un puente, con una etiqueta VLAN opcional. La correspondencia hay que escribirla uno mismo; no hay traducción automática de un grupo de puertos a un puente. Dos cosas más que decidir antes del primer traslado:

• Las direcciones MAC. Llevarlas consigo mantiene válidas las reservas DHCP y las ataduras de licencia, y significa que dos máquinas comparten una MAC si la de origen se vuelve a encender alguna vez. Conviene elegir de forma explícita.
• El cortafuegos por VM. vSphere no lo tiene; eso es NSX, un producto aparte. Proxmox sí. Las máquinas que llegan de VMware nunca han tenido un cortafuegos a nivel de hipervisor, y encenderlo es un proyecto y no una casilla.

Lo que no viaja, y no está en ningún fichero

Algunas cosas no tienen equivalente, y un plan que no las nombra las descubre de una en una:

• Las instantáneas. La máquina cruza como un disco plano; un árbol de instantáneas es una estructura de vSphere sin nada donde importarla.
• El seguimiento de bloques modificados, y con él cualquier historial de copias incrementales que dependiera de él.
• Etiquetas, atributos personalizados y carpetas. Viven en la base de datos de vCenter, no en la máquina.
• Grupos de recursos, reglas de DRS, reservas y participaciones. Proxmox no tiene un planificador equivalente, así que una política de colocación escrita como reglas de DRS se convierte en decisiones sobre en qué nodo se sienta cada máquina.
• La versión de hardware de la VM. Un concepto de vSphere sin contrapartida en Proxmox, así que cualquier cosa indexada por él en la automatización propia es ya código muerto.

Lo que nuestras herramientas hacen, y lo que no

Para ser claros: no hemos construido la migración de vSphere a Proxmox. Nuestras herramientas de migración cubren hoy exactamente una ruta, entre dos paneles de juego, y está detrás de un interruptor de función que está apagado.

Dos reglas de haber construido esa única ruta merecen robarse igualmente, porque hacen que una migración sea revisable en vez de esperanzada. El origen es de solo lectura, como una constante y no como una bandera, de modo que no existe configuración alguna en la que la herramienta escriba en el sistema que se está abandonando. Y una ejecución en seco es obligatoria antes de aplicar, con un recuento por categoría al terminar, origen contra destino. Una migración que no sabe decir cuántas máquinas movió no ha terminado; se ha detenido.

Esto salió de construir las integraciones de vSphere y de Proxmox para Provibr, un panel de gestión de servidores para proveedores de alojamiento, donde los dos hipervisores tienen que poder leerse por una misma interfaz sin que ninguno quede descrito como si fuera el otro. Las notas de configuración están en la documentación de vSphere y de Proxmox.