Dit rapport uit september 2025 moet worden beschouwd als een historische, bèta-specifieke ZVM-fout en niet als een actuele conclusie dat “ZVM niet werkt”. De gebruiker draaide ZimaOS 1.4.4-beta1 en zag herhaaldelijk dat het starten van VM's mislukte met de interne melding client socket is closed. Zima-Giorgio testte een Ubuntu-VM op dezelfde bèta en meldde dat deze normaal draaide, dus het probleem trad niet op bij elke installatie van 1.4.4-beta1.
Het nuttige aan de thread is de diagnostische afbakening. KVM was geladen, het standaardnetwerk en de opslagpool van libvirt waren actief, en het resetten van de libvirt-configuratie hielp niet. Latere logs toonden virtqemud waarbij de verbinding met een libvirt-netwerksocket mislukte en de service vervolgens werd gedeactiveerd.
libvirt-guests opnieuw starten was niet de juiste laag
De oorspronkelijke gebruiker startte eerst opnieuw libvirt-guests.service. Een communitylid merkte op dat deze service voornamelijk het opslaan en herstellen van gastmachines rond het afsluiten van de host afhandelt; het is niet de kern-QEMU/libvirt-daemon die de VM start.
Een succesvolle herstart daarvan bewees dus niet dat de VM-stack goed functioneerde.
KVM-hardwareversnelling was beschikbaar
De gebruiker controleerde de geladen modules en ontdekte dat beide kvm en kvm_intel. Daarmee werd één veelvoorkomende oorzaak uitgesloten: dat virtualisatieondersteuning volledig niet beschikbaar was op kernelniveau.
Het standaardnetwerk en de opslagpools waren actief
In de thread werden ook het standaardnetwerk en de opslagpool van libvirt gecontroleerd. Beide werden als actief en toegankelijk gemeld.
Daardoor werd ontbrekende VM-opslag of een inactief NAT-netwerk minder waarschijnlijk als primaire oorzaak.
Een volledige reset van de libvirt-configuratie loste het probleem niet op
De oorspronkelijke poster verwijderde configuratie onder /etc/libvirt en /var/lib/libvirt en de fout nog steeds kon reproduceren. Dat was een destructieve diagnostische stap en moet niet worden aanbevolen als eerste oplossing voor huidige systemen.
Maak op een modern productiesysteem een back-up van VM-definities en schijfkopieën voordat je de libvirt-status aanpast.
De latere log verwees naar virtqemud en een netwerksocket
De gebruiker plaatste vervolgens een nuttigere foutmelding: virtqemud kan geen verbinding maken met een socket onder /var/run/libvirt/..., waarna de service werd gedeactiveerd. De melding in de UI over een gesloten clientsocket was daarom waarschijnlijk een symptoom van het onderliggende probleem met de backend-daemon.
Een daemon die „succesvol is afgesloten” kan de applicatie nog steeds laten uitvallen
Verschillende libvirt-daemons worden via sockets geactiveerd en kunnen stoppen wanneer ze niet actief zijn, dus alleen „inactief” is geen bewijs van een fout. In dit geval maakten de expliciete mislukte socketverbinding en de logs over het beëindigen van de VM de interactie met de backend echter verdacht.
Interpreteer de systemd-status samen met de daadwerkelijke libvirt/QEMU-fout, niet op basis van één statusregel op zichzelf.
IceWhale kon de fout niet reproduceren op zijn testsysteem
Zima-Giorgio zei dat een Ubuntu-VM normaal draaide op 1.4.4-beta1 en vroeg om het OS-type plus screenshots/video. Dit is een belangrijke officiële afbakening: de bron toont een echte gebruikersfout, maar geen bevestigde storing die de hele bèta trof.
De gebruiker escaleerde dit als een GitHub-bètafout
De plaatser verplaatste de gedetailleerde logs en een video naar de GitHub-tracker van IceWhale, omdat bestandsuploads op het forum lastig waren. De bijgevoegde bron was een video, geen statische forumscreenshot.
De openbare forumthread bevat geen releasenotitie of definitieve patch die één specifieke, bevestigde oorzaak aanwijst.
Pas de services niet aan zoals bij ZimaOS 1.4.4-beta1
Het huidige ZimaOS loopt ver voor op deze bèta. De libvirt-pakketten, de ZVM-UI, de image-ondersteuning en het gedrag van systemd-services kunnen allemaal verschillen.
Verzamel bij een vergelijkbare huidige fout eerst de VM-fout, de huidige ZimaOS-versie, de KVM-status, de status van het libvirt-netwerk en de libvirt-opslag, en de QEMU-logs voordat je systeembestanden wijzigt.
De fout veranderde naarmate de gebruiker beter bewijs verzamelde
De eerste theorie was simpelweg dat de ZVM-bèta een dieper probleem had, omdat het opnieuw starten van een service niet hielp. In de volgende ronde werd vastgesteld dat KVM aanwezig was en dat het standaardnetwerk en de standaardopslag goed functioneerden. Pas daarna werd de socketfout binnen virtqemud zichtbaar worden.
Deze voortgang is een goed model voor het oplossen van virtualisatieproblemen: ga niet rechtstreeks van een generieke UI-fout naar het opnieuw installeren van de hypervisor. Sluit hardwareversnelling, opslag, netwerk en services in die volgorde uit.
virtqemud is afhankelijk van de rest van de modulaire libvirt-stack
De geregistreerde fout verwees naar een libvirt-netwerksocket. In moderne modulaire libvirt kunnen QEMU-beheer, netwerkbeheer, logging en andere functies in afzonderlijke daemons en sockets draaien. Een QEMU-daemon kan dus aanwezig zijn, maar toch niet kunnen communiceren met de netwerkdaemon die deze nodig heeft.
Dit helpt verklaren waarom een VM kon mislukken, hoewel KVM en de storagepool er normaal uitzagen.
De QEMU-logboeken lieten zien dat guests werden beëindigd
In de QEMU-logboeken van de gebruiker werd herhaaldelijk vermeld dat guestprocessen werden beëindigd met signaal 15 van virtqemud. Dat ondersteunt het idee dat de guests werden afgebroken door de virtualisatiebesturingsstack, in plaats van te crashen door een defecte Windows- of Linux-ISO.
De gebruiker testte ook verschillende ISO-images en zag hetzelfde gedrag, wat de verklaring dat het installatiemedium defect was verder verzwakt.
Een bètaregressie moet eerst met de stabiele versie worden vergeleken voordat destructieve reparaties worden uitgevoerd
Een communityreactie stelde voor om terug te gaan naar het stabiele kanaal als VM's onmiddellijk nodig waren. Dat is een zinvolle diagnostische grens bij een fout die alleen in een bèta voorkomt: als dezelfde VM en hardware op de stabiele versie werken, wordt de bèta de sterkste gewijzigde variabele.
De brondiscussie bevat geen definitieve bevestiging van het terugdraaien door de oorspronkelijke poster, dus dit blijft een diagnostische strategie en geen geverifieerde oplossing uit de bron.
Bij een huidige ZVM-fout: bewaar de eerste backendfout
UI-meldingen zoals “client socket is gesloten” treden vaak op nadat de relevante backendgebeurtenis heeft plaatsgevonden. Leg systeem- en QEMU-logboeken vast op het exacte moment waarop op Start wordt geklikt en bewaar de vroegste fout in plaats van alleen de uiteindelijke statusmelding.
Dit verkleint het risico dat een symptoom aan de downstreamkant wordt beschouwd als de hoofdoorzaak.
Historische ZVM-bèta-FAQ
Ontbrak KVM in het oorspronkelijke geval?
Nee. De gebruiker bevestigde dat de KVM-modules waren geladen.
Lostte het resetten van de libvirt-configuratie het probleem op?
Nee.
Kwam het probleem voor op elk 1.4.4-beta1-systeem?
Nee. Zima-Giorgio zei dat een Ubuntu-test-VM op dezelfde bèta normaal draaide.
Wat was de sterkste aanwijzing in de backend?
virtqemud registreerde een fout bij het verbinden met een libvirt-netwerksocket voordat deze werd gedeactiveerd.
