This thread is a useful record of how ZVM users defined the virtualization features they wanted most. IceWhale opened the discussion in May 2024 while a voting campaign was underway. Early attention centered on more disk-image formats, easier image access, importing instances from other virtualization platforms, and LXC support. Over the next year, the requests became more concrete: QCOW2 and appliance images, PCI/GPU passthrough, VM autostart, advanced QEMU controls, storage resizing, audio passthrough, and better error reporting.
The source should be read as a product-feedback history, not as a current feature checklist. A request appearing in this thread does not prove the feature is absent today, and an IceWhale reply saying “we will discuss it” is not a release commitment.
QCOW2, VDI, OVA, and Prebuilt Appliances Were an Early Priority
Multiple users wanted to boot prebuilt virtual appliances without converting them to ISO installers. Home Assistant OS was repeatedly cited because it distributes VM images rather than a conventional installation ISO.
This is a different requirement from “mount an ISO.” A preinstalled disk image already contains an operating system and should be attached as the VM's boot disk.
Home Assistant OS Made the Image-Import Gap Concrete
Several replies specifically asked to run HAOS in ZVM. Later community results on newer ZVM versions confirmed that HAOS can be run as a VM, showing why a 2024 limitation should not be described as a permanent current state.
PCI and GPU Passthrough Became a Major 2025 Request
Users with gaming-class hardware wanted Windows or SteamOS guests to use a real GPU. One participant with an RTX 2070 said both Windows 11 and a planned SteamOS guest were sluggish because the guest appeared to rely on software graphics.
PCI passthrough requires IOMMU/VFIO support and safe device isolation. It is fundamentally different from emulated or paravirtualized display output.
VM Autostart Was Another Practical Server Requirement
A Debian-server VM user asked for a per-VM autostart switch so infrastructure guests would come back after a ZimaOS reboot. IceWhale acknowledged the feedback and said the team would discuss it.
For an always-on home server, startup order and reboot recovery often matter more than graphical VM creation.
Advanced Users Wanted Direct QEMU/libvirt Control
Another user asked for access to custom QEMU commands and Cockpit Machines. Their goals included audio passthrough experiments, higher display resolutions, and easier storage-pool resizing.
Zima-Giorgio asked what privileges were actually needed and then said the team would discuss the use cases. The source does not show an official promise to expose arbitrary QEMU command-line flags in the ZVM UI.
Later Screenshots Showed VM Boot and Configuration Friction
Users Also Asked for Better Download and Error Feedback
In October 2025, a new user said the built-in Debian ISO download link failed while a manually found Debian URL worked. They specifically asked ZVM to show which URL had failed rather than only presenting a generic error.
This is a usability issue separate from the hypervisor itself: troubleshooting becomes much easier when ZVM exposes the actual failing resource or backend message.
Do Not Use This Thread as a 2026 Feature Matrix
ZVM continued evolving after the initial feedback campaign, and community extensions now add features such as snapshots, autostart, USB/PCIe passthrough, backup exports, and metrics around the built-in libvirt layer. Some 2024 requests therefore have working community paths even when they were absent in the original interface.
When deciding whether ZVM can run a specific appliance today, test the current ZVM image formats and device controls instead of relying only on this historical request list.
LXC Was Part of the Original Official Voting List
IceWhale's opening post specifically said LXC support was already attracting votes. That is a different virtualization model from full KVM/QEMU virtual machines: LXC-style system containers share the host kernel while presenting a more VM-like userspace.
The thread does not show IceWhale shipping LXC as a ZVM feature, so the safe historical statement is only that it was a requested direction.
Users Wanted Appliance Import, Not Just More File Extensions
The requests for QCOW2, VDI, and OVA were really about portability. Users already had appliances that worked on QNAP, Unraid, VMware, or other hypervisors and wanted to bring those systems into ZVM without rebuilding them from installation media.
That means format support, disk-bus compatibility, firmware mode, network configuration, and imported VM metadata all matter. Recognizing a file extension alone does not guarantee that an appliance boots correctly.
Display Resolution and Audio Passthrough Were Also Practical Pain Points
One advanced user wanted to experiment with QEMU options because their Linux guests needed better display resolutions and they had previously been told Windows audio passthrough was not available. They also wanted easier storage-pool resizing through a richer GUI.
These requests show that ZVM feedback was not only about creating VMs; users wanted deeper lifecycle and device control after the VM already existed.
The Thread Helps Separate Beginner and Power-User Priorities
For ordinary users, image import, clear errors, reliable boot, and autostart reduce friction. For advanced users, PCI passthrough, custom QEMU arguments, storage resizing, LXC, and direct libvirt access matter more.
That distinction is useful when evaluating ZVM today: a feature can be unnecessary for a simple Home Assistant appliance but essential for a GPU-backed Windows or gaming VM.
ZVM Feedback FAQ
Did users ask for QCOW2 support?
Yes. QCOW2 and other prebuilt VM formats were among the most repeated requests.
Did IceWhale promise PCI passthrough in this thread?
No. Users requested it and the team acknowledged feedback, but the thread is not a release commitment.
Was VM autostart requested?
Yes, specifically for server VMs that need to return after a host reboot.
