This bug was fixed in the package libvirt - 1.0.0-0ubuntu4
---
libvirt (1.0.0-0ubuntu4) raring; urgency=low
* debian/patches/apparmor-allow-hugepages: update apparmor policies to
allow use of hugepages. (LP: #646468)
* debian/patches/vnc-socket.patch: If a vnc socket is in
A better way to do it would be to modify libvirt to create a directory
on the hugetlbfs for the vm (not just for itself), then pass that as the
mem-path to kvm and tell the sVirt driver about it somehow.
--
Apparmor deny when trying to use hugetlbfs
https://bugs.launchpad.net/bugs/646468
You
I read about how it unlinks after creation, so I think in general have just a
commented line like this in /etc/apparmor.d/abstractions/libvirt-qemu is ok:
# Uncomment the following line to enable huge pages in your guests.
# owner /dev/hugepages/libvirt/qemu/* rw,
It would be better if
Look at this PPA
https://launchpad.net/~jcollins/+archive/jaminppa
--
Apparmor deny when trying to use hugetlbfs
https://bugs.launchpad.net/bugs/646468
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
--
Can you add this to /etc/apparmor.d/abstractions/libvirt-qemu:
owner /dev/hugepages/libvirt/qemu/* w,
and try again?
** Changed in: libvirt (Ubuntu)
Status: New = Incomplete
** Changed in: libvirt (Ubuntu)
Assignee: (unassigned) = Jamie Strandboge (jdstrand)
--
Apparmor deny
** Tags added: apparmor
--
Apparmor deny when trying to use hugetlbfs
https://bugs.launchpad.net/bugs/646468
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
--
Ubuntu-server-bugs mailing list
Ok, that was closer, but this time I get the message:
[84836.383289] type=1400 audit(1285366835.469:59): apparmor=DENIED
operation=open parent=1 profile=libvirt-
e2420e79-06d6-f8d0-0523-7c52b3650191
name=/dev/hugepages/libvirt/qemu/kvm.3Ag3N7 pid=1149 comm=kvm
requested_mask=r denied_mask=r
Just a follow-up...
This actually does work, and since qemu seems to unlink() right after
the mkstemp() there's only a small race condition there, and after that
the only way to steal another VMs memory is via procfs.
Is it worth writing a small doc (or debconf option?) to help people
setup
