This September 2025 report should be treated as a historical beta-specific ZVM failure, not a current “ZVM does not work” conclusion. The user was running ZimaOS 1.4.4-beta1 and repeatedly saw VM startup fail with an internal client socket is closed message. Zima-Giorgio tested an Ubuntu VM on the same beta and said it ran normally, so the problem was not universal across every 1.4.4-beta1 installation.
The useful part of the thread is the diagnostic narrowing. KVM was loaded, the default libvirt network and storage pool were active, and resetting libvirt configuration did not help. Later logs showed virtqemud failing to connect to a libvirt network socket and then deactivating.
Restarting libvirt-guests Was Not the Right Layer
The original user first restarted libvirt-guests.service. A community responder pointed out that this service mainly handles guest save/restore behavior around host shutdown; it is not the core QEMU/libvirt daemon that launches the VM.
A successful restart there therefore did not prove the VM stack was healthy.
KVM Hardware Acceleration Was Present
The user checked loaded modules and found both kvm and kvm_intel. That ruled out one common cause: virtualization support being completely unavailable at the kernel level.
Default Network and Storage Pools Were Active
The thread also checked libvirt's default network and storage pool. Both were reported active and accessible.
That made missing VM storage or an inactive NAT network less likely as the primary cause.
A Full libvirt Configuration Reset Did Not Fix It
The original poster deleted configuration under /etc/libvirt and /var/lib/libvirt and still reproduced the failure. That was a destructive diagnostic step and should not be promoted as a current first-line fix.
On a modern production system, back up VM definitions and disk images before touching libvirt state.
The Later Log Pointed to virtqemud and a Network Socket
The user then posted a more useful error: virtqemud failed to connect to a socket under /var/run/libvirt/..., after which the service deactivated. The UI's closed-client-socket message was therefore likely a downstream symptom of the backend daemon problem.
A Daemon Showing “Exited Successfully” Can Still Break the Application
Several libvirt daemons are socket-activated and can stop when idle, so “inactive” alone is not proof of a failure. In this case, however, the explicit failed socket connection plus VM termination logs made the backend interaction suspicious.
Interpret systemd state together with the actual libvirt/QEMU error, not from one status line in isolation.
IceWhale Could Not Reproduce the Failure on Its Test
Zima-Giorgio said an Ubuntu VM ran normally on 1.4.4-beta1 and asked for OS type plus screenshots/video. This is an important official boundary: the source shows a real user failure, but not a beta-wide confirmed outage.
The User Escalated It as a GitHub Beta Bug
The poster moved the detailed logs and a video to IceWhale's GitHub tracker because file uploads in the forum were difficult. The attached source was a video, not a static forum screenshot.
The public forum thread does not show a release note or final patch identifying a single confirmed root cause.
Do Not Apply 1.4.4-beta1 Service Surgery to Current ZimaOS
Current ZimaOS is far beyond this beta. libvirt packaging, ZVM UI, image support, and systemd service behavior can all differ.
For a similar current failure, collect the VM error, current ZimaOS version, KVM status, libvirt network/storage state, and QEMU logs before changing system files.
The Failure Changed as the User Collected Better Evidence
The initial theory was simply that the ZVM beta had a deeper bug because restarting a service did not help. The next round established that KVM existed and the default network/storage were healthy. Only after that did the socket error inside virtqemud become visible.
This progression is a good model for virtualization troubleshooting: avoid jumping from a generic UI error directly to reinstalling the hypervisor. Eliminate hardware acceleration, storage, network, and service layers in order.
virtqemud Depends on the Rest of the Modular libvirt Stack
The logged failure referenced a libvirt network socket. In modern modular libvirt, QEMU management, network management, logging, and other functions can live in separate daemons and sockets. A QEMU daemon can therefore be present while failing to communicate with the network daemon it needs.
This helps explain why a VM could fail even though KVM and the storage pool looked normal.
The QEMU Logs Showed Guests Being Terminated
The user's QEMU logs repeatedly showed guest processes terminating on signal 15 from virtqemud. That supports the idea that the guests were being torn down by the virtualization control stack rather than crashing because of a bad Windows or Linux ISO.
The user also tested several ISO images and saw the same behavior, further weakening the “bad installer media” explanation.
A Beta Regression Should Be Compared with Stable Before Destructive Repair
A community reply suggested rolling back to the stable channel if VMs were needed immediately. That is a sensible diagnostic boundary for a beta-only failure: if the same VM and hardware work on stable, the beta becomes the strongest changed variable.
The source thread does not include a final rollback confirmation from the original poster, so this remains a diagnostic strategy rather than a verified source fix.
For a Current ZVM Failure, Preserve the First Backend Error
UI messages such as “client socket is closed” often occur after the meaningful backend event. Capture system and QEMU logs at the exact moment Start is clicked and preserve the earliest error rather than only the final status message.
This reduces the risk of treating a downstream symptom as the root cause.
Historical ZVM Beta FAQ
Was KVM missing in the source case?
No. The user confirmed KVM modules were loaded.
Did resetting libvirt configuration solve it?
No.
Was the problem confirmed on every 1.4.4-beta1 system?
No. Zima-Giorgio said an Ubuntu test VM ran normally on the same beta.
What was the strongest backend clue?
virtqemud logged a failure connecting to a libvirt network socket before deactivating.
