My host OS is Ubuntu Server 11.04 (natty)

After following the instructions detailed by Ubuntu's help, I created one KVM image using

sudo ubuntu-vm-builder kvm hardy --libvirt qemu:///system

The image file was created as

-rw-r--r-- 1 root root 438M 2011-06-17 14:39 ubuntu-kvm/tmpK9hbU5.qcow2

The I can list it with virsh by sudo virsh -c qemu:///system "list --all"

Id   Name                 State
  - ubuntu               shut off  

Buth when I call

sudo virsh -c qemu:///system "start ubuntu"

The error was thrown up:

error: Failed to start domain ubuntu
error: internal error process exited while connecting to monitor: kvm: -drive file=/home/myuser/vmopt/ubuntu-kvm/tmpK9hbU5.qcow2,if=none,id=drive-ide0-0-0,format=qcow2: could not open disk image /home/myuser/vmopt/ubuntu-kvm/tmpK9hbU5.qcow2: Permission denied

The user "myuser" had been added to group libvirt.

I've gone so far as to chmod the image file as well its directory to 777, but the error is still there.


KVM images are restricted by selinux. Putting them in /var/lib/libvirt/images should suffice.

http://libvirt.org/drvqemu.html#securityselinux goes into more detail.

  • Man!! This worked for me. Thanks a lot man. Apparently the $HOME directory of your account is protected wich is where virsh likes to install things at by default. After I installed my vms, I ran mv $HOME/vmfolder /var/lib/libvirt/images. Then I ran virsh edit vmname and changed the image file's location accordingly. Feb 23 '12 at 3:47
  • I also had to change the owner of one of my vms. It belonged to root which led to an access denied. sudo chown -R libvirt-qemu:kvm dbos/ubuntu-kvm/. You can run ls -l on/your/vm/dir/and/its/subdirs/ to check permissions at each level. Ensure none of them belong to the root group and user. Feb 23 '12 at 4:05
  • I've found that the easiest and safest way to create your vm's is to make sure you cd to this directory /var/lib/libvirt/images and run your install from there. That way you won't have to worry about the folder level permissions. They'll just default to the current user as opposed to root. Feb 23 '12 at 5:01

a easy solution would be to edit the /etc/libvirt/qemu.conf file and uncommenting the following lines:

User = "root"
group = "root"

Don't forget to restart libvirtd

  • 4
    That might let you run it, but what are the security implications?
    – cpast
    Feb 25 '13 at 15:19
  • 1
    Probably better to add yourself to the kvm group, adjust the image file permissions accordingly, and set user="<yourname>" in qemu.conf.
    – Marc.2377
    Jul 22 '17 at 3:16

In Arch Linux:

sudo usermod -a -G kvm username

set permissions for QEMU processes in /etc/libvirt/qemu.conf

user = "username"
group = "kvm"

to refresh group membership in the same terminal:

su - username

Add an alias to your ~/.bashrc

alias virsh='EDITOR=nano sudo virsh && cd /etc/libvirt/qemu'


source ~/.bashrc
list --all
start mydomain

Running QEMU with root privileges is not advised, as from version 6.0.0 it would not strip the Linux capabilities.

In my case it was AppArmor. I wanted to add an SSDT file for a battery to the VM. There are some folders which AppArmor allows access to, and others (like /home/something) are just not allowed. /var/lib/libvirt/images/ is one of the allowed folders. Although i placed my file there, it was still not allowed by AppArmor policy (as can be seen with sudo cat /var/log/kern.log | grep -C 10 apparmor | grep -C 10 qemu). What worked was adding /var/lib/libvirt/images/SSDT1.dat rk in /etc/apparmor.d/libvirt/TEMPLATE.qemu like this:

# This profile is for the domain whose UUID matches this file.

#include <tunables/global>

profile LIBVIRT_TEMPLATE flags=(attach_disconnected) {
  #include <abstractions/libvirt-qemu>
  /var/lib/libvirt/images/SSDT1.dat rk,

It seem this permission-error can also be related to corrupted qcow2 overlay/snapshots!

In had this setup:

Baseimage > Overlay1 > Overlay2

The overlays was created with cmd virsh snapshot-create ... and Overlay1 was newer used (VM not started) before creating Overlay2 (created for testing).

Not a very likely IRL use case, but nonetheless it got this error and it was driving me nuts until I realized if was related to the overlay chain and not file-system access permissions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy