Dieser Bericht vom September 2025 sollte als historischer, beta-spezifischer ZVM-Fehler betrachtet werden, nicht als aktuelle Schlussfolgerung „ZVM funktioniert nicht“. Der Benutzer verwendete ZimaOS 1.4.4-beta1 und stellte wiederholt fest, dass der VM-Start mit der internen Meldung Client-Socket ist geschlossen fehlschlug. Zima-Giorgio testete auf derselben Beta ein Ubuntu-VM und teilte mit, dass es normal lief. Das Problem trat daher nicht bei jeder Installation von 1.4.4-beta1 auf.
Der nützliche Teil des Threads ist die diagnostische Eingrenzung. KVM war geladen, das libvirt-Standardnetzwerk und der Speicherpool waren aktiv, und das Zurücksetzen der libvirt-Konfiguration half nicht. Spätere Protokolle zeigten virtqemud konnte keine Verbindung zu einem libvirt-Netzwerk-Socket herstellen und wurde anschließend deaktiviert.
Der Neustart von libvirt-guests war nicht die richtige Ebene
Der ursprüngliche Benutzer startete zunächst libvirt-guests.service. Ein Community-Antwortender wies darauf hin, dass dieser Dienst hauptsächlich das Speichern und Wiederherstellen von Gastsystemen beim Herunterfahren des Hosts übernimmt; er ist nicht der zentrale QEMU/libvirt-Daemon, der die VM startet.
Ein erfolgreicher Neustart bewies daher nicht, dass der VM-Stack ordnungsgemäß funktionierte.
KVM-Hardwarebeschleunigung war vorhanden
Der Benutzer überprüfte die geladenen Module und stellte fest, dass beide kvm und kvm_intel. Damit war eine häufige Ursache ausgeschlossen: dass Virtualisierungsunterstützung auf Kernel-Ebene vollständig nicht verfügbar ist.
Standardnetzwerk und Speicherpools waren aktiv
Im Thread wurden außerdem das Standardnetzwerk und der Speicherpool von libvirt überprüft. Beide wurden als aktiv und zugänglich gemeldet.
Dadurch wurde fehlender VM-Speicher oder ein inaktives NAT-Netzwerk als primäre Ursache unwahrscheinlicher.
Ein vollständiges Zurücksetzen der libvirt-Konfiguration behob das Problem nicht
Der ursprüngliche Verfasser löschte Konfigurationen unter /etc/libvirt und /var/lib/libvirt und reproduzierte den Fehler weiterhin. Das war ein destruktiver Diagnoseschritt und sollte nicht als aktuelle Erstmaßnahme empfohlen werden.
Sichern Sie auf einem modernen Produktivsystem VM-Definitionen und Festplatten-Images, bevor Sie den libvirt-Zustand ändern.
Das spätere Protokoll verwies auf virtqemud und einen Netzwerk-Socket
Der Benutzer veröffentlichte daraufhin einen aussagekräftigeren Fehler: virtqemud konnte keine Verbindung zu einem Socket herstellen unter /var/run/libvirt/..., woraufhin der Dienst deaktiviert wurde. Die Meldung der Benutzeroberfläche über einen geschlossenen Client-Socket war daher wahrscheinlich ein nachgelagertes Symptom des Backend-Daemon-Problems.
Ein Daemon mit dem Status „erfolgreich beendet“ kann die Anwendung trotzdem beeinträchtigen
Mehrere libvirt-Daemons werden per Socket aktiviert und können im Leerlauf beendet werden; allein „inactive“ ist daher kein Beweis für einen Fehler. In diesem Fall machten jedoch die ausdrücklich fehlgeschlagene Socket-Verbindung und die Protokolle zur VM-Beendigung die Backend-Interaktion verdächtig.
Interpretieren Sie den systemd-Status zusammen mit dem tatsächlichen libvirt-/QEMU-Fehler, nicht isoliert anhand einer einzelnen Statuszeile.
IceWhale konnte den Fehler in seiner Testumgebung nicht reproduzieren
Zima-Giorgio sagte, dass eine Ubuntu-VM unter 1.4.4-beta1 normal lief, und bat um den Betriebssystemtyp sowie Screenshots/Videos. Dies ist eine wichtige offizielle Einordnung: Die Quelle zeigt einen tatsächlichen Benutzerfehler, aber keinen für die gesamte Beta bestätigten Ausfall.
Der Benutzer eskalierte das Problem als GitHub-Beta-Fehler
Der Verfasser verschob die ausführlichen Protokolle und ein Video in den GitHub-Tracker von IceWhale, weil das Hochladen von Dateien im Forum schwierig war. Die beigefügte Quelle war ein Video, kein statischer Forumscreenshot.
Der öffentliche Foren-Thread enthält weder einen Versionshinweis noch einen endgültigen Patch, der eine einzelne, bestätigte Grundursache benennt.
Wenden Sie die Dienständerungen aus Version 1.4.4-beta1 nicht auf das aktuelle ZimaOS an
Das aktuelle ZimaOS ist dieser Beta weit voraus. Die libvirt-Paketierung, die ZVM-Oberfläche, die Image-Unterstützung und das Verhalten der systemd-Dienste können sich allesamt unterscheiden.
Bei einem ähnlichen aktuellen Fehler sollten Sie den VM-Fehler, die aktuelle ZimaOS-Version, den KVM-Status, den libvirt-Netzwerk- und Speicherstatus sowie die QEMU-Protokolle erfassen, bevor Sie Systemdateien ändern.
Der Fehler änderte sich, als der Benutzer bessere Belege sammelte
Die ursprüngliche Theorie war schlicht, dass die ZVM-Beta einen tiefer liegenden Fehler enthielt, weil ein Neustart des Dienstes nicht half. Die nächste Runde ergab, dass KVM vorhanden und das Standardnetzwerk sowie der Standardspeicher intakt waren. Erst danach wurde der Socket-Fehler innerhalb von virtqemud sichtbar werden.
Diese Entwicklung ist ein gutes Modell für die Fehlersuche bei der Virtualisierung: Vermeiden Sie es, von einem allgemeinen UI-Fehler direkt zur Neuinstallation des Hypervisors überzugehen. Schließen Sie Hardwarebeschleunigung, Speicher, Netzwerk und Dienste der Reihe nach als Fehlerquellen aus.
virtqemud hängt vom restlichen modularen libvirt-Stack ab
Der protokollierte Fehler bezog sich auf einen libvirt-Netzwerk-Socket. In modernem modularem libvirt können sich die QEMU-Verwaltung, die Netzwerkverwaltung, die Protokollierung und andere Funktionen in separaten Daemons und Sockets befinden. Daher kann ein QEMU-Daemon vorhanden sein, während die Kommunikation mit dem benötigten Netzwerk-Daemon fehlschlägt.
Das hilft zu erklären, warum eine VM fehlschlagen konnte, obwohl KVM und der Speicherpool normal aussahen.
Die QEMU-Protokolle zeigten, dass Gäste beendet wurden
In den QEMU-Protokollen des Benutzers wurde wiederholt angezeigt, dass Gastprozesse durch Signal 15 von virtqemud. Das stützt die Annahme, dass die Gäste vom Virtualisierungs-Kontrollstack beendet wurden, statt aufgrund eines fehlerhaften Windows- oder Linux-ISO-Images abzustürzen.
Der Benutzer testete außerdem mehrere ISO-Images und beobachtete dasselbe Verhalten, wodurch die Erklärung „fehlerhaftes Installationsmedium“ weiter an Plausibilität verlor.
Eine Regression in der Beta sollte vor einer destruktiven Reparatur mit der stabilen Version verglichen werden
Eine Antwort aus der Community schlug vor, bei unmittelbar benötigten VMs auf den stabilen Kanal zurückzuwechseln. Das ist eine sinnvolle diagnostische Abgrenzung bei einem ausschließlich in der Beta auftretenden Fehler: Wenn dieselbe VM auf derselben Hardware im stabilen Release funktioniert, ist die Beta die wahrscheinlichste geänderte Variable.
Der Quell-Thread enthält keine abschließende Bestätigung des ursprünglichen Verfassers, dass ein Rollback erfolgreich war. Daher bleibt dies eine Diagnosestrategie und keine verifizierte Lösung aus der Quelle.
Bei einem aktuellen ZVM-Fehler den ersten Backend-Fehler bewahren
UI-Meldungen wie „Client-Socket ist geschlossen“ treten häufig nach dem eigentlichen Backend-Ereignis auf. Erfassen Sie die System- und QEMU-Protokolle genau in dem Moment, in dem auf „Start“ geklickt wird, und bewahren Sie den frühesten Fehler auf, statt nur die abschließende Statusmeldung zu berücksichtigen.
Dadurch sinkt das Risiko, ein nachgelagertes Symptom als Grundursache zu behandeln.
Historische ZVM-Beta-FAQ
Fehlte KVM im Ausgangsfall?
Nein. Der Benutzer bestätigte, dass die KVM-Module geladen waren.
Wurde das Problem durch das Zurücksetzen der libvirt-Konfiguration behoben?
Nein.
Trat das Problem auf jedem System mit 1.4.4-beta1 auf?
Nein. Zima-Giorgio sagte, dass eine Ubuntu-Test-VM auf derselben Beta normal lief.
Was war der stärkste Hinweis auf das Backend?
virtqemud vor der Deaktivierung einen Fehler beim Verbinden mit einem libvirt-Netzwerk-Socket protokolliert
