Skip to navigationSkip to content
libvirtd docs
Commands

Manual nav

Search `/` or jump with `g` / `G`.

Portal

  • Home manual
  • Command explorer
Foundations6 sections
  • Overview1
  • Installation2
  • Platform1
  • Concepts5
  • Domains2
  • Domain XML2
Subsystems9 sections
  • Identity1
  • Automation2
  • Daemons3
  • virsh3
  • Networking5
  • Storage4
  • Security3
  • Observability2
  • Remote Access1
Operations6 sections
  • Migration2
  • Backup2
  • Performance3
  • Recovery1
  • Troubleshooting2
  • References2

/ search · g top · G quickstart

manconceptsReviewed July 15, 2026

Control plane, drivers, and execution plane

Libvirt is an API and driver framework. It normalizes lifecycle, storage, network, and host operations while hypervisors such as QEMU/KVM perform guest execution. Request path This separation explains why a successful AP

apidriverqemuarchitecture

Libvirt is an API and driver framework. It normalizes lifecycle, storage, network, and host operations while hypervisors such as QEMU/KVM perform guest execution.

Request path

TEXT
virsh / application
        |
libvirt client API
        |
UNIX socket, SSH, or TLS
        |
libvirtd or modular daemon
        |
QEMU, network, storage, secret, and node-device drivers
        |
kernel KVM + host resources

This separation explains why a successful API connection does not prove a guest can boot. Socket access, XML validation, storage labels, bridge state, QEMU capabilities, and KVM acceleration are distinct gates.

Ask the right layer

  • Use virsh uri and socket inspection for connection failures.
  • Use virsh domstate, dumpxml, and QEMU logs for domain failures.
  • Use net-dumpxml, ip, and firewall tooling for network failures.
  • Use pool-info, vol-info, and filesystem evidence for storage failures.

Related

  • libvirtd overview and the compatibility daemon
  • QEMU, KVM, and libvirt: division of responsibility
  • virtqemud and virtproxyd roles

On this page

  • Request path
  • Ask the right layer