La migración de una máquina física a una máquina virtual en Proxmox VE suele aparecer en el peor momento: cuando el servidor envejece, el fabricante ya no da soporte, el disco empieza a fallar o el negocio no puede permitirse una reinstalación completa. En ese contexto, el llamado P2V (Physical to Virtual) se convierte en una maniobra de continuidad: capturar el sistema tal y como está, convertirlo en imagen y levantarlo en un hipervisor moderno.
El proceso, sin embargo, no es “copiar y pegar”. En Windows —especialmente en versiones antiguas— el cambio de controladora de disco puede provocar pantallazos (clásico STOP 0x7B) si el sistema no tiene habilitados los controladores correctos. En Linux, el reto suele ser otro: asegurar una captura fiable del disco y una conversión sin corrupción. La guía práctica que circula en entornos Proxmox describe un flujo habitual, con varias decisiones críticas que determinan si el primer arranque será limpio… o un fin de semana perdido.
1) Antes de tocar el disco: preparar Windows con MergeIDE (cuando aplica)
En entornos Windows antiguos (por ejemplo, Windows XP o migraciones desde imágenes de VMware/VirtualBox donde cambia la controladora), se menciona una herramienta conocida como MergeIDE. Su función es pragmática: inyecta claves de registro para habilitar controladores IDE y aumentar las probabilidades de arranque cuando el sistema “despierta” bajo una controladora distinta.
La advertencia es importante: puede haber casos en los que arranque sin MergeIDE, pero el procedimiento se vuelve más incierto y, a veces, más complejo de recuperar. Por eso, cuando el origen es un Windows “delicado” o muy atado a un stack de drivers antiguo, ejecutar MergeIDE antes de capturar el disco suele considerarse una medida preventiva.
2) Capturar la máquina física: GRML como entorno de rescate y ddrescue para la imagen
Con el sistema preparado (o asumido el riesgo), llega el paso más delicado: crear una imagen del disco. Aquí se recomienda arrancar el servidor desde un Linux “live” orientado a administración y rescate, como GRML, y volcar el contenido del disco con GNU ddrescue hacia un destino externo (USB, NAS o un recurso en red como NFS/Samba).
La lógica de ddrescue es clara: prioriza la fiabilidad y permite continuar una copia si hay sectores dañados gracias a su mapfile (archivo de estado). En un P2V, esto no solo ayuda cuando el disco está en mal estado: también aporta control y trazabilidad del copiado.
Ejemplo típico (ajústese a su entorno):
# Identificar el disco origen (ej.: /dev/sda) y montar el destino (ej.: /mnt/copia)
ddrescue -f -n /dev/sda /mnt/copia/servidor.img /mnt/copia/servidor.map
# Segunda pasada opcional para intentar recuperar sectores problemáticos
ddrescue -d -r3 /dev/sda /mnt/copia/servidor.img /mnt/copia/servidor.map
Lenguaje del código: PHP (php)La disciplina aquí marca el resultado: validar bien qué es origen y qué es destino, conservar el mapfile, y no reutilizar por error un mapfile antiguo de otra máquina.
3) Convertir la imagen a un formato “amigable” para Proxmox
Una vez obtenida la imagen (por ejemplo, RAW con ddrescue) o si se parte de un disco virtual (VMDK/VDI), toca la conversión. La herramienta estándar en el ecosistema KVM es qemu-img, que permite convertir entre formatos (RAW, QCOW2, VMDK, VDI, etc.). El objetivo habitual en Proxmox es terminar en QCOW2 (si se quiere imagen tipo fichero con snapshots) o en RAW sobre un almacenamiento gestionado.
Ejemplo genérico de conversión de RAW a QCOW2:
qemu-img convert -f raw -O qcow2 servidor.img servidor.qcow2
Lenguaje del código: CSS (css)Y si el origen ya era un VMDK:
qemu-img convert -f vmdk -O qcow2 midisco.vmdk midisco.qcow2
Lenguaje del código: CSS (css)Un matiz operacional: estas conversiones pueden tardar bastante y deben hacerse con la imagen “en frío”, sin procesos que la estén usando.
4) Importar el disco en Proxmox: qemu-img manual o qm importdisk (la vía más cómoda)
En Proxmox, hay dos enfoques habituales:
Opción A: crear VM y sustituir el fichero del disco
Se crea una VM “vacía” con disco en un almacenamiento tipo fichero (por ejemplo, NFS o directorio). Después, se renombra el QCOW2 convertido para que coincida con el nombre que espera Proxmox. Es funcional, pero exige orden y cuidado con nombres y backups del fichero original.
Opción B: qm importdisk (recomendada por su simplicidad)
Se crea una VM (idealmente sin disco, o borrando el disco por defecto para mantener el orden vmXXX-disk-0) y luego se importa el disco:
qm importdisk <vmid> /ruta/servidor.qcow2 <almacenamiento>
Lenguaje del código: HTML, XML (xml)Tras importar, el disco queda como “unused” en el hardware de la VM y se asigna desde la interfaz gráfica o CLI, eligiendo el bus apropiado (SATA/IDE para primer arranque conservador, VirtIO para rendimiento una vez instalados drivers).
5) Primer arranque y transición a VirtIO: rendimiento sin sustos
Una estrategia que se repite en migraciones Windows es arrancar primero con un bus “tolerante” (IDE/SATA) y, una vez que el sistema inicia, instalar VirtIO dentro del invitado. Proxmox mantiene documentación específica sobre Windows VirtIO Drivers, con la ISO y repositorios recomendados.
Para forzar la instalación del driver de almacenamiento VirtIO en Windows, es común añadir un disco pequeño adicional (por ejemplo, de 5 GB) conectado como VirtIO. Si Windows solicita drivers, se montan desde la ISO VirtIO y se instalan. En el siguiente reinicio, ya se puede planificar la migración del disco principal a VirtIO y, muy importante, ajustar el orden de arranque para evitar el clásico “arranca, pero no desde donde creías”.
6) Si algo falla: los dos “trucos” que más se repiten
Cuando una VM no arranca tras el import, hay dos correcciones típicas que suelen resolver más casos de los que parece:
- Desasignar y reasignar el disco: en Proxmox, quitar el disco y volver a añadirlo desde “unused disk” puede recalcular rutas y orden.
- Revisar el boot order: después de tocar buses (SATA ↔ VirtIO) o añadir discos, Proxmox puede intentar arrancar desde el dispositivo equivocado.
Y, para casos avanzados, Proxmox también reúne técnicas de migración más completas para escenarios P2V, drivers y controladoras.
Preguntas frecuentes
¿Cómo migrar un servidor físico a Proxmox sin reinstalar Windows ni perder configuración?
El enfoque más habitual es un P2V con imagen del disco (ddrescue o herramienta equivalente), conversión con qemu-img y posterior importación con qm importdisk, arrancando primero con SATA/IDE y migrando a VirtIO tras instalar drivers.
¿Qué comando usar para convertir una imagen RAW o VMDK a QCOW2 para Proxmox?
La herramienta estándar es qemu-img convert, indicando formato de origen (-f raw o -f vmdk) y destino (-O qcow2). Es recomendable hacerlo con la imagen “en frío” y verificando espacio disponible.
¿Por qué Windows a veces no arranca tras importar el disco en Proxmox?
Con frecuencia es un problema de controladora (drivers) o de orden de arranque. En sistemas antiguos, habilitar drivers IDE (MergeIDE) antes del volcado puede evitar errores al cambiar de hardware virtual.
¿Cómo pasar un Windows importado a VirtIO sin que deje de arrancar?
Primero se instala VirtIO dentro del sistema (a veces añadiendo un disco VirtIO pequeño para forzar drivers), luego se cambia el disco principal a VirtIO y se actualiza el orden de arranque para apuntar al nuevo bus.
vía: Proxmox
