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

mansecurityReviewed March 6, 2026

AppArmor and the sVirt isolation model

AppArmor and SELinux solve a similar problem for libvirt: they confine the hypervisor and protect guest resources with mandatory access control. sVirt is the broader model that binds guest execution to labeled or profile

apparmorsvirtconfinement

AppArmor and SELinux solve a similar problem for libvirt: they confine the hypervisor and protect guest resources with mandatory access control. sVirt is the broader model that binds guest execution to labeled or profiled resources.

What changes on AppArmor hosts

Instead of SELinux labels, you usually inspect AppArmor profiles, complain mode, and denials recorded by the kernel or distribution tooling.

BASH
aa-status
journalctl -k -g apparmor -n 100

sVirt mental model

Think in terms of controlled guest reach:

  • The guest process should only see its own disks and devices.
  • Host-side resources need an explicit profile or label path.
  • Moving a disk or firmware blob can silently invalidate the policy assumptions.

Practical debugging

Start with the resource path and the guest XML. If both are correct, inspect the host security framework before editing the domain definition again.

Related

  • virtqemud and virtproxyd roles
  • SELinux, virtd_t, and common denials
  • Troubleshooting playbook

On this page

  • What changes on AppArmor hosts
  • sVirt mental model
  • Practical debugging