Questo resoconto del settembre 2025 va considerato un problema storico specifico della versione beta di ZVM, non una conclusione attuale secondo cui «ZVM non funziona». L'utente eseguiva ZimaOS 1.4.4-beta1 e riscontrava ripetutamente il fallimento dell'avvio della VM con il messaggio interno client socket is closed. Zima-Giorgio ha testato una VM Ubuntu sulla stessa versione beta e ha dichiarato che funzionava normalmente, quindi il problema non era universale per tutte le installazioni di 1.4.4-beta1.
La parte utile della discussione è il restringimento diagnostico. KVM era caricato, la rete libvirt predefinita e il pool di storage erano attivi e il ripristino della configurazione di libvirt non aveva aiutato. I log successivi mostravano virtqemud non riusciva a connettersi a un socket di rete di libvirt e poi si disattivava.
Riavviare libvirt-guests non era il livello corretto
Inizialmente l'utente ha riavviato libvirt-guests.service. Un membro della community ha fatto notare che questo servizio gestisce principalmente il salvataggio e il ripristino dei guest durante l'arresto dell'host; non è il demone QEMU/libvirt principale che avvia la VM.
Un riavvio riuscito di quel servizio non dimostrava quindi che lo stack delle VM fosse operativo.
L'accelerazione hardware KVM era disponibile
L'utente ha controllato i moduli caricati e ha trovato entrambi kvm e kvm_intel. Questo ha escluso una causa comune: il supporto alla virtualizzazione era completamente indisponibile a livello del kernel.
La rete predefinita e i pool di storage erano attivi
La discussione ha inoltre verificato la rete predefinita e il pool di storage di libvirt. Entrambi risultavano attivi e accessibili.
Ciò ha reso meno probabile che la causa principale fosse l'assenza dello storage delle VM o una rete NAT inattiva.
Un ripristino completo della configurazione di libvirt non ha risolto il problema
L'autore originale ha eliminato la configurazione in /etc/libvirt e /var/lib/libvirt e il problema si è riprodotto comunque. Si trattava di un passaggio diagnostico distruttivo e non dovrebbe essere promosso come soluzione iniziale attuale.
Su un sistema di produzione moderno, esegui il backup delle definizioni delle VM e delle immagini disco prima di modificare lo stato di libvirt.
I log successivi indicavano virtqemud e un socket di rete
L'utente ha quindi pubblicato un errore più utile: virtqemud impossibile connettersi a un socket in /var/run/libvirt/..., dopodiché il servizio veniva disattivato. Il messaggio dell’interfaccia relativo alla chiusura del socket del client era quindi probabilmente un sintomo secondario del problema del demone backend.
Un demone che mostra “Terminato correttamente” può comunque interrompere il funzionamento dell’applicazione
Diversi demoni libvirt vengono attivati tramite socket e possono arrestarsi quando sono inattivi, quindi il solo stato “inattivo” non dimostra un problema. In questo caso, tuttavia, la connessione al socket esplicitamente fallita, insieme ai log di terminazione della VM, rendeva sospetta l’interazione con il backend.
Interpreta lo stato di systemd insieme all’errore effettivo di libvirt/QEMU, non basandoti su una sola riga di stato isolata.
IceWhale non è riuscita a riprodurre il problema nei propri test
Zima-Giorgio ha dichiarato che una VM Ubuntu funzionava normalmente sulla 1.4.4-beta1 e ha chiesto il tipo di sistema operativo e screenshot/video. Questo è un importante limite ufficiale: la fonte mostra un problema reale riscontrato da un utente, ma non un’interruzione del servizio confermata per l’intera beta.
L’utente lo ha segnalato come bug della beta su GitHub
L’autore ha spostato i log dettagliati e un video nel tracker GitHub di IceWhale, perché il caricamento dei file sul forum era complicato. Il materiale allegato era un video, non uno screenshot statico del forum.
La discussione pubblica sul forum non mostra alcuna nota di rilascio né una patch finale che identifichi un’unica causa principale confermata.
Non applicare alla versione attuale di ZimaOS gli interventi sui servizi della 1.4.4-beta1
La versione attuale di ZimaOS è molto più avanzata rispetto a questa beta. Il pacchettizzazione di libvirt, l’interfaccia di ZVM, il supporto alle immagini e il comportamento dei servizi systemd possono essere tutti diversi.
Per un problema simile attuale, raccogli l’errore della VM, la versione corrente di ZimaOS, lo stato di KVM, lo stato della rete e dello storage di libvirt e i log di QEMU prima di modificare i file di sistema.
Il problema è cambiato man mano che l’utente raccoglieva prove migliori
La teoria iniziale era semplicemente che la beta di ZVM avesse un bug più profondo, perché il riavvio di un servizio non aveva aiutato. Il turno successivo ha stabilito che KVM era presente e che la rete e lo storage predefiniti funzionavano correttamente. Solo dopo l’errore del socket all’interno di virtqemud diventasse visibile.
Questa progressione è un buon modello per la risoluzione dei problemi di virtualizzazione: evita di passare direttamente da un errore generico dell’interfaccia alla reinstallazione dell’hypervisor. Escludi in ordine l’accelerazione hardware, lo storage, la rete e i livelli dei servizi.
virtqemud dipende dal resto dello stack libvirt modulare
L'errore registrato faceva riferimento a un socket di rete libvirt. Nella moderna architettura modulare di libvirt, la gestione di QEMU, della rete, dei log e di altre funzioni può risiedere in demoni e socket separati. Di conseguenza, un demone QEMU può essere presente, ma non riuscire a comunicare con il demone di rete di cui ha bisogno.
Questo aiuta a spiegare perché una VM potesse non avviarsi anche se KVM e il pool di archiviazione sembravano normali.
I log di QEMU mostravano che i guest venivano terminati
I log di QEMU dell'utente mostravano ripetutamente processi guest terminati dal segnale 15 inviato da virtqemud. Ciò avvalora l'idea che i guest venissero terminati dallo stack di controllo della virtualizzazione, anziché arrestarsi a causa di un'ISO di Windows o Linux difettosa.
L'utente ha inoltre testato diverse immagini ISO e ha riscontrato lo stesso comportamento, indebolendo ulteriormente l'ipotesi di un «supporto di installazione difettoso».
Una regressione della beta va confrontata con la versione stabile prima di procedere con riparazioni distruttive
Una risposta della community suggeriva di tornare al canale stabile se era necessario usare subito le VM. È un confine diagnostico sensato per un errore limitato alla beta: se la stessa VM e lo stesso hardware funzionano nella versione stabile, la beta diventa la variabile modificata più probabile.
La discussione originale non include una conferma finale del ripristino da parte dell'autore del post, quindi questa rimane una strategia diagnostica e non una soluzione verificata dalla fonte.
Per un errore attuale di ZVM, conservare il primo errore del backend
I messaggi dell'interfaccia, come «il socket client è chiuso», spesso compaiono dopo l'evento significativo del backend. Acquisire i log di sistema e di QEMU nell'istante esatto in cui si fa clic su Avvia e conservare il primo errore, invece di considerare solo il messaggio di stato finale.
Questo riduce il rischio di scambiare un sintomo a valle per la causa principale.
FAQ storiche sulla beta di ZVM
KVM mancava nel caso originale?
No. L'utente ha confermato che i moduli KVM erano caricati.
Il ripristino della configurazione di libvirt ha risolto il problema?
No.
Il problema è stato confermato su tutti i sistemi 1.4.4-beta1?
No. Zima-Giorgio ha detto che una VM di test Ubuntu funzionava normalmente sulla stessa beta.
Qual è stato l'indizio più forte sul backend?
virtqemud registrava un errore di connessione a un socket di rete libvirt prima della disattivazione.
