Cuando una KVM‑VM deja de arrancar de repente, a menudo está en juego más que un simple reinicio. En este artículo muestro un análisis de fallos sistemático y comandos de reparación concretos, para que administradores, ingenieros de sistemas y operadores puedan actuar de forma segura y con conciencia del riesgo. La palabra clave focal „KVM-VM no arranca“ se menciona al inicio, ya que los pasos de comprobación descritos aquí son aplicables tanto a entornos puramente libvirt/QEMU como a Proxmox y otros hosts KVM.
KVM-VM no arranca: Por qué es importante una búsqueda de fallos estructurada
Un fallo de arranque no planificado puede ir desde un simple error de configuración hasta la corrupción del almacenamiento. Sin un enfoque estructurado existen riesgos de pérdida de datos o tiempos de inactividad innecesarios. En la práctica importan la identificación rápida, los modos de solo lectura seguros y una estrategia de reversión clara.
Visión general: causas posibles (de un vistazo)
- Servicios del host detenidos (p. ej. libvirtd, qemu‑kvm)
- Problemas de almacenamiento: LVM‑Thin lleno, NFS/ISCSI desconectado, Ceph OSD caído
- Imagen de disco dañada (qcow2/raw) o inconsistencia de snapshots
- Falta el bootloader/EFI/Grub o initramfs está corrupto
- Eventos de arranque de red/Cloud‑Init que bloquean el inicio
- Pánico de hardware/kernel en el huésped — ninguna consola configurada
Preparación: trabajar de forma segura y minimizar riesgos
Antes de ejecutar comandos de reparación que escriben en disco, debe crear una copia de seguridad o, al menos, una copia de la imagen de disco afectada. Muchas herramientas de reparación son potentes pero no reversibles. Si es posible, trabaje sobre una copia.
Ejemplo: crear una copia de un archivo qcow2 (local):
cp -v --reflink=auto vmdisk.qcow2 vmdisk.qcow2.bakComentario: reflink=auto utiliza CoW en sistemas de archivos como XFS o btrfs si está disponible; de lo contrario se crea una copia normal. Con imágenes grandes esto suele ser más rápido y ahorrar espacio. Si trabaja en almacenamiento en red (NFS/SMB), compruebe antes el espacio libre.
Primeras comprobaciones en el Host
Comience con comprobaciones del host — muchos problemas no se originan en el invitado sino en el host.
1) Estado de los servicios de virtualización
systemctl status libvirtd.service qemu-kvm.service --no-pagerPor qué: libvirtd administra las VMs vía libvirt; si el servicio está detenido o aparecen errores en journalctl, las VMs no arrancan. En Proxmox el servicio se llama pvedaemon o pveproxy — compruebe también esos.
2) Buscar en los logs del host
journalctl -u libvirtd -n 200
journalctl -k -n 200Por qué: dmesg/journal aporta indicios sobre errores de dispositivos de bloque, errores de E/S del kernel o controladores ausentes. Si el host informa errores de E/S, probablemente hay un problema de almacenamiento.
3) Comprobar la capa de almacenamiento
Compruebe LVM, ZFS, Ceph, NFS o iSCSI según la configuración. Ejemplos:
# LVM Pools
lvs -a -o +lv_name,lv_attr,lv_size,lv_free
# ZFS Pools
zpool status
# Ceph
ceph -sPor qué: LVM‑Thin puede llenarse, los pools de ZFS pueden estar degradados, en Ceph pueden faltar OSDs. Si el backend no está disponible, la VM no arrancará o se quedará colgada al adjuntar el disco.
Comprobación de la configuración de la VM
Errores en el XML de la VM (libvirt) o en cadenas de snapshots QCOW suelen causar errores de arranque.
1) Ver información del dominio y el XML
virsh dominfo vmname
virsh dumpxml vmname > /tmp/vmname.xmlPor qué: dumpxml muestra la ruta del disco, la firmware (BIOS vs. OVMF/UEFI), la configuración de la consola y los dispositivos adjuntos. Preste atención a rutas de disco incorrectas, backing stores faltantes en qcow2 o a valores de driver‑type erróneos.
2) Comprobar rutas de archivos de dispositivos
ls -lh /var/lib/libvirt/images/vm-100-disk-1.qcow2
qemu-img info /var/lib/libvirt/images/vm-100-disk-1.qcow2Por qué: qemu-img info proporciona el formato (qcow2/raw), el tamaño virtual y la cadena de snapshots. Si falta el backing file, qemu no podrá arrancar.
Activar la consola del invitado y leer los logs
A menudo la consola serie ayuda a ver los mensajes de arranque en el invitado. La consola serie es un acceso de texto simple a la salida del kernel/GRUB.
1) Usar virsh console
virsh console vmname
# Bei Bedarf: Escape-Sequenz ~. zum BeendenPor qué: Si en el invitado está configurada una consola ttyS0, verá mensajes del kernel e initramfs. Si falta la consola en el invitado, este método no funciona — entonces utilice el procedimiento de adjuntar el disco que se describe más abajo.
2) Reconocer la secuencia de boot‑hooks
Lea los mensajes: ¿se queda colgado en GRUB, en el initramfs (p. ej. shell de busybox) o más adelante en el kernel (kernel panic)? Cada fase tiene sus propios indicadores.
Si la imagen de disco es sospechosa: diagnóstico y comprobaciones seguras
Si la VM se queda colgada al montar la partición raíz o el initramfs genera errores, compruebe la imagen de disco en un host de rescate.
1) Comprobar la integridad de la imagen
qemu-img check -r all /var/lib/libvirt/images/vm-disk.qcow2Por qué: qemu-img check analiza las estructuras qcow2. Atención: las reparaciones deben realizarse solo tras hacer una copia de seguridad. Si se encuentran errores, primero cree una copia de la imagen.
2) Montar la imagen en modo solo-lectura (guestfish/guestmount)
# Solo lectura, con libguestfs
guestfish --ro -a /var/lib/libvirt/images/vm-disk.qcow2 -i -- command :
# Alternativamente montar con libguestfs guestmount
guestmount -a /var/lib/libvirt/images/vm-disk.qcow2 -i /mnt/vmroot --roPor qué: guestfish / guestmount (libguestfs) permite el acceso a particiones dentro de una imagen de VM sin manipular dispositivos loop del kernel. Así puede comprobar /etc/fstab, kernel-cmdline o los registros de cloud-init. Use –ro para no modificar la imagen por error.
3) Usar loopdev & kpartx (alternativa)
losetup -f --show /var/lib/libvirt/images/vm-disk.raw
kpartx -av /dev/loopX
mount /dev/mapper/loopXp1 /mnt/vmroot -o roPor qué: Si libguestfs no está disponible, puede convertir la imagen (qcow2 → raw) y montarla mediante un dispositivo loop. La conversión requiere tiempo y espacio; trabaje sobre copias.
Reparación del sistema de archivos o del gestor de arranque
Si puede acceder a la partición raíz, es posible realizar reparaciones: fsck, regeneración del initramfs o reinstalación de GRUB.
1) Reparar el sistema de archivos (¡siempre sobre una copia!)
# Ejemplo para ext4 (en el dispositivo montado o en el dispositivo reemplazado por loopdev)
e2fsck -f -y /dev/mapper/loopXp1Por qué: e2fsck repara errores del sistema de archivos. -f fuerza la comprobación, -y responde automáticamente Sí — use -y solo si comprende las consecuencias. Para XFS utilice xfs_repair; tenga en cuenta que XFS típicamente no puede repararse en modo solo lectura.
2) Regenerar el initramfs y restaurar GRUB
Si el gestor de arranque o el initramfs están dañados, haga chroot en la imagen y regénrelos:
# Secuencia de ejemplo después de montar las particiones
mount --bind /dev /mnt/vmroot/dev
mount --bind /proc /mnt/vmroot/proc
mount --bind /sys /mnt/vmroot/sys
chroot /mnt/vmroot /bin/bash
update-initramfs -u -k all
grub-install --target=i386-pc /dev/sda
update-grub
exit
umount -l /mnt/vmroot/{dev,proc,sys}
Por qué: update-initramfs genera el initramfs necesario, que durante el arranque del kernel carga módulos y controladores en tiempo de ejecución. grub-install/update-grub escribe un gestor de arranque funcional. En VMs UEFI, tenga en cuenta la configuración de OVMF/EFI y, si procede, use grub-install –target=x86_64-efi en un sistema EFI.
Riesgo: chroot y grub-install modifican el contenido del disco. Por ello, haga una copia de seguridad previa.
Si el problema está en el firmware (UEFI / OVMF)
Muchas VMs modernas usan OVMF (firmware UEFI para QEMU). Si faltan los binarios de OVMF o se referencian incorrectamente, la VM no arranca.
# Comprobar si OVMF está presente
ls -l /usr/share/OVMF /usr/share/ovmf /usr/share/qemu/OVMF* /usr/share/ovmf/*
# Ejemplo: el XML de libvirt muestra Por qué: Archivos ausentes o permisos incorrectos impiden la carga del firmware. Compruebe actualizaciones de paquetes o cambios del proveedor que hayan movido OVMF.
Si la VM no arranca tras un cambio de kernel
Actualizaciones en el kernel huésped o en el initramfs pueden requerir revertir cambios. Si tiene snapshots, compruebe la posibilidad de un rollback; de lo contrario, inicie en un entorno de rescate y cambie el initrd o la versión del kernel.
# En chroot: listar paquetes de kernel antiguos y, si procede, reinstalarlos
apt list --installed | grep Linux-image
apt install Linux-image-
update-grub
Por qué: Las actualizaciones de paquetes pueden suministrar controladores/módulos incompatibles. Un rollback suele ser la solución más rápida, si es posible a corto plazo.
Si la red/cloud-init bloquean el arranque
En imágenes basadas en Cloud‑Init, una configuración de red errónea puede retrasar o impedir el arranque (p. ej., timeout de systemd al solicitar una dirección DHCP). Revise /etc/cloud/cloud.cfg y las configuraciones de Netplan/ifupdown dentro de la imagen.
# Comprobar logs de cloud-init (vía guestmount/guestfish)
cat /var/log/cloud-init.log
cat /var/log/cloud-init-output.logPor qué: cloud-init puede provocar esperas de red; a menudo ayuda ajustar a una configuración estática o establecer parámetros más tolerantes en NetworkManager/Netplan.
Reinicio: adjuntar el disco de la VM a una Rescue‑VM
Si se requieren reparaciones en la imagen, adjuntar el disco a una Rescue‑VM funcional es el método más seguro.
# Ejemplo libvirt: adjuntar disco a Rescue-VM
virsh attach-disk rescue-vm /var/lib/libvirt/images/vm-disk.qcow2 vdb --driver qemu --subdriver qcow2 --persistent
# Alternativa: en la GUI de Proxmox o qm set / qm importdiskPor qué: de este modo puede reparar el sistema de ficheros o leer logs en la Rescue‑VM con herramientas conocidas, sin arrancar la VM objetivo.
Si todo falla: RESTaurar snapshot del disco y plan de rollback
Disponga de una vía de rollback: snapshots existentes, backups o réplicas de almacenamiento. Documente de antemano los pasos mínimos necesarios para lograr la RESTauración del servicio (p. ej., arrancar la VM en otro host, importar el disco desde una réplica).
Lista de verificación de rollback
- Localizar un backup/snapshot válido
- Comprobar espacio e I/O en el host destino
- Probar la importación/RESTore del disco en un host separado
- Realizar pruebas de servicio (SSH, verificación de integridad de la aplicación)
- Comunicación: tiempo de inactividad, problemas, ventana de rollback
Problemas típicos y cómo evitarlos
- Cadenas de snapshots: demasiados snapshots qcow2 aumentan la complejidad — consolide con precaución.
- Thin provisioning: LVM/ZFS thin puede llenarse de repente — configure alertas.
- Versiones de OVMF incompatibles tras una actualización del host — verifique los binarios OVMF.
- Consola ausente: sin consola serial no se ven mensajes de pánico del kernel — configure la consola de forma permanente.
- Errores tipográficos en el XML de libvirt (ruta, nombre del controlador) — siempre comprobar dumpxml.
Ejemplo práctico: imagen qcow2 con archivo base faltante
Síntoma: la VM no arranca, qemu indica archivo base faltante.
# Diagnóstico
qemu-img info vm-disk.qcow2
# La salida muestra backing file: /var/lib/libvirt/images/base.qcow2 (faltante)
# Solución: reemplazar o recrear el backing file
cp /backup/base.qcow2 /var/lib/libvirt/images/
chown libvirt-qemu:kvm /var/lib/libvirt/images/base.qcow2
# Alternativa: rebase para eliminar la referencia al backing file (¡en una copia!)
qemu-img rebase -u -b "" vm-disk.qcow2
Por qué: qcow2 puede usar un backing file; si falta, la imagen queda inconsistente. qemu-img rebase elimina el enlace al backing file; esto solo funciona si los datos del disco son completos por sí mismos — por eso haga un backup antes.
Notas de monitorización y prevención
Para evitar incidentes futuros, ponga en marcha las siguientes medidas:
- Alertas para llenado de almacenamiento (LVM/ZFS/thin/datastore)
- Scrubs/comprobaciones periódicas (p. ej., ZFS scrub, Ceph health checks)
- RESTauraciones de prueba automatizadas en intervalos de mantenimiento
- Consola serial como estándar en plantillas de VM
- Runbooks de recuperación documentados para VMs críticas
Conclusión y lista de prioridades para el análisis de fallos
Cuando una KVM‑VM deja de arrancar, proceda de forma estructurada: servicios del host, almacenamiento, configuración de la VM, consola e integridad del disco. Trabaje siempre sobre copias, documente cada paso y proporcione una opción de reversión. En la mayoría de los casos, el fallo puede corregirse con una combinación de análisis en modo solo lectura (guestmount/guestfish), reparación del sistema de ficheros y, si procede, regeneración de initramfs/GRUB.
Si desea una lista de verificación rápida, comience con estos pasos:
- Comprobar los logs y los servicios del host (libvirtd/qemu, dmesg)
- Comprobar el backend de almacenamiento (LVM/ZFS/Ceph/NFS)
- Comprobar el XML de la VM y la ruta del disco
- Activar la consola serial y leer los logs
- Montar la imagen en modo solo lectura de forma segura y comprobar su contenido
- Sobre una copia: fsck, regenerar initramfs y reinstalar GRUB
Esta entrada pretende servir como introducción práctica al runbook: técnicamente precisa, con comandos concretos y siempre orientada a la seguridad operativa y a las estrategias de recuperación.