<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<small>Thanks for the response! I'm glad this is possible...<br>
<br>
Opennebula specifies the permissions for files to be used to be
opened up a fair bit, so I made sure the backing store had the
permissions. Also, I'm actually letting opennebula do the
qemu-img line, and it would probably have to do any libvirt lines
as well (the workflow is opennebula kicks off a new machine
process, which sets up the base files including the image
(originally by copying, I'm trying to do that via a snapshot
instead) and the xml file, then creates and boot the machine using
libvirt.<br>
<br>
The backstore is located in ~/public. The apparmor profile
includes the lines:<br>
@{HOME}/ r,<br>
@{HOME}/** r,<br>
<br>
and<br>
/**.img r,<br>
/**.qcow{,2} r,<br>
/**.vmdk r,<br>
/**.[iI][sS][oO] r,<br>
/**/disk{,.*} r,<br>
Under a comment that says "<br>
# For backingstore, virt-aa-helper needs to peek inside the disk
image, so<br>
# allow access to non-hidden files in @{HOME} as well as storage
pools, and<br>
# removable media and filesystems, and certain file extentions.
A<br>
# virt-aa-helper failure when checking a disk for backinsgstore
is non-fatal<br>
# (but obviously the backingstore won't be added).<br>
"<br>
<br>
And from my reading of the apparmor docs, this should allow
access.<br>
<br>
I can't find any apparmor errors in /var/log/kern.log
/var/log/messages. I don't have a /var/log/apparmor or a
/var/log/audit. This is running inside of a chroot (works fine if
I copy the images rather than snapshot), and I can't find any
apparmor errors inside or outside the chroot.<br>
<br>
I also found this:
<a class="moz-txt-link-freetext" href="http://serverfault.com/questions/145834/how-to-convert-a-raw-disk-image-to-a-copy-on-write-image-based-on-another-image">http://serverfault.com/questions/145834/how-to-convert-a-raw-disk-image-to-a-copy-on-write-image-based-on-another-image</a>,
but I think my version of libvirt has the apparmor updates (see
above).<br>
<br>
The other piece I found is from /var/log/libvirt/libvirtd.log:<br>
<br>
21:55:33.603: 6988: error : qemuMonitorOpenUnix:291 : monitor
socket did not show up.: Connection refused<br>
21:55:33.603: 6988: error : qemuProcessWaitForMonitor:1069 :
internal error process exited while connecting to monitor:
file=/var/lib/one/vm/56/images/disk.0,if=none,id=drive-virtio-disk0,boot=on,format=qcow2,cache=none<br>
<br>
But I assume that the monitor socket isn't showing up because it's
not starting because it's not reading the file...<br>
<br>
Any other ideas for how to see if it's attempting to access the
backing file and failing? I apparently don't have strace,
either... :-(</small><br>
<br>
<br>
On 06/06/2012 05:23 PM, Eric Blake wrote:<br>
<span style="white-space: pre;">> On 06/06/2012 10:55 AM, Sean
Abbott wrote:<br>
>> So, I was attempting to use qemu snapshots with backing
stores. The<br>
>> QEMU docs
(<a class="moz-txt-link-freetext" href="http://wiki.qemu.org/Documentation/CreateSnapshot">http://wiki.qemu.org/Documentation/CreateSnapshot</a>) make it<br>
>> sound like you simply point your qemu at the snapshot
after it's<br>
>> creation, and you're golden.<br>
>><br>
>> When attempting this with libvirt, though, it fails.<br>
><br>
> Libvirt definitely supports this, as I use it for my guests,
so let's<br>
> figure out where you went wrong. By the way, libvirt can
create qcow2<br>
> files itself, rather than forcing you to hand-create it with
qemu-img,<br>
> although support for this could probably be improved with
more APIs and<br>
> documentation. Patches welcome.<br>
><br>
>><br>
>> I created a snapshot using the above tutorial. the
resulting file is<br>
>> disk.0, and a qmeu-img info on it returns:<br>
>><br>
>> image: disk.0<br>
>> file format: qcow2<br>
>> virtual size: 29G (31457280000 bytes)<br>
>> disk size: 140K<br>
>> cluster_size: 65536<br>
>> backing file:
/var/lib/one/public/lin_client_current.qcow2 (actual path:<br>
>> /var/lib/one/public/lin_client_current.qcow2)<br>
>><br>
>> So that all looks groovy, right?<br>
><br>
> Unfortunately, 'qemu-img info' output doesn't say whether you
properly<br>
> populated the backing_fmt property, but I will assume that is
not your<br>
> issue (do note, however, that failure to use the backing_fmt
property is<br>
> a security hole - it means libvirt and/or qemu will autoprobe
the format<br>
> from the backing file itself, but if the backing file is
supposed to be<br>
> raw, the guest can manipulate the backing file into looking
non-raw, and<br>
> cause your host to hand over control of files to the guest
that should<br>
> not normally be accessible to the guest).<br>
><br>
>><br>
>> Then, I created (via opennebula) an xml deployment file
like so: <br>
>> <a class="moz-txt-link-freetext" href="http://paste.ubuntu.com/1027145/">http://paste.ubuntu.com/1027145/</a><br>
><br>
> which included:<br>
><br>
> <disk type='file' device='disk'><br>
> <source file='/var/lib/one/vm/56/images/disk.0'/><br>
> <target dev='hda' bus='virtio'/><br>
> <driver name='qemu' type='qcow2' cache='none'/><br>
><br>
> and that looked correct to me.<br>
><br>
>><br>
>> When I attempt to do a virsh create, I get the following
errors:<br>
>><br>
>> virsh # create deployment.0<br>
>> error: Failed to create domain from deployment.0<br>
>> error: internal error process exited while connecting to
monitor:<br>
>>
file=/var/lib/one/vm/56/images/disk.0,if=none,id=drive-virtio-disk0,boot=on,format=qcow2,cache=none<br>
>> qemu-kvm: boot=on|off is deprecated and will be ignored.
Future versions<br>
>> will reject this parameter. Please update your scripts.<br>
><br>
> This warning is not the real problem, but a patch to libvirt
to avoid it<br>
> might be nice, if it hasn't already been patched in newer
libvirt.<br>
><br>
>> qemu-system-x86_64: -drive<br>
>>
file=/var/lib/one/vm/56/images/disk.0,if=none,id=drive-virtio-disk0,boot=on,format=qcow2,cache=none,boot=on:<br>
>> could not open disk image
/var/lib/one/vm/56/images/disk.0: Invalid argument<br>
><br>
> You mentioned Ubuntu - do you have appArmor running? This
could be a<br>
> case of the apparmor settings on your machine preventing qemu
from<br>
> opening the backing file. I don't have Ubuntu experience
myself to tell<br>
> you how to resolve it (I tend to work with SELinux on Fedora
as my<br>
> security mechanism), but suspect that it might be a failure
along the<br>
> lines of an over-strict security policy.<br>
><br>
>><br>
>> So...something isn't working. Is it possible to do this,
or should I<br>
>> give up on this path?<br>
><br>
> Libvirt definitely supports what you want to do, but I don't
know what<br>
> to suggest to help you get further.<br>
></span><br>
<br>
</body>
</html>