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
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