Den här rapporten från september 2025 bör betraktas som ett historiskt, betaspecifikt ZVM-fel, inte som en aktuell slutsats att ”ZVM inte fungerar”. Användaren körde ZimaOS 1.4.4-beta1 och såg upprepade gånger att VM-starten misslyckades med det interna meddelandet client socket is closed. Zima-Giorgio testade en Ubuntu-VM på samma betaversion och uppgav att den kördes normalt, så problemet var inte universellt för alla installationer av 1.4.4-beta1.
Det användbara i tråden är den diagnostiska avgränsningen. KVM var inläst, libvirts standardnätverk och lagringspool var aktiva, och en återställning av libvirt-konfigurationen hjälpte inte. Senare loggar visade virtqemud som inte kunde ansluta till ett libvirt-nätverksuttag och sedan inaktiverades.
Att starta om libvirt-guests var inte rätt nivå
Den ursprungliga användaren startade först om libvirt-guests.service. En person i communityn påpekade att den här tjänsten främst hanterar sparande och återställning av gäster vid avstängning av värddatorn; det är inte den centrala QEMU-/libvirt-demonen som startar den virtuella maskinen.
En lyckad omstart där bevisade därför inte att VM-stacken var felfri.
KVM-maskinvaruacceleration var tillgänglig
Användaren kontrollerade inlästa moduler och hittade båda kvm och kvm_intel. Det uteslöt en vanlig orsak: att virtualiseringsstödet helt saknades på kärnnivå.
Standardnätverket och lagringspoolerna var aktiva
Tråden kontrollerade också libvirts standardnätverk och lagringspool. Båda rapporterades vara aktiva och åtkomliga.
Det gjorde saknad VM-lagring eller ett inaktivt NAT-nätverk mindre sannolikt som den primära orsaken.
En fullständig återställning av libvirt-konfigurationen löste inte problemet
Den ursprungliga skribenten raderade konfiguration under /etc/libvirt och /var/lib/libvirt och återskapade fortfarande felet. Det var ett destruktivt diagnostiksteg och bör inte rekommenderas som den första åtgärden i dag.
På ett modernt produktionssystem bör du säkerhetskopiera VM-definitioner och diskavbildningar innan du ändrar libvirt-tillståndet.
Den senare loggen pekade på virtqemud och ett nätverksuttag
Användaren publicerade sedan ett mer användbart felmeddelande: virtqemud kunde inte ansluta till ett uttag under /var/run/libvirt/..., varefter tjänsten avaktiverades. Användargränssnittets meddelande om att klientsocketen stängts var därför sannolikt ett följdsymptom av problemet med backend-daemonen.
En daemon som visar ”avslutades utan fel” kan fortfarande få programmet att sluta fungera
Flera libvirt-daemoner aktiveras via sockets och kan stoppas när de är inaktiva, så ”inaktiv” är i sig inget bevis på ett fel. I det här fallet gjorde dock den uttryckliga misslyckade socketanslutningen tillsammans med loggarna över VM-avslutningen backend-interaktionen misstänkt.
Tolka systemd-status tillsammans med det faktiska libvirt/QEMU-felet, inte utifrån en enda statusrad isolerat.
IceWhale kunde inte återskapa felet i sin testmiljö
Zima-Giorgio uppgav att en Ubuntu-VM kördes normalt på 1.4.4-beta1 och bad om operativsystemstyp samt skärmbilder/video. Detta är en viktig officiell avgränsning: källan visar ett verkligt användarfel, men inte ett bekräftat avbrott som drabbade hela betaversionen.
Användaren eskalerade det som ett GitHub-fel i betaversionen
Användaren flyttade de detaljerade loggarna och en video till IceWhales GitHub-ärendehanterare eftersom det var svårt att ladda upp filer i forumet. Den bifogade källan var en video, inte en statisk skärmbild från forumet.
Den offentliga forumtråden innehåller ingen versionsanteckning eller slutgiltig korrigering som identifierar en enda bekräftad grundorsak.
Tillämpa inte tjänsteingreppen för 1.4.4-beta1 på aktuell ZimaOS
Den aktuella ZimaOS-versionen ligger långt bortom denna betaversion. Libvirt-paketering, ZVM-användargränssnittet, stöd för avbildningar och systemd-tjänsternas beteende kan alla skilja sig åt.
Vid ett liknande aktuellt fel bör du samla in VM-felet, den aktuella ZimaOS-versionen, KVM-status, libvirt-nätverkets och lagringens status samt QEMU-loggar innan du ändrar systemfiler.
Felet förändrades när användaren samlade in bättre bevis
Den ursprungliga teorin var helt enkelt att ZVM-betaversionen hade ett djupare fel eftersom det inte hjälpte att starta om en tjänst. Nästa omgång fastställde att KVM fanns och att standardnätverket och standardlagringen fungerade korrekt. Först därefter blev socketfelet inuti virtqemud bli synligt.
Den här utvecklingen är en bra modell för felsökning av virtualisering: undvik att gå direkt från ett generiskt användargränssnittsfel till att installera om hypervisorn. Uteslut lager för hårdvaruacceleration, lagring, nätverk och tjänster i tur och ordning.
virtqemud är beroende av resten av den modulära libvirt-stacken
Det loggade felet hänvisade till ett libvirt-nätverksuttag. I moderna modulära libvirt kan QEMU-hantering, nätverkshantering, loggning och andra funktioner köras i separata daemoner och via separata uttag. En QEMU-daemon kan därför finnas på plats men ändå inte kunna kommunicera med den nätverksdaemon den behöver.
Detta hjälper till att förklara varför en virtuell maskin kunde misslyckas trots att KVM och lagringspoolen verkade fungera normalt.
QEMU-loggarna visade att gäster avslutades
Användarens QEMU-loggar visade upprepade gånger att gästprocesser avslutades med signal 15 från virtqemud. Det stöder idén att gästerna stängdes ned av virtualiseringsstyrningen, snarare än kraschade på grund av en felaktig Windows- eller Linux-ISO.
Användaren testade också flera ISO-avbildningar och såg samma beteende, vilket ytterligare försvagar förklaringen ”felaktigt installationsmedium”.
En betaregression bör jämföras med den stabila versionen innan destruktiv reparation
Ett svar från communityn föreslog att man skulle återgå till den stabila kanalen om virtuella maskiner behövdes omedelbart. Det är en rimlig diagnostisk avgränsning för ett betabundet fel: om samma virtuella maskin och maskinvara fungerar i den stabila versionen blir betaversionen den starkaste förändrade variabeln.
Källtråden innehåller ingen slutlig bekräftelse på återställning från det ursprungliga inläggets författare, så detta förblir en diagnostisk strategi snarare än en verifierad lösning från källan.
Vid ett aktuellt ZVM-fel: bevara det första backend-felet
UI-meddelanden som ”klientuttaget är stängt” inträffar ofta efter den betydelsefulla backend-händelsen. Samla in system- och QEMU-loggar exakt när Start klickas och bevara det tidigaste felet i stället för enbart det slutliga statusmeddelandet.
Det minskar risken för att behandla ett följdsymptom som grundorsaken.
Historiska vanliga frågor om ZVM Beta
Saknades KVM i källfallet?
Nej. Användaren bekräftade att KVM-modulerna var inlästa.
Löste en återställning av libvirt-konfigurationen problemet?
Nej.
Var problemet bekräftat på alla system med 1.4.4-beta1?
Nej. Zima-Giorgio sa att en Ubuntu-test-VM kördes normalt på samma betaversion.
Vilken var den starkaste ledtråden från backend?
virtqemud loggade ett anslutningsfel till ett libvirt-nätverksuttag innan inaktivering.
