Proxmox: la vuelta a VMware sigue sin construirse
En inventarios VMware más Proxmox, el retorno a ESXi sigue siendo el caso duro: dos a cuatro horas más medio día de red.
Un inventario mixto de VMware y Proxmox puede entregar por la noche copias de seguridad en verde. En cuanto los datos de producción están en Proxmox, a menudo falta un camino de vuelta fiable. El caso duro necesita de dos a cuatro horas para la restauración más medio día para red y puesta en marcha, hasta que la máquina vuelve a responder en ESXi.
Con valoraciones de Sergei Serdyuk, VP of Product Management en NAKIVO
Lo más importante en resumen
- El Bitmap muere con el proceso. El CBT de VMware sobrevive al reboot y a vMotion en el datastore. El QEMU-Dirty-Bitmap vive en la memoria del proceso en ejecución y cae tras un reboot del huésped, un reboot del host o una live-migration.
- El verde cuenta bloques leídos. Un job correcto no acredita la recuperabilidad. Para eso quedan dos pruebas: un restore hasta la respuesta de la máquina y una ventana de immutability que cubra el tiempo de permanencia.
- El camino de vuelta duro dura horas. Si la producción está en Proxmox, el inicio de sesión en ESXi solo vuelve tras la restauración y el trabajo de red.
Relacionado:VMware se ha ido, el backup no se ha movido con él / Shock de precios de VMware: empresas DACH ante una elección dura
¿Qué es Changed Block Tracking? CBT es el mapa persistente de VMware de bloques modificados en el datastore. Sobrevive al reboot y a vMotion. El QEMU-Dirty-Bitmap asume el mismo papel bajo Proxmox y vive en la memoria del proceso en ejecución.
| Situación | Tiempo hasta el inicio de sesión |
|---|---|
| Migración inacabada, original de VMware presente | Minutos |
| Camino de vuelta duro de 2-TB a ESXi | 2 a 4 horas más medio día para red y puesta en marcha |
Fuente: Sergei Serdyuk, respuestas por escrito, 17. septiembre 2026.
El bitmap que no sobrevive al reboot
VMware deposita Changed Block Tracking en el Datastore. El mapa sobrevive a Power-Cycle, Reboot y vMotion, porque reside con la máquina virtual en el disco. En Proxmox asume el mismo papel el QEMU-Dirty-Bitmap y vive en la memoria del proceso QEMU en ejecución. Si termina el proceso, termina el mapa.
La primera noche tras el Cutover engaña aquí. La máquina migrada es para el producto de backup un objeto nuevo. La primera ejecución es por eso un Full planificado, con independencia de lo bien que haya funcionado antes CBT en el lado de VMware. Lo no planificado llega después: tras un reboot del invitado, un Host-Reboot o una Live-Migration falta el bitmap volátil. La siguiente ejecución incremental vuelve a leer el disco por completo. El job tiene entonces tamaño de Full en una ventana dimensionada para incrementales. En la semana parece un valor atípico. En realidad el mapa está muerto.
Proxmox VE 9.0 ofrece bitmaps persistentes en qcow2. Los fabricantes se ponen al día. Ceph RBD y raw ZFS no tienen para ello un lugar de almacenamiento; allí el mapa sigue siendo volátil. El Data Mover se ejecuta por regla general en el host de Proxmox y comparte la CPU con los invitados de producción. Los productos recortan el paralelismo claramente por debajo de lo que recibe un proxy de VMware. Por cada disco en vuelo el host necesita un NBD libre. Si se agotan los dispositivos, el job falla en lugar de ponerse en cola. Más discos en una ejecución significan más canales NBD abiertos y más carga en el mismo host que ya calcula los invitados.
El verde cuenta bloques leídos
Un resultado de job en verde significa: el producto ha leído los bloques que debía leer. Los ha escrito. Si de ello se puede construir una máquina arrancable, ese estado no lo mide. La copia puede ser crash-consistent aunque la aplicación necesitara app-consistent. El repositorio puede degenerar. Un punto malo en una cadena Forever-Incremental arrastra todo lo que viene después. Ransomware puede alcanzar el inventario. La retención puede eliminar el último punto bueno. La clave puede residir solo en el sistema que hay que restaurar. Tras un cambio de plataforma la copia puede ser correcta y, aun así, faltar la ruta de restore.
Dos pruebas sustituyen la suposición. La primera es Verification: restore, arranque, respuesta de la máquina. La segunda es Immutability: una ventana que se extiende más allá del tiempo de detectar una intrusión. Los equipos con práctica de ejercicios encuentran la laguna en la siguiente prueba, a menudo en el ensayo de migración. Las explotaciones más pequeñas la encuentran en un caso real, cuando la máquina debe volver a funcionar. El estado en el dashboard permanece verde en ambos casos hasta que alguien ejecuta el restore.
El camino de vuelta a ESXi dura horas
Mientras la migración no esté terminada, el camino fácil sigue abierto. El original de VMware aún existe. La máquina de Proxmox se detiene, la máquina de VMware arranca, el inicio de sesión vuelve en minutos. El caso duro es la situación inversa: la migración se ha ejecutado, la máquina virtual ha acumulado datos de producción en Proxmox, el estado actual debe volver a ESXi. Eso es un Cross-Platform-Restore.
Para una restauración convencional de 2 TB, Serdyuk cita de dos a cuatro horas y medio día más para la red y el resto de la puesta en servicio, hasta que el inicio de sesión está listo. La traducción del hardware virtual es tarea del producto de backup: formato de disco, Storage-Controller, adaptador de red, modo de firmware, orden de arranque. El producto crea la máquina tal como ESXi la espera. Introduce drivers. Sin esa ruta, el estado actual de los datos permanece en Proxmox y no vuelve a ESXi. Quien busca el camino de vuelta recién después del Cutover lo busca bajo presión de tiempo y con un volumen de datos ya crecido.
El traslado planificado sigue siendo el caso fácil
Las migraciones ordenadas con POC, Freigabe y Failback capturan la mayor parte de los errores de migración. Quien piensa en POC, Freigabe y Failback conserva el original de VMware hasta que la prueba en Proxmox tiene éxito. La primera noche sigue siendo un Full planificado. Los bitmaps persistentes en qcow2 bajo Proxmox VE 9.0 acortan los Full posteriores no planificados. En el producto de backup, Compatibility es un smoke-test y va rápido. Full Support significa regresión sobre Storage, Restore y Cross-Version-Restore, y solo después Shipping.
La lista de Supported-Versions vale antes que apt. Hasta que exista Full Support, permanece un Canary-Node; las máquinas de alto valor están en otro sitio. El primer backup tras el upgrade cuenta como punto de restore solo cuando se ha restaurado a partir de él. Un upgrade que coincide con el Retention-Rollover deja caducar el último punto bueno mientras aún está abierto si el nuevo aguanta.
Una ventana de Immutability más corta que el tiempo de detectar una irrupción es la mala configuración que describe Serdyuk. El atacante permanece dos meses. Borra copias de seguridad fuera de la ventana de Lock. Todo lo que está en el Lock se escribió después del compromiso. La ventana debe llegar más lejos que el tiempo de permanencia plausible. Los puntos de recovery necesitan un escaneo de malware. La prueba más barata sigue siendo un restore de una máquina desde un punto más antiguo de lo pensado, 45 o 60 días atrás, solo a través de la cuenta local del sistema de backup, con el Domain como untrusted.
Preguntas frecuentes
¿Por qué la primera copia de seguridad tras el cutover es un Full?
La máquina migrada es para el producto de backup un objeto nuevo. El primer recorrido tras el cambio a Proxmox es por eso un Full planificado, con independencia del historial de CBT en VMware.
¿Qué acredita un resultado de job verde?
Acredita que los bloques solicitados se leyeron y se escribieron. Boot, aplicación y red no los comprueba este estado. Para eso quedan el restore hasta la respuesta de la máquina y una ventana de Immutability por encima del tiempo de permanencia.
¿Cuánto dura el camino de vuelta de un fileserver de 2 TB a ESXi?
En el estado de migración inacabado, minutos, porque el original de VMware sigue en marcha. En el caso duro con datos de producción en Proxmox, Serdyuk indica de dos a cuatro horas para la restauración y medio día más para red y el resto de la puesta en servicio, hasta que el inicio de sesión está listo.
¿Se conserva el Dirty-Bitmap bajo Proxmox VE 9.0?
En qcow2, Proxmox VE 9.0 ofrece bitmaps persistentes. Ceph RBD y raw ZFS no tienen un lugar de almacenamiento para ello.
¿Qué ventana de Immutability describe Serdyuk como mala configuración?
Una ventana más corta que el tiempo de detectar una intrusion. Como patrón cita dos meses de permanencia. La prueba: restore 45 o 60 días atrás, cuenta local de backup, Domain untrusted.
Selección editorial
cloudmagazinCloud-Repatriation: cuándo merece la pena repatriarMás de la red MBF Media
MyBusinessFutureLos fabricantes notifican incidentes CRA a ENISA antes que al CSIRTDigital ChiefsCancillería federal: 3000 empleados se pasan a openDeskSecurityTodayEl cliente ScreenConnect ejecuta archivos sin OK del hostFuente de la imagen: generada por IA (septiembre 2026)
Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.
