Skip to navigationSkip to content
libvirtd docs
InteractiveCommands

Manual nav

Search `/` · tty `~` · g top · G bottom

Portal

  • Manual index
  • Interactive lab
  • Command explorer
Foundations5 sections
  • libvirtd Overview1
  • Host & Installation2
  • Architecture & Concepts6
  • Domains2
  • Domain XML2
Subsystems6 sections
  • Daemons3
  • virsh3
  • Virtual Networking5
  • Virtual Storage4
  • Virtualization Security3
  • Remote libvirt1
Operations5 sections
  • Migration2
  • Snapshots & Backup2
  • Performance3
  • Troubleshooting2
  • Reference2
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 modern daemon model
  • QEMU, KVM, and libvirt: division of responsibility
  • virtqemud and virtproxyd roles

On this page

  • Request path
  • Ask the right layer