Respuesta corta: hay tres mecanismos. CBT (Change Block Tracking) es el nativo de VMware y el más eficiente: te dice exactamente qué bloques cambiaron. Snapshots sirven cuando CBT no está disponible. Sincronización por bloques con rsync o NBD funciona sobre discos ya convertidos. En la práctica se combinan: CBT para la replicación y sincronización por bloques para el delta final.
CBT — Change Block Tracking
VMware lleva un registro de qué bloques del disco cambiaron desde un punto determinado. En vez de comparar el disco entero, preguntás "¿qué cambió desde ayer?" y te responde con la lista exacta.
Ventajas: es el más eficiente por lejos. El tiempo de cada sincronización depende de lo que cambió, no del tamaño del disco.
Requisitos: hay que habilitarlo por VM (ctkEnabled = true), y para que tome efecto la VM necesita un ciclo de apagado o una operación de snapshot.
Cuidado conocido: CBT ha tenido bugs históricos en algunas versiones de ESXi que devuelven información incompleta. Es la razón por la que las herramientas serias validan con un checksum al final. Si venís de una versión vieja de ESXi, verificá que CBT esté sano antes de confiar en él.
Replicación por snapshots
Se toma un snapshot, se copia el estado congelado mientras la VM sigue escribiendo en el delta, y después se sincronizan los cambios.
Ventajas: funciona sin CBT y es fácil de entender.
Desventajas: los snapshots largos degradan el rendimiento de la VM y crecen. Un snapshot de días sobre una VM activa es un problema en sí mismo.
Regla: el snapshot vive lo mínimo indispensable. Si tu replicación tarda tres días, este no es el método.
Sincronización por bloques: rsync, NBD, libvirt
Sobre discos ya convertidos a RAW o QCOW2, se sincroniza a nivel bloque.
`bash
rsync -av –inplace –no-whole-file –progress \
disco.raw destino:/var/lib/libvirt/images/
qemu-nbd –persistent –shared=4 -f qcow2 disco.qcow2
virsh blockcopy dominio vda /destino/disco.qcow2 –wait –verbose
`
--inplace y --no-whole-file son importantes: sin ellos, rsync reescribe el archivo entero y perdés todo el beneficio.
Ventajas: herramientas estándar, sin licencias, funciona con cualquier destino.
Desventajas: más manual y más lento que CBT en discos grandes.
Cuál usar
| CBT | Snapshots | Bloques (rsync/NBD) | |
|---|---|---|---|
| Eficiencia | Alta | Media | Media |
| Complejidad | Media | Baja | Media |
| Requiere VMware | Sí | Sí | No |
| Impacto en la VM | Mínimo | Medio si dura mucho | Mínimo |
| Discos grandes | Ideal | Regular | Aceptable |
| Costo | Incluido | Incluido | Incluido |
En la práctica se combinan: CBT para la replicación inicial y las sincronizaciones intermedias, y una verificación por checksum antes del corte final.
El proceso completo
- Habilitar CBT en la VM
- Exportación inicial del VMDK y conversión a QCOW2 o RAW
- Replicación continua de los bloques modificados, con la VM en producción
- Importación parcial en destino y validación en un entorno aislado
- Corte: apagar la VM en VMware, replicar el último delta, arrancar en destino
- Pruebas post-corte: servicios, integraciones, rendimiento
- Desmantelamiento del origen recién cuando el destino esté estable
Los pasos 1 a 4 no tienen impacto en el servicio. El único con downtime es el 5.
Herramientas
- virt-v2v — la herramienta de Red Hat para convertir VMs de VMware a KVM. Hace mucho del trabajo sucio, incluida la instalación de drivers virtio. Es el punto de partida obligado.
- CloudEndure, Veeam, Zerto y similares — comerciales, agregan orquestación, tableros y soporte. A escala se justifican.
- Scripts propios sobre CBT + rsync — viable y muy usado. Requiere trabajo de ingeniería propio.
Para menos de 30 VMs, virt-v2v más un procedimiento ordenado suele alcanzar. Arriba de 100, la orquestación deja de ser opcional.
Preguntas frecuentes
¿Cuántas sincronizaciones conviene hacer?
Las necesarias para que el delta final sea chico. Un patrón razonable: inicial, una diaria durante la semana previa, y una última lo más cerca posible del corte.
¿Cómo sé que la copia es correcta?
Con checksum antes del corte. No confíes solo en el "completado con éxito" de la herramienta, sobre todo con CBT.
¿Puedo replicar varias VMs en paralelo?
Sí, y a escala es necesario. El límite es el ancho de banda y la carga sobre el almacenamiento origen.
¿Y si el delta crece más rápido de lo que sincronizo?
No converge nunca. Se resuelve con más ancho de banda, sincronizando en horarios de baja actividad, o —para bases de datos— usando la replicación nativa del motor en lugar de replicar el disco.
En resumen
Tres mecanismos, y en la práctica una combinación: CBT para saber qué cambió, sincronización por bloques para el delta final, y checksum para confiar. Con eso, la ventana de corte deja de depender del tamaño del disco.
Cómo se ejecuta ese corte y cómo se vuelve atrás está en la ventana de corte.
3 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.