I’m experiencing a persistent issue with the ZVM (Virtual Machine) feature on my ZimaCube running ZimaOS v1.4.4-beta1. The VMs fail to start or operate correctly.
I have already attempted basic troubleshooting steps without success. I tried to restart the libvirt service via the terminal, and while the command executed without error, the problem remains. This suggests it’s not a temporary issue but a bug within the beta software itself.
Here is the key information I’ve gathered from the system:
Operating System: ZimaOS v1.4.4-beta1
Problem: VMs are not starting or are failing to run correctly.
Troubleshooting Steps Taken:
Successfully restarted the libvirt-guests.service via sudo systemctl restart libvirt-guests.service.
Confirmed the opkg package manager is not available on this version.
Findings: The service appears to be running, but the issue persists, which points to a deeper bug in the ZVM application or its dependencies.
I’m hoping to get some guidance or confirmation if this is a known issue. Any help would be greatly appreciated.
I’m on 1.4.4-beta1 as well. A quick note: restarting libvirt-guests won’t fix a broken VM stack—that unit just handles saving/restoring guests on shutdown. The main bits to sanity-check are below; none of these are destructive.
Make sure the right services are actually up
systemctl status libvirtd virtqemud virtnetworkd virtlogd
If any are inactive/failed, start them: systemctl start
Confirm KVM is available
lsmod | grep -E ‘kvm|kvm_intel’ and dmesg | grep -i kvm
If you see “failed to initialize kvm” or permission errors, that’s the root cause.
Check libvirt’s default network
virsh net-list --all
You want default to be active and autostart. If not:
virsh net-start default && virsh net-autostart default
Check the storage pool
virsh pool-list --all
Make sure the pool ZVM is using is active and points to a real, writable path (on my box it’s under /DATA/…). If it’s inactive:
virsh pool-start default && virsh pool-autostart default
Look at the actual VM error logs
While you click “Start” in ZVM, tail these:
journalctl -u libvirtd -f and tail -f /var/log/libvirt/qemu/*.log
Post any lines that mention kvm, permission denied, cannot access file, or network not found.
If you need VMs working immediately, rolling back to the stable channel has helped some folks while the beta gets patched. But if you can share the outputs from #1–#5, we can pinpoint whether it’s a network, storage, or KVM init issue and hand the devs a clean repro. Happy to compare notes against my setup, too.
I am the user who created this issue. Following the suggestion to try different troubleshooting steps, I have performed a series of tests to diagnose the problem, and the issue still persists.
The “internal error: client socket is closed” that appears in the UI seems to be a symptom of a deeper problem: the libvirtd.service is not staying active after being started.
Here is a summary of the steps I have taken and the key findings:
Service Status: The libvirtd service starts but then immediately deactivates. The logs show: libvirtd.service: Deactivated successfully. This happens consistently.
Hardware Check (KVM): I have confirmed that KVM is available and correctly loaded on the system. lsmod shows kvm and kvm_intel modules are present.
Network and Storage: I have verified that the default network and storage pools are both active and accessible.
Full Reset: I have tried a full reset of the ZVM configuration, deleting all related files in /etc/libvirt/ and /var/lib/libvirt/, but the problem remains.
Video of the Issue: I have attached a video of the issue as requested, showing how the VM creation process fails immediately.
The persistent nature of this error, even after a full configuration reset, suggests a fundamental bug in ZimaOS v1.4.4-beta1. The logs do not provide a clear reason for the service deactivation, which makes it difficult to diagnose further.
I have used several different .iso images, and the result is the same. I’m hoping you can use this information to pinpoint the root cause.
It won’t let me upload files here, so I’m uploading everything to GitHub using the link I sent you.
I have new log information that points to the root cause of the issue.
The libvirtd job is being canceled because the virtqemud service starts but fails to connect to a network socket, causing it to immediately deactivate. This seems to be the underlying reason for the “client socket is closed” error.
Here is the key log entry: Sep 03 20:28:10 FsocietyOS virtqemud[1133791]: Failed to connect socket to '/var/run/libvirt/virtnetwo
I have tried a full configuration reset, and the issue persists. This confirms that it’s a bug that needs to be fixed in a future update.
virtqemud:** Failed to connect socket to /var/run/libvirt/virtnetworkd-sock
On libvirt 10.x the daemons are split. The UI’s “client socket is closed” usually means virtqemud can’t talk to virtnetworkd (network daemon) because its socket isn’t up, or /var/run/libvirt wasn’t created with the right perms.
For Proxmox, I used a stable ZimaOS build (generic x86-64 image) and it’s been rock-solid. On bare metal, the only installer that actually launched the graphical setup was the slim ISO: zimaos_zimacube-1.4.2-beta1_installer_slim.iso.
And one question, is there any way to fix this? Because if I reimage, will I lose all my data and have to re-upload both the data and the application? I’m looking for another way because the only thing giving me trouble in the beta is ZVM alone, and I can tell you that I already had it configured correctly.
I understand. Actually, we don’t recommend accessing the CLI and modifying critical configurations as root unless directed by our engineer in detail. I don’t know what configuration changes you might have made, and whether they’re still valid. I can suggest copying the relevant configuration files from another machine. Alternatively, you can use the system reset feature provided in 1.4.4. A system reset won’t lose user files, but personalized settings will need to be reconfigured.
The reset function can be located at Settings → General.
Hello, I finally updated it and then reset everything and it seems to be working fine. I’m sorry for causing you so much inconvenience and thank you very much.