Este informe de septiembre de 2025 debe considerarse un fallo histórico y específico de la versión beta de ZVM, no una conclusión actual de que «ZVM no funciona». El usuario ejecutaba ZimaOS 1.4.4-beta1 y observaba repetidamente que el inicio de las máquinas virtuales fallaba con el mensaje interno client socket is closed. Zima-Giorgio probó una máquina virtual con Ubuntu en la misma versión beta y dijo que funcionaba con normalidad, por lo que el problema no era universal en todas las instalaciones de 1.4.4-beta1.
La parte útil del hilo es el acotamiento del diagnóstico. KVM estaba cargado, la red predeterminada de libvirt y el grupo de almacenamiento estaban activos, y restablecer la configuración de libvirt no ayudó. Los registros posteriores mostraron virtqemud no se pudo conectar a un socket de red de libvirt y luego se desactivó.
Reiniciar libvirt-guests no era la capa adecuada
El usuario original primero reinició libvirt-guests.serviceUn miembro de la comunidad señaló que este servicio se encarga principalmente de guardar y restaurar los estados de los invitados durante el apagado del host; no es el demonio principal de QEMU/libvirt que inicia la máquina virtual.
Por lo tanto, un reinicio correcto en ese punto no demostró que la pila de máquinas virtuales estuviera funcionando correctamente.
La aceleración de hardware de KVM estaba disponible
El usuario comprobó los módulos cargados y encontró ambos kvm y kvm_intelEso descartó una causa común: que la compatibilidad con la virtualización no estuviera disponible por completo a nivel del kernel.
La red predeterminada y los grupos de almacenamiento estaban activos
El hilo también comprobó la red predeterminada y el grupo de almacenamiento de libvirt. Ambos aparecían activos y accesibles.
Eso hizo menos probable que el almacenamiento de las máquinas virtuales faltara o que la red NAT estuviera inactiva como causa principal.
Un restablecimiento completo de la configuración de libvirt no solucionó el problema
El autor original eliminó la configuración de /etc/libvirt y /var/lib/libvirt y reprodujo el fallo. Ese fue un paso de diagnóstico destructivo y no debería recomendarse como solución inicial actual.
En un sistema de producción moderno, haz una copia de seguridad de las definiciones de las máquinas virtuales y de las imágenes de disco antes de modificar el estado de libvirt.
El registro posterior apuntaba a virtqemud y a un socket de red
A continuación, el usuario publicó un error más útil: virtqemud no se pudo conectar a un socket en /var/run/libvirt/..., después de lo cual el servicio se desactivó. Por lo tanto, el mensaje de la interfaz sobre el socket del cliente cerrado probablemente era un síntoma posterior del problema del demonio del backend.
Un demonio que muestra «salió correctamente» aún puede bloquear la aplicación
Varios demonios de libvirt se activan mediante sockets y pueden detenerse cuando están inactivos, por lo que «inactivo» por sí solo no demuestra que haya un fallo. En este caso, sin embargo, la conexión explícita fallida del socket y los registros de terminación de la máquina virtual hicieron sospechosa la interacción con el backend.
Interpreta el estado de systemd junto con el error real de libvirt/QEMU, no a partir de una sola línea de estado aislada.
IceWhale no pudo reproducir el fallo en sus pruebas
Zima-Giorgio dijo que una máquina virtual de Ubuntu funcionaba con normalidad en la versión 1.4.4-beta1 y solicitó el tipo de sistema operativo y capturas de pantalla o vídeo. Este es un límite oficial importante: la fuente muestra un fallo real de un usuario, pero no una interrupción confirmada que afectara a toda la versión beta.
El usuario lo escaló como un error de la versión beta en GitHub
El usuario publicó los registros detallados y un vídeo en el rastreador de GitHub de IceWhale porque era difícil adjuntar archivos en el foro. El archivo adjunto era un vídeo, no una captura de pantalla estática del foro.
El hilo público del foro no muestra ninguna nota de versión ni parche final que identifique una única causa raíz confirmada.
No apliques la manipulación de servicios de la versión 1.4.4-beta1 a la versión actual de ZimaOS
La versión actual de ZimaOS está muy por delante de esta versión beta. El empaquetado de libvirt, la interfaz de ZVM, la compatibilidad con imágenes y el comportamiento de los servicios de systemd pueden ser diferentes.
Para un fallo actual similar, recopila el error de la máquina virtual, la versión actual de ZimaOS, el estado de KVM, el estado de la red y el almacenamiento de libvirt y los registros de QEMU antes de modificar archivos del sistema.
El fallo cambió a medida que el usuario recopiló mejores pruebas
La teoría inicial era simplemente que la versión beta de ZVM tenía un error más profundo, porque reiniciar un servicio no ayudaba. La siguiente ronda estableció que KVM existía y que la red y el almacenamiento predeterminados funcionaban correctamente. Solo después apareció el error del socket dentro de virtqemud se hizo visible.
Esta progresión es un buen modelo para solucionar problemas de virtualización: evita pasar directamente de un error genérico de la interfaz a reinstalar el hipervisor. Descarta por orden las capas de aceleración de hardware, almacenamiento, red y servicios.
virtqemud depende del resto de la pila modular de libvirt
El fallo registrado hacía referencia a un socket de red de libvirt. En el libvirt modular moderno, la gestión de QEMU, la gestión de red, el registro y otras funciones pueden ejecutarse en demonios y sockets independientes. Por tanto, un demonio de QEMU puede estar presente y, aun así, no poder comunicarse con el demonio de red que necesita.
Esto ayuda a explicar por qué una máquina virtual podía fallar aunque KVM y el grupo de almacenamiento parecieran funcionar con normalidad.
Los registros de QEMU mostraron que los huéspedes estaban siendo terminados
Los registros de QEMU del usuario mostraban repetidamente que los procesos invitados terminaban con la señal 15 de virtqemud. Esto respalda la idea de que los huéspedes estaban siendo cerrados por la pila de control de virtualización, en lugar de bloquearse por una ISO defectuosa de Windows o Linux.
El usuario también probó varias imágenes ISO y observó el mismo comportamiento, lo que debilita aún más la explicación de que el medio de instalación estuviera defectuoso.
Una regresión de una beta debe compararse con la versión estable antes de realizar reparaciones destructivas
Una respuesta de la comunidad sugirió volver al canal estable si se necesitaban máquinas virtuales de inmediato. Es un límite de diagnóstico razonable para un fallo exclusivo de una beta: si la misma máquina virtual y el mismo hardware funcionan en la versión estable, la beta se convierte en la variable modificada más relevante.
El hilo de origen no incluye una confirmación final del autor original sobre la reversión, por lo que esto sigue siendo una estrategia de diagnóstico y no una solución verificada en el caso de origen.
Ante un fallo actual de ZVM, conserva el primer error del backend
Los mensajes de la interfaz, como «el socket del cliente está cerrado», suelen aparecer después del evento significativo del backend. Captura los registros del sistema y de QEMU en el momento exacto en que se hace clic en Iniciar y conserva el error más antiguo, en lugar de limitarte al mensaje de estado final.
Esto reduce el riesgo de tratar un síntoma posterior como la causa raíz.
Preguntas frecuentes históricas sobre la beta de ZVM
¿Faltaba KVM en el caso original?
No. El usuario confirmó que los módulos de KVM estaban cargados.
¿Restablecer la configuración de libvirt solucionó el problema?
No.
¿Se confirmó el problema en todos los sistemas con la versión 1.4.4-beta1?
No. Zima-Giorgio dijo que una máquina virtual de prueba de Ubuntu funcionaba con normalidad en la misma beta.
¿Cuál fue la pista más contundente del backend?
virtqemud registró un fallo al conectarse a un socket de red de libvirt antes de desactivarse.
