Comment 3 for bug 1365261

@Takenori
These messages can be worked around by editing /etc/apparmor.d/abstractions/libvirt-qemu as such
__________________________________________________________
--- libvirt-qemu.orig 2014-12-19 20:13:31.162926539 +0000
+++ libvirt-qemu 2014-12-19 20:20:32.226276231 +0000
@@ -130,6 +130,7 @@

   # for rbd
   /etc/ceph/ceph.conf r,
+ /var/lib/charm/ceph/ceph.conf r,

   # for access to hugepages
   owner "/run/hugepages/kvm/libvirt/qemu/**" rw,
@@ -146,3 +147,8 @@
   # for ppc device-tree access
   @{PROC}/device-tree/ r,
   @{PROC}/device-tree/** r,
+
+ # deny qemu access to /tmp
+ deny /tmp/ r,
+ deny /var/tmp/ r,
+
----------------------------------------------------------------------------------

You are correct in assuming that qemu using librbd to talk to the ceph cluster which in turn invokes reads on /etc/ceph/ceph.conf. However I'm not sure why your specific setup is attempting to access your cinder keyring. If I understand correctly once the ceph.conf is read it should use the secret contained in the libvirt xml definition for the VM rather than the global keyrings. Can you please verify that your libvirt xml for related guests has a line like
<secret type='ceph' uuid='514c9fca-8cbe-11e2-9c52-3bc8c7819472'/>
albeit with a different uuid?

Also can you then check /etc/libvirt/secrets/<uuid.xml> and check where it's pointing?

Recent revisions of the charms have the secret file pointing at <name>client.nova-compute secret</name> on nova-compute nodes rather than the cinder key. Which really only should get used on the cinder node.

Additionally I was unable to reproduce the error similar to "Aug 4 06:37:31 cn1 kernel: [1058976.654848] type=1400 audit(1407101851.714:2102): apparmor="DENIED" operation="open" profile="libvirt-53a1d479-2299-4069-a691-72f3f5ae7a6e" name="/etc/ceph/ceph.client.cinder.keyring" pid=8336 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=110 ouid=108" .