Choosing KVM management and automation tools

The commands and XML are generic examples; adapt them to the host version and actual resources. Network addresses use documentation ranges; choose nonconflicting private networks for real deployments. See the relevant sections for the conditions required for image modification and device passthrough.

1 A landscape of KVM management frontends#

virsh, virt-manager, Cockpit machines, and WebVirtCloud generally manage QEMU/KVM through libvirt, but not every tool uses the same API. Proxmox VE has its own management stack, while virt-builder primarily builds offline images. Even tools that use libvirt must connect to the same host and URI to see the same domains.

1.1 Architecture overview

graph TD
    User["管理员"] --> CLI["virsh / virt-install"]
    User --> Desktop["virt-manager / Boxes / virt-viewer"]
    User --> Web["Cockpit machines / oVirt / WebVirtCloud"]
    CLI --> Libvirt["libvirt API 与实际 daemon"]
    Desktop --> Libvirt
    Web --> Libvirt
    Libvirt --> QEMU["QEMU 客体进程与设备模型"]
    User --> PVE["Proxmox VE 自有管理栈"]
    PVE --> QEMU
    User --> Builder["virt-builder / libguestfs 离线镜像构建"]
    Builder --> Image["磁盘镜像"]
    Image --> QEMU
    QEMU --> KVM["Linux KVM 加速器"]

GUI, CLI, and IaC tools can operate on the same domain, but not every operation has an equivalent entry point. When mixing tools, establish resource ownership so the next Terraform/NixVirt apply does not overwrite manual edits. Do not assume that Boxes session/Flatpak instances share resources with the host’s system libvirt instance.

1.2 Three main frontend categories

1.3 Tools covered in this article

2 Desktop GUI frontends#

Desktop GUI tools run in the local desktop environment of a workstation or server and operate libvirt directly through a graphical interface.

2.1 GNOME Boxes: the simplest graphical KVM client

GNOME Boxes is the GNOME desktop environment’s virtualization tool, designed to work with "zero configuration". The original notes were written in the GNOME 49 era; this article retains the feature overview without calling 49.0 the current latest version. Its current official focus is local virtual machines; GNOME Connections handles remote desktops.

Installation:

# Debian / Ubuntu
sudo apt install gnome-boxes

# Fedora
sudo dnf install gnome-boxes

# Arch Linux
sudo pacman -S gnome-boxes

Core strengths:

Key limitations:

GNOME Boxes limitations

• Boxes usually manages resources in the user session scope; verify the URI for the particular package or Flatpak instance. It does not provide the full system-level management interfaces available in tools such as virt-manager. However, session scope alone does not mean every lifecycle feature is necessarily unavailable.
• No TCG fallback: if the CPU lacks VT-x/AMD-V, Boxes refuses to work rather than falling back to software emulation
• Overwrites custom CPU settings: if you manually set host-passthrough, which is needed for nested virtualization, Boxes resets it on the next start
• No snapshots with UEFI: snapshot functionality for EFI virtual machines has long-standing limitations
• No fine-grained hardware tuning: no precise CPU model configuration, multiple virtual disks, or complex device layouts

Best suited to: beginners quickly trying other Linux distributions, lightweight virtualization for desktop users, and simple Windows virtual machines

How its role differs from virt-manager:

Boxes vs virt-manager If KVM virtualization were a way of getting around:

• GNOME Boxes is a bicycle: quick to learn and good for short trips, but unable to carry heavy loads
• virt-manager is a repair workshop: fully equipped to dismantle and assemble every part, but with a learning curve

When Boxes is no longer sufficient, you can open the same virtual machine in virt-manager without losing any data.

2.2 virt-viewer: a lightweight SPICE/VNC console

virt-viewer is not a virtual-machine manager; it is purely a desktop console client. It does one thing: connect to a virtual machine’s graphical console.

Installation:

sudo apt install virt-viewer    # Debian/Ubuntu
sudo dnf install virt-viewer    # Fedora
sudo pacman -S virt-viewer      # Arch

Typical usage:

# 连接指定虚拟机的控制台
virt-viewer --connect qemu:///system <vm-name>

# 连接到远程主机的虚拟机
virt-viewer -c qemu+ssh://user@server.example.com/system <vm-name>

virt-manager includes virt-viewer’s functionality, essentially using the same SPICE/VNC client libraries. If virt-manager is already open, you do not need to launch virt-viewer separately. If you only need a console connection and do not want to launch the full virt-manager application, virt-viewer is lighter. For details, see 04 Graphical KVM management.

3 Web management platforms#

The following retains an overview of each platform’s features; version numbers and earlier release dates are historical context only. Cluster HA, migration, snapshots, and backups all require additional storage, quorum, or compatibility conditions. QEMU live migration differs from LXC migration: container migration involving a restart should not be described as zero-downtime migration of memory state. Before deployment, review publicly exposed management UI listeners, default accounts, and permissions.

Web management platforms provide graphical controls through a browser. Their key advantages are remote access and multi-user collaboration, without installing a client on the management machine.

3.1 Cockpit + cockpit-machines

Cockpit is a lightweight web-based server management tool maintained by Red Hat, running on port 9090 by default. The cockpit-machines plugin provides common libvirt virtual-machine management functions; exact capabilities vary with the plugin version.

Architecture:

graph LR
    Browser["浏览器 / https://host:9090"] --> Cockpit_WS["Cockpit Web 服务 / (cockpit-ws)"]
    Cockpit_WS --> Libvirt["libvirt API"]
    Libvirt --> QEMU["QEMU/KVM"]

Installation and activation:

# Debian / Ubuntu
sudo apt install cockpit cockpit-machines -y
sudo systemctl enable --now cockpit.socket libvirtd

# Fedora / RHEL / Rocky Linux
sudo dnf install cockpit cockpit-machines -y
sudo systemctl enable --now cockpit.socket libvirtd

Visit https://<服务器IP>:9090 and sign in with a system account.

Core features (as of 2025-2026, versions 314-337):

Key updates as of 2025-2026:

• Upgrade to the PatternFly 6 UI framework (v330) for a more modern interface
• Source mode selection for virtual network interfaces (v333), enabling finer network control
• Enhanced VNC and serial consoles (v336), including scaling controls

Advantages:

• Lightweight: adds only a web frontend, without changing the underlying KVM architecture
• Integrated server management: manages disks, networking, logs, terminals, and containers as well as VMs; containers require cockpit-podman
• Backed by Red Hat: a default component of Fedora Server and RHEL, with ongoing active maintenance
• Multiple hosts: Cockpit can connect to and manage multiple servers

Limitations:

Cockpit limitations

• Cannot create bridges from the web UI; the CLI is required
• Storage pool creation and selection depend on the cockpit-machines version and backend. Check the current interface and documentation rather than treating historical limitations as permanent omissions.
• ISO downloads sometimes fail to find an image; downloading manually is recommended
• Advanced operations still require the virsh CLI

Best suited to: managing one or more KVM hosts, general server management requiring a web UI, and users who do not want to install a dedicated virtualization OS.

3.2 Proxmox VE: a complete virtualization platform

Proxmox Virtual Environment (Proxmox VE) is more than a frontend: it is a complete Type-1 virtualization operating system, based on Debian and integrating a web UI, KVM virtualization, LXC containers, ZFS storage, clustering, and backup systems.

Architecture:

graph TD
    Browser["浏览器 / https://pve:8006"] --> PVEProxy["pveproxy / (HTTP/WebSocket 网关)"]
    PVEProxy --> PVEMgr["pve-manager / (集群管理与 API)"]

    PVEMgr --> Corosync["Corosync / (集群通信)"]
    PVEMgr --> QEMU["QEMU/KVM / (虚拟机)"]
    PVEMgr --> LXC["LXC / (容器)"]
    PVEMgr --> Storage["存储层 / ZFS/Ceph/NFS/LVM"]

    Corosync --> Cluster{"PVE 集群 / （容量需按支持版本与仲裁设计验证）"}

Not an APT package: it is a complete OS:

Installation methods Proxmox VE is a complete host platform, with both an official ISO installation method and a package-based route on supported Debian systems. The ISO generally involves disk layout changes and reinstallation, so it should not be treated as an ordinary GUI application for an existing host. The original notes’ 8.4 / Debian 12 combination is a historical example. For current deployments, check the installation documentation and support lifecycle of the selected release.

Core capabilities (Proxmox VE 8.x, as of 2025-2026):

Highlights of version 8.4 (April 2025):

• Enhanced live migration for a more stable migration process
• Improved backup integration and closer coordination with Proxmox Backup Server
• Kernel updated to the 6.8 series, supporting newer hardware

Advantages:

• Enterprise-grade features with a free community edition under the AGPL license
• The web UI covers full platform management; the feature set depends on the platform version
• A large community ecosystem with extensive tutorials and documentation
• Unified management of both virtual machines and containers

Limitations:

• Requires replacing the operating system or installing an additional layer on Debian
• Heavier than Cockpit; even a single-host deployment requires the complete Proxmox stack
• Clusters need a stable network because Corosync is sensitive to latency
• Enterprise support requires a paid subscription

Best suited to: a first choice for homelabs, virtualization in small and medium-sized businesses, environments needing clustering and high availability, and users migrating from VMware.

3.3 oVirt: enterprise-grade KVM management

oVirt is the upstream open-source project for Red Hat Virtualization (RHV), positioned as a KVM alternative with a role similar to VMware vSphere. It uses a centralized management engine: one oVirt Engine manages multiple KVM host nodes.

Architecture:

graph TD
    Browser["浏览器 / （管理员门户 + 用户门户）"] --> Engine["oVirt Engine / (Java/WildFly/JBoss)"]
    Engine --> Postgres["PostgreSQL / (配置数据库)"]
    Engine --> VDSM1["VDSM @ Host 1 / (libvirt 管理代理)"]
    Engine --> VDSM2["VDSM @ Host 2 / (libvirt 管理代理)"]
    VDSM1 --> QEMU1["QEMU/KVM"]
    VDSM2 --> QEMU2["QEMU/KVM"]
    Engine --> Storage["存储域 / (NFS/iSCSI/FC/Gluster)"]

Current status (as of 2025-2026):

Slower development The official oVirt release records provide historical change notes for 4.5.7. Do not infer that maintenance has stopped, or that this is the only update, from a single release interval. Evaluate the selected release, host OS support, upgrade path, documentation, and actual community maintenance status, rather than calling a historical version current.

Changes in 4.5.7:

• Support for CentOS 10 and AlmaLinux 10
• New CPU support: AMD EPYC Milan/Rome/Genoa, Intel Sapphire Rapids, and IBM POWER10
• Full migration of Java code to Java 21
• Fix for CVE-2024-7259, an administrator-password disclosure vulnerability

Core capabilities:

Advantages:

• A vSphere-style management experience: data center → cluster → host → VM
• Enterprise-grade RBAC and multi-tenant isolation
• Upstream of RHV, compatible with the Red Hat ecosystem

Limitations:

• Complex deployment: install the Engine, configure storage domains, and add hosts
• The Java engine is relatively heavy and needs substantial resources
• Community development has slowed, with an uncertain long-term outlook
• Centered on RHEL/CentOS, with limited Debian-family support

Best suited to: existing RHV users, large enterprise data centers with dozens or more KVM hosts, and environments needing a vSphere-like management model.

Red Hat’s new direction Red Hat’s current primary virtualization offering is OpenShift Virtualization, based on KubeVart, which runs virtual machines as Kubernetes workloads on OpenShift clusters. If you are planning new enterprise virtualization infrastructure, consider evaluating both Proxmox VE and OpenShift Virtualization.

3.4 WebVirtCloud: lightweight web-based KVM management

WebVirtCloud is an open-source web-based KVM management platform built on Python/Django. It aims to offer a Proxmox-like web management experience without replacing the operating system; it can be installed directly on an existing Linux server.

Core technology stack: Python >= 3.11, Django 4.2 LTS, libvirt, noVNC

Core capabilities:

Installation method:

# 部署参考：先审阅仓库 compose、默认账户、secret、权限和网络监听，再决定启动
git clone https://github.com/retspen/webvirtcloud.git
cd webvirtcloud
docker-compose up -d

# 方式二：手动安装（参考官方文档）
# Python/Django/libvirt/noVNC版本以所选commit的依赖文件为准

Activity: the retspen/webvirtcloud fork remained active on GitHub through 2025-2026, with support for Ubuntu 26.04/24.04/22.04 and Debian.

Advantages:

• No OS replacement; can be added to an existing server
• One-step Docker deployment
• Multiple users and hosts, suitable for team collaboration
• A complete REST API for automation integrations

Limitations:

• A smaller community than Proxmox
• Less feature depth than Proxmox VE, with no built-in cluster HA or integrated backup server
• Remote host management relies on SSH connections, so performance is affected by the network

Best suited to: teams wanting to add web management to existing Linux servers, environments needing simple multi-tenant web management, and DevOps workflows that orchestrate KVM resources through an API.

3.5 Kimchi / Wok: historical projects and checking maintenance status

Kimchi is an HTML5-based KVM management tool started by IBM in 2014. Wok is the CherryPy-based web framework used by Kimchi.

Project status: abandoned

• The v2.5 release cited in the original notes is historical. Before deployment, check repository releases, archival status, and security maintenance.
• The status of the original sponsorship does not mean that development has stopped on every branch today; evaluate the specific repository and its dependencies.
• Last activity in the Kimchi repository was in January 2023
• Last activity in the Wok repository was in June 2021
• Not recommended for any new deployment; included here only as historical background

If you are evaluating web-based KVM management, choose from Cockpit, Proxmox VE, and WebVirtCloud rather than Kimchi/Wok.

4 CLI and automation tools#

Desktop GUIs and web UIs suit interactive work, but CLI and automation tools are indispensable in the following scenarios:

• Bulk management: operating on hundreds of virtual machines at once
• Scripting/CI/CD: integrating VM creation and destruction into automated pipelines
• Infrastructure as Code: defining virtualization infrastructure declaratively
• Headless servers: remote hosts without a desktop environment or browser

4.1 virsh: the general-purpose libvirt CLI

virsh is the official command-line tool from the libvirt project and the low-level foundation for all other frontends. Anything graphical frontends can do, virsh can do.

For detailed virsh usage, see 03 KVM CLI management. Here are its key characteristics:

• Versatility: one command manages every backend supported by libvirt, including KVM, Xen, LXC, and QEMU
• Remote capabilities: manage virtualization on remote hosts through -c qemu+ssh://
• Script-friendly: output can be processed with grep/awk/jq, making it suitable for automation
• Native XML: operates directly on libvirt XML definitions, without an intervening abstraction layer

4.2 virt-install: scripted VM creation

virt-install is part of the virt-manager project and is dedicated to creating virtual machines from the command line. It can generate domains and drive installation or import workflows, often including define/start. It also handles installation media and guest defaults, so it is not simply an alias for two commands.

# 典型用法：从 ISO 创建虚拟机
virt-install \
  --name demo-vm \
  --ram 4096 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/demo-vm.qcow2,size=20 \
  --os-variant ubuntu24.04 \
  --network bridge=virbr0 \
  --graphics spice \
  --cdrom /path/to/ubuntu-24.04.iso

For more virt-install usage, see 04 Graphical KVM management, which covers both virt-manager and virt-install.

4.3 virt-builder: template-based builds

First use --list/--notes to choose a template that actually exists, then pin and verify its source. Password files should have 0600 permissions and be supplied through a secure runtime mechanism. Avoid plaintext passwords in command arguments or committing password files to a repository. Building a template neither creates a domain nor verifies behavior after boot.

virt-builder comes from the libguestfs project and can quickly build virtual-machine images from predefined templates:

# 列出可用的模板
virt-builder --list

# 从模板构建一个 Ubuntu 24.04 镜像
virt-builder ubuntu-24.04 \
  --size 20G \
  --format qcow2 \
  --hostname my-vm \
  --root-password "file:/run/secrets/<VM_ROOT_PASSWORD_FILE>" \
  --install vim,nginx,openssh-server \
  -o /var/lib/libvirt/images/my-vm.qcow2

virt-builder’s strengths are repeatability and automation. Pinning template versions, checksums, repositories, and customization inputs improves repeatability, but randomized identities, timestamps, and mutable software repositories mean the same command does not guarantee byte-identical output. It is a natural fit for CI/CD pipelines.

4.4 Cloud-Init and cloud images: modern automated configuration

current download URLs change; real deployments should pin release files and official signatures/checksums. After confirming the image format, create an overlay for each VM. Check the qcow2 assumption below with qemu-img info. A cloud-init seed contains identity configuration: protect its permissions and check the instance ID/metadata so clones do not reuse identities. The example uses a documentation public-key placeholder that must be replaced; it is not a complete credential usable for login.

For large-scale deployment, the most modern approach is cloud images + cloud-init:

# 1. 下载 Ubuntu Cloud Image
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img

# 2. 创建 cloud-init 配置
cat > user-data <<'EOF'
#cloud-config
hostname: auto-vm
users:
  - name: user
    groups: [sudo]
    shell: /bin/bash
    lock_passwd: true
    ssh_authorized_keys:
      - "ssh-ed25519 <ADMIN_PUBLIC_KEY_DATA> admin@example.com"
ssh_pwauth: false
packages:
  - vim
  - curl
  - nginx
EOF

# 3. 生成 cloud-init ISO
cloud-localds seed.img user-data

# 4. 每台 VM 使用独立 overlay，保持下载的 base 不变；先核对文件格式
qemu-img create -f qcow2 -F qcow2 -b "$(pwd)/noble-server-cloudimg-amd64.img" auto-vm.qcow2

# 5. 用 virt-install 创建 VM（附加 cloud-init 磁盘）
virt-install \
  --name auto-vm \
  --ram 2048 \
  --vcpus 2 \
  --disk path=auto-vm.qcow2,format=qcow2 \
  --disk path=seed.img,device=cdrom \
  --os-variant ubuntu24.04 \
  --import

This is a best practice for KVM management in the cloud-native era. Image size and boot time vary with version and customization. Configuration can be reviewed, while runtime information such as identities and secrets should be managed securely and separately.

4.5 Terraform Libvirt Provider

This is a minimal domain/volume example using an older provider interface. Pinning 0.8.3 only specifies the schema version and is not a recommendation for current deployments. Newer provider versions introduce migration changes, so check the documentation for the locked version and inspect the plan. The example does not attach a cloud-init seed or guarantee that guest accounts, IP addresses, an agent, or login are ready. apply creates or modifies real resources; review deletion/recreation and disk-retention policies in the plan before approval.

Terraform’s dmacvicar/libvirt provider brings KVM virtualization into Infrastructure as Code:

terraform {
  required_providers {
    libvirt = {
      source = "dmacvicar/libvirt"
      version = "= 0.8.3" # 此处保留 0.8.x schema 的历史示例；升级前迁移并核对新版文档
    }
  }
}

provider "libvirt" {
  uri = "qemu:///system"
}

resource "libvirt_volume" "ubuntu" {
  name   = "ubuntu-terraform.qcow2"
  source = "https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img"
  format = "qcow2"
}

resource "libvirt_domain" "vm" {
  name   = "terraform-vm"
  memory = 2048
  vcpu   = 2

  network_interface {
    network_name = "default"
  }

  disk {
    volume_id = libvirt_volume.ubuntu.id
  }

  console {
    type        = "pty"
    target_port = "0"
  }
}

Terraform suits virtualization environments that need declarative management, version control, and collaborative review. If you already use Terraform to manage cloud resources, extending it to local KVM hosts is a natural step.

5 Tool selection summary#

5.1 Overall comparison matrix

5.2 Decision flowchart

graph TD
    Start["我需要 KVM 管理前端"] --> Q1{"管理几台主机？"}

    Q1 -->|"单台"| Q2{"主要操作方式？"}
    Q1 -->|"多台 / 集群"| Q3{"需要集群 HA 吗？"}

    Q2 -->|"命令行/脚本"| A1["virsh / + virt-install / + cloud-init"]
    Q2 -->|"桌面 GUI"| Q4{"需要高级配置？"}

    Q4 -->|"是：PCI 直通、调优"| A2["virt-manager / （功能最全的桌面 GUI）"]
    Q4 -->|"否：快速创建基础 VM"| A3["GNOME Boxes / （零配置上手）"]

    Q3 -->|"是：生产环境 HA"| Q5{"愿意替换 OS？"}
    Q3 -->|"否：仅远程管理"| Q6{"需要多用户权限？"}

    Q5 -->|"是"| A4["Proxmox VE / （最完整的 KVM 平台）"]
    Q5 -->|"否"| A5["oVirt / （企业级，但发展放缓）"]

    Q6 -->|"是：团队协作"| A6["WebVirtCloud / （Docker 一键部署）"]
    Q6 -->|"否：个人使用"| A7["Cockpit / （最轻量的 Web 管理）"]

5.3 Recommendations by use case

5.4 Combining tools

When combining tools, record the host, URI, storage ownership, and definition ownership. System and session instances have different resources; Proxmox is not managed through virsh. Manual GUI edits can drift from IaC definitions. Feed changes back into the configuration that owns the resource and retain recovery information.

Combine interfaces as needed while preserving definition ownership Tools connected to the same libvirt instance can work together, provided resource ownership and synchronization of changes are clear:

• Use Cockpit for everyday monitoring and simple operations, with convenient remote web access
• Use virsh for advanced configuration and scripted bulk operations
• Use virt-manager for complex desktop-side debugging and PCI passthrough configuration
• Use cloud-init + Terraform for highly consistent environment cloning and IaC management

Concurrent operations and IaC/GUI state drift can still conflict. Do not run simultaneous jobs that modify the same domain, network, or disk.

5.5 Final recommendations

1. Getting started: install GNOME Boxes and begin with a local test VM. The time required depends on image downloads, hardware, and the installation process
2. Expanding your capabilities: when Boxes is no longer enough, install virt-manager and learn basic virsh commands
3. Server use: deploy Cockpit for web management and use virsh for deeper operations
4. Homelab/production: evaluate complete platforms such as Proxmox VE, including their requirements for reinstallation, storage, backups, and quorum
5. Existing enterprise KVM: continue using oVirt if already deployed; evaluate OpenShift Virtualization for new environments
6. DevOps/cloud-native: choose cloud-init, Terraform, NixVirt, or other automation tools according to the existing platform
7. What to avoid: first check the current maintenance, dependencies, and security fixes of historical options such as Kimchi/Wok; do not use them for new deployments if support is lacking

The key insight Choosing a KVM management frontend is fundamentally a user-experience decision rather than a technical one: they share the same backend. Select based on four dimensions: team skills, management scale, the need for web access, and willingness to replace the OS, rather than comparing underlying capabilities.