Ce rapport de septembre 2025 doit être considéré comme un échec historique propre à la version bêta de ZVM, et non comme la conclusion actuelle selon laquelle « ZVM ne fonctionne pas ». L’utilisateur exécutait ZimaOS 1.4.4-beta1 et observait à plusieurs reprises l’échec du démarrage de la VM avec le message interne client socket is closed. Zima-Giorgio a testé une VM Ubuntu sur la même version bêta et a indiqué qu’elle fonctionnait normalement ; le problème n’était donc pas universel à toutes les installations de la version 1.4.4-beta1.
La partie utile de la discussion est le rétrécissement progressif du diagnostic. KVM était chargé, le réseau libvirt par défaut et le pool de stockage étaient actifs, et la réinitialisation de la configuration de libvirt n’a rien changé. Des journaux ultérieurs ont montré virtqemud échouant à se connecter à un socket réseau de libvirt, puis se désactivant.
Redémarrer libvirt-guests n’était pas le bon niveau
L’utilisateur d’origine a d’abord redémarré libvirt-guests.service. Un intervenant de la communauté a souligné que ce service gère principalement la sauvegarde et la restauration des invités lors de l’arrêt de l’hôte ; ce n’est pas le démon QEMU/libvirt principal qui lance la VM.
Un redémarrage réussi à cet endroit ne prouvait donc pas que la pile de VM fonctionnait correctement.
L’accélération matérielle KVM était disponible
L’utilisateur a vérifié les modules chargés et a constaté que les deux kvm et kvm_intel. Cela écartait une cause courante : l’absence totale de la prise en charge de la virtualisation au niveau du noyau.
Le réseau par défaut et les pools de stockage étaient actifs
La discussion a également vérifié le réseau par défaut et le pool de stockage de libvirt. Tous deux étaient signalés comme actifs et accessibles.
Cela rendait moins probable que le stockage des VM soit manquant ou que le réseau NAT soit inactif comme cause principale.
Une réinitialisation complète de la configuration de libvirt n’a pas résolu le problème
L’auteur du message original a supprimé la configuration sous /etc/libvirt et /var/lib/libvirt et a toujours reproduit l’échec. Il s’agissait d’une étape de diagnostic destructive qui ne devrait pas être recommandée comme première solution actuelle.
Sur un système de production moderne, sauvegardez les définitions des VM et les images disque avant de modifier l’état de libvirt.
Les journaux ultérieurs ont indiqué virtqemud et un socket réseau
L’utilisateur a ensuite publié une erreur plus utile : virtqemud échec de connexion à un socket sous /var/run/libvirt/..., après quoi le service a été désactivé. Le message de l’interface indiquant que le socket client était fermé était donc vraisemblablement un symptôme en aval du problème affectant le démon backend.
Un démon affichant « quitté normalement » peut tout de même interrompre le fonctionnement de l’application
Plusieurs démons libvirt sont activés par socket et peuvent s’arrêter lorsqu’ils sont inactifs ; le seul état « inactif » ne prouve donc pas une défaillance. Dans ce cas, toutefois, l’échec explicite de la connexion au socket, associé aux journaux de terminaison de la VM, rendait suspecte l’interaction avec le backend.
Interprétez l’état de systemd conjointement avec l’erreur réelle de libvirt/QEMU, et non à partir d’une seule ligne d’état prise isolément.
IceWhale n’a pas pu reproduire l’échec sur son environnement de test
Zima-Giorgio a indiqué qu’une VM Ubuntu fonctionnait normalement avec la version 1.4.4-beta1 et a demandé le type de système d’exploitation ainsi que des captures d’écran ou une vidéo. Il s’agit d’une limite officielle importante : la source montre un problème réel rencontré par un utilisateur, mais pas une panne confirmée touchant toute la version bêta.
L’utilisateur a signalé le problème comme un bogue de la version bêta sur GitHub
L’auteur a déplacé les journaux détaillés et une vidéo vers le gestionnaire de tickets GitHub d’IceWhale, car il était difficile de téléverser des fichiers sur le forum. La pièce jointe était une vidéo, et non une capture d’écran statique du forum.
Le fil de discussion public du forum ne contient aucune note de version ni correctif final identifiant une cause racine unique et confirmée.
N’appliquez pas les manipulations des services de la version 1.4.4-beta1 à la version actuelle de ZimaOS
La version actuelle de ZimaOS est très différente de cette version bêta. Le paquetage libvirt, l’interface ZVM, la prise en charge des images et le comportement des services systemd peuvent tous différer.
Pour un échec similaire aujourd’hui, recueillez l’erreur de la VM, la version actuelle de ZimaOS, l’état de KVM, l’état du réseau et du stockage libvirt, ainsi que les journaux de QEMU avant de modifier les fichiers système.
L’échec a évolué à mesure que l’utilisateur recueillait de meilleures preuves
La théorie initiale était simplement que la version bêta de ZVM comportait un bogue plus profond, puisqu’un redémarrage du service n’avait rien résolu. La série de vérifications suivante a établi que KVM était bien disponible et que le réseau et le stockage par défaut fonctionnaient correctement. Ce n’est qu’ensuite que l’erreur de socket à l’intérieur virtqemud devenir visible.
Cette progression constitue un bon modèle pour le dépannage de la virtualisation : évitez de passer directement d’une erreur générique de l’interface à la réinstallation de l’hyperviseur. Éliminez successivement les couches d’accélération matérielle, de stockage, de réseau et de services.
virtqemud dépend du reste de la pile libvirt modulaire
L’échec enregistré faisait référence à un socket réseau libvirt. Dans libvirt modulaire moderne, la gestion de QEMU, la gestion du réseau, la journalisation et d’autres fonctions peuvent résider dans des démons et des sockets distincts. Un démon QEMU peut donc être présent tout en ne parvenant pas à communiquer avec le démon réseau dont il a besoin.
Cela explique pourquoi une VM pouvait échouer même si KVM et le pool de stockage semblaient fonctionner normalement.
Les journaux QEMU montraient que les invités étaient terminés
Les journaux QEMU de l’utilisateur montraient à plusieurs reprises que les processus invités se terminaient sur le signal 15 de virtqemud. Cela étaye l’idée que les invités étaient arrêtés par la pile de contrôle de la virtualisation plutôt qu’en raison d’un plantage causé par une mauvaise image ISO Windows ou Linux.
L’utilisateur a également testé plusieurs images ISO et a constaté le même comportement, ce qui affaiblit encore l’hypothèse d’un « support d’installation défectueux ».
Une régression de la bêta doit être comparée à la version stable avant toute réparation destructive
Une réponse de la communauté a suggéré de revenir au canal stable si des VM étaient nécessaires immédiatement. Il s’agit d’une limite de diagnostic pertinente pour une défaillance propre à la bêta : si la même VM et le même matériel fonctionnent sur la version stable, la bêta devient la variable modifiée la plus probante.
Le fil source n’inclut pas de confirmation finale de restauration de la part de l’auteur initial ; il s’agit donc toujours d’une stratégie de diagnostic plutôt que d’une solution vérifiée dans la source.
Pour une défaillance actuelle de ZVM, conservez la première erreur du backend
Les messages de l’interface tels que « le socket client est fermé » apparaissent souvent après l’événement backend significatif. Capturez les journaux du système et de QEMU au moment exact où vous cliquez sur Démarrer et conservez la première erreur plutôt que le seul message d’état final.
Cela réduit le risque de prendre un symptôme en aval pour la cause racine.
FAQ historique sur la bêta de ZVM
KVM était-il absent dans le cas source ?
Non. L’utilisateur a confirmé que les modules KVM étaient chargés.
La réinitialisation de la configuration libvirt a-t-elle résolu le problème ?
Non.
Le problème a-t-il été confirmé sur tous les systèmes équipés de la version 1.4.4-beta1 ?
Non. Zima-Giorgio a indiqué qu’une VM de test Ubuntu fonctionnait normalement sur la même version bêta.
Quel était l’indice le plus probant concernant le backend ?
virtqemud a signalé un échec de connexion à un socket réseau libvirt avant la désactivation.
