Respuesta corta: virtio es la familia de dispositivos paravirtualizados de KVM —disco, red, SCSI— que da rendimiento cercano al hardware real. Si el sistema operativo de la VM no tiene los drivers virtio disponibles antes de migrar, la máquina arranca sin red, con rendimiento degradado, o directamente no arranca. Es la causa número uno de migraciones que fallan, y se previene por completo preparando la VM mientras todavía corre en VMware.
La regla de oro: los drivers se instalan en origen, no en destino.
Por qué existe virtio
Una VM puede acceder al hardware de dos maneras. La emulación completa hace que el hipervisor simule un dispositivo real —una placa de red Intel e1000, por ejemplo— y el sistema operativo usa su driver de siempre. Funciona con todo, pero es lento: cada operación pasa por una capa de traducción.
La paravirtualización cambia el trato: el sistema operativo sabe que está virtualizado y habla directo con el hipervisor por un canal optimizado. Eso es virtio. Menos capas, más velocidad.
Los que importan en una migración:
| Dispositivo | Para qué |
|---|---|
virtio-blk | Disco, acceso directo por bloques |
virtio-scsi | Disco vía SCSI. El recomendado: soporta más discos y TRIM |
virtio-net | Red |
virtio-balloon | Gestión dinámica de memoria |
virtio-rng | Entropía para el invitado |
El problema, en concreto
En VMware tu VM usa vmxnet3 para red y algún controlador propietario (LSI Logic, BusLogic o PVSCSI) para disco. En KVM esos dispositivos no existen.
Si migrás sin preparar:
- El disco no se detecta → kernel panic o pantalla azul al arrancar
- La red no aparece → la VM arranca aislada
- Si funciona con emulación, el rendimiento cae mucho respecto de lo que tenías
Linux: preparar antes de mover
En Debian y Ubuntu el soporte suele estar de fábrica, pero conviene verificarlo igual.
1. Confirmar que los módulos existen:
`bash
ls /lib/modules/$(uname -r)/kernel/drivers/virtio/
modinfo virtio_blk virtio_scsi virtio_net | grep filename
`
2. Forzarlos dentro del initramfs. Este es el paso que se saltea y rompe todo:
`bash
echo -e "virtio\nvirtio_pci\nvirtio_blk\nvirtio_scsi\nvirtio_net" | \
sudo tee -a /etc/initramfs-tools/modules
sudo update-initramfs -u -k all
sudo dracut –add-drivers "virtio virtio_pci virtio_blk virtio_scsi virtio_net" \
–force –regenerate-all
`
3. Pasar fstab y GRUB a UUID, porque el disco va a cambiar de /dev/sda a /dev/vda:
`bash
blkid # obtener los UUID
sudo nano /etc/fstab # reemplazar /dev/sdX por UUID=…
sudo update-grub # o grub2-mkconfig -o /boot/grub2/grub.cfg
`
4. Verificar que el módulo quedó adentro:
`bash
lsinitramfs /boot/initrd.img-$(uname -r) | grep virtio # Debian/Ubuntu
lsinitrd | grep virtio # RHEL y familia
`
Si ese grep no devuelve nada, la VM no va a arrancar. Es la verificación más importante de todo el procedimiento.
5. Instalar el agente:
`bash
sudo apt install qemu-guest-agent # o dnf install qemu-guest-agent
`
Windows: el caso que exige más cuidado
Windows no trae drivers virtio. Hay que instalarlos mientras la VM todavía corre en VMware.
1. Bajar el ISO oficial de drivers virtio del Fedora Project (virtio-win.iso).
2. Montarlo en la VM en VMware e instalar el paquete completo (virtio-win-guest-tools.exe).
3. Precargar el driver de disco, que es el truco clave. Windows no carga un driver de arranque que nunca vio. Se agrega un disco temporal con controlador virtio para que Windows lo detecte e instale, y después se quita:
- Agregar un disco chico a la VM con controlador virtio-scsi
- Arrancar Windows → detecta el nuevo hardware e instala el driver
- Apagar y quitar el disco temporal
- Ahora sí, migrar
Sin este paso, el resultado típico es INACCESSIBLE_BOOT_DEVICE.
4. Desinstalar VMware Tools antes de migrar.
5. Instalar el guest agent de QEMU, que viene en el mismo ISO.
Por versión
| Versión | Situación |
|---|---|
| Windows Server 2016 / 2019 / 2022 | Sin problemas. Drivers oficiales y firmados |
| Windows 10 / 11 | Igual, pero verificar Secure Boot y que la firma del driver sea aceptada |
| Windows Server 2012 / 2012 R2 | Funciona, con drivers de la rama correspondiente |
| Windows Server 2008 R2 y anteriores | Sin soporte oficial de virtio moderno. Hay que emular IDE o SATA como paso intermedio. Conviene planificar actualizar el SO junto con la migración |
Preguntas frecuentes
¿Puedo instalar virtio después de migrar?
En Linux, a veces sí, con virt-rescue o montando el disco desde afuera. En Windows es mucho más difícil. Prepararlo antes toma 20 minutos; arreglarlo después puede llevarte medio día.
¿Qué pasa si migro sin virtio?
Si emulaste IDE/SATA y e1000, probablemente arranque, pero con rendimiento notablemente peor. Es un parche aceptable como paso intermedio, no como destino.
¿virtio-blk o virtio-scsi?
virtio-scsi. Soporta más discos, permite passthrough y maneja TRIM/discard, que sobre thin provisioning importa mucho.
¿Y Windows Server 2008 R2?
Es el caso más incómodo. Emular SATA funciona, pero además ese sistema no tiene parches de seguridad hace años. La recomendación honesta es aprovechar la migración para actualizarlo.
En resumen
virtio es el punto donde se decide si la migración es tranquila o es una noche larga. La preparación toma minutos por VM y se hace antes, con la máquina todavía en VMware.
Y la verificación que no hay que saltear nunca: que el módulo virtio esté dentro del initramfs. Si no está, no arranca.
3 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.