VM Curator

Checked: 2026-07-14

Summary

VM-curator is a Rust terminal interface for creating and managing desktop QEMU/KVM virtual machines on Linux. It replaces much of the libvirt and virt-manager workflow with editable QEMU launch scripts, more than 120 operating-system profiles, and guided setup for graphics and device passthrough.

It can supply a full virtual-machine boundary for an agent, but it is not designed as an agent sandbox or security policy system.

Problem it solves

• QEMU complexity: Building useful desktop VM commands by hand is error-prone.
• Virt-manager friction: The author wanted fewer screens, no libvirt XML, and working NVIDIA para-virtualized 3D graphics.
• Desktop VM setup: It guides users through disks, firmware, snapshots, networking, shared folders, USB, and GPU passthrough.
• Mixed VM libraries: It discovers existing launch.sh-based VMs and imports libvirt XML or Quickemu configurations.

How it works

• Local manager: The terminal interface scans a chosen library directory for VM folders containing launch.sh.
• Direct QEMU: It generates, parses, edits, and runs QEMU commands without requiring libvirt.
• Profiles: More than 120 profiles select suitable machine, CPU, disk, display, audio, and network settings for many operating systems.
• Disk images: It creates virtual disks with qemu-img; qcow2 disks support create, restore, and delete snapshot operations.
• Desktop integration: Optional features include 3D acceleration, SPICE clipboard sharing, host folders, USB/PCI passthrough, Looking Glass, and single-GPU passthrough.
• Control: The interface monitors VM processes and can launch, pause, resume, stop, or force-stop them.

Think of it as a friendly control panel for QEMU, not an automatic guard at the VM door.

Security boundary

• Guest isolation: The actual boundary comes from QEMU/KVM hardware virtualization, guest configuration, and the host kernel—not VM-curator itself.
• Full guest system: A guest can run normal operating-system tools and native programs, unlike a narrow WebAssembly sandbox.
• Boundary openings: Shared folders, clipboard integration, networking, USB, PCI, and GPU passthrough intentionally connect guest and host resources.
• Editable scripts: Users can directly edit generated launch.sh files and extra QEMU arguments. This is flexible, but it makes policy consistency the user’s responsibility.
• Privilege use: Bridge and device-passthrough setup may use Linux capabilities, pkexec, or sudo for host changes.
• No agent policy layer: The project does not advertise per-session policy, command approval, network allowlists, secret brokering, image signing, or automatic cleanup of untrusted agent sessions.

For hostile agent workloads, every device, mount, clipboard channel, network route, and launch argument needs an independent review.

Platforms and agents

• Host platform: Linux with QEMU, qemu-img, and libudev; KVM acceleration requires supported hardware and host configuration.
• Packages: AUR, crates.io, Nix, DEB, RPM, AppImage, tarball, and source builds are documented.
• Guest systems: Profiles cover current and historical Windows, Linux, BSD, macOS, Unix, mobile, infrastructure, research, and retro systems.
• Architectures: The code recognizes x86_64, i386, PowerPC, m68k, ARM, AArch64, and custom QEMU emulators.
• Agents: No coding-agent integration is provided. Any agent that runs in a supported guest can be installed manually.

Setup

1. Install prerequisites: QEMU, qemu-img, and libudev are required.
2. Install VM-curator: Use a supported package, cargo install vm-curator, Nix, or build from source.
3. Choose a library: The first-run wizard sets the VM directory; the documented default is ~/vm-space.
4. Create or import: Select an operating-system profile and installation media, or import an existing VM.
5. Review exposure: Choose networking, shared folders, clipboard, and device passthrough based on the workload’s trust level.

VM-curator does not download licensed operating-system disk images. The user supplies installation media; some profiles link to official or archive sources.

Network and credentials

• Network choices: User-mode SLIRP/NAT, passt, host bridge, or no network.
• Inbound access: TCP or UDP port forwards can expose selected guest services to the host or network.
• Isolation option: Selecting no network removes the VM network adapter.
• Credentials: No secret store, proxy, or credential broker was found. Credentials placed in the guest behave like normal guest files and process data.
• Host access: Shared folders, SPICE clipboard, attached USB storage, and passthrough devices can move sensitive data across the boundary.
• Agent use: A safer agent profile would normally start with no shared folders, clipboard, or passthrough and enable only the network access required. VM-curator does not enforce that profile automatically.

Strengths

• Broad compatibility: It manages full operating systems and native software.
• Direct and transparent: Generated QEMU shell scripts can be inspected and changed.
• Desktop graphics: Para-virtualized 3D and GPU passthrough are major project strengths.
• Guided setup: Profiles and wizards reduce QEMU configuration work.
• Practical management: Snapshots, imports, monitoring, notes, search, ports, shared folders, and devices live in one terminal interface.
• Active releases: The project reached v1.2.0 within six months and has external contributions and automated formatting, lint, test, and dependency-audit checks.
• Permissive license: MIT.

Limits

• Linux host only: It depends on Linux QEMU/KVM and libudev workflows.
• Not agent-focused: There is no session API, policy engine, credential proxy, repository handoff, or agent lifecycle automation.
• Manual guest setup: The tool creates machines, not ready-to-use coding-agent images.
• Security defaults vary: Desktop conveniences can weaken isolation if enabled.
• Script model: launch.sh is flexible but harder to centrally validate than a narrow declarative policy.
• Single maintainer: The README calls it a spare-time personal project with no promise that feature requests will be implemented.
• GPU complexity remains: IOMMU groups, firmware, drivers, display-manager shutdown, and host hardware still constrain passthrough.

Activity and maturity

As of 2026-07-14:

• Latest release: v1.2.0, published 2026-07-06.
• Repository: Created 2026-01-22; 344 stars and 13 forks when checked.
• Recent push: 2026-07-06.
• Release status: v1.0.0 was described as the first stable release; v1.2.0 includes fixes for Windows 11 firmware, GPU passthrough, and dependency security advisories.
• Maintenance: The author says it is used daily and critical bugs will be fixed, but development happens in spare time.
• Interpretation: Mature enough for personal desktop VM management, but not evidence of a reviewed multi-tenant or hostile-agent security platform.

Best fit

• Good fit: A Linux user wants a terminal-first QEMU desktop VM manager with graphics, passthrough, and many guest profiles.
• Possible agent fit: A developer is willing to build and inspect a dedicated guest image, manually harden connectivity, and manage agent sessions themselves.
• Poor fit: A team needs repeatable disposable agent environments, centrally enforced network rules, safe credential use, or multi-user orchestration.

Comparison with Clawk

Area	VM-curator	Clawk
Primary goal	Friendly desktop QEMU VM management	Isolated coding-agent sessions
Boundary	QEMU/KVM full VM	Full VM designed around agent use
Agent setup	Manual guest installation	Agent-oriented environment and workflow
Network	NAT, passt, bridge, port forwards, or none	Controlled agent network policy
Credentials	Normal guest-managed secrets	Agent-specific credential handling
Host sharing	Optional folders, clipboard, USB, PCI, GPU	Narrower workflow-controlled exchange
Lifecycle	Long-lived personal VM library and snapshots	Disposable or session-oriented agent machines
Best use	Interactive desktop operating systems	Running untrusted coding agents

Practical choice: VM-curator is the more general desktop VM tool. Clawk is the more purpose-built guardrail for coding agents.

Hacker News context

• Original launch: HN item 46750437 was “Show HN: VM-curator – a TUI alternative to libvirt and virt-manager.” The author focused on direct QEMU use, simpler configuration, and NVIDIA 3D acceleration.
• Launch feedback: Comments asked about GPU passthrough, installation-media downloads, and NVIDIA support. The author later reported single-GPU and experimental multi-GPU passthrough in v0.2.x.
• Current change: GPU passthrough is now a documented feature rather than only a planned feature from the launch discussion.
• Clawk thread: Comment 48893850 linked the VM-curator Show HN inside a broad list of VM, container, WebAssembly, and agent-isolation technologies. It did not claim VM-curator itself was an agent sandbox.

Direct sources

• VM-curator repository
• VM-curator v1.2.0 release
• VM-curator on crates.io
• Original VM-curator Show HN
• Clawk discussion
• Clawk comment linking VM-curator

Unknowns

• Independent audit: No independent VM-curator or recommended-QEMU-profile security audit was found.
• Agent hardening: No maintained secure baseline for coding agents was found.
• Cleanup: Automatic reset or destruction after each session was not documented.
• Credential safety: No method for giving an agent short-lived credentials without storing them in the guest was documented.
• Multi-user use: Access control, quotas, remote APIs, and concurrent tenant isolation were not documented.
• Test matrix: The README lists broad distribution and guest support, but a complete tested host/guest/hardware matrix was not found.

Sources

• • imported AI research note for Vm Curator.