On 03/28/2013 06:21 AM, Daniel P. Berrange wrote: > We decided on using xattrs, instead of an in-memory record, because we > want the data to be accessible to multiple libvirtd daemons on different > hosts. This does not imply we actually need to store the xattrs on the > files themselves. Perhaps we should have been creating some parallel > files to record the original ownership, which are permanently root > owned. > > eg For a file /var/lib/libvirt/images/foo.img add a > /var/lib/libvirt/images/.libvirt.dac.foo.img file to record the original > information. > > Or as with the lock manager, just use a single directory like > /var/lib/libvirt/dac/ and create files in there based on the SHA256SUM > of the filename, and declare that you must share that directory between > hosts ? Out of the box, libvirt is not set up for sharing unless you mount /var/lib/libvirt/images on shared storage or add your own storage pool pointing to shared storage. Since setting up shared storage pools is already an admin action, I would be okay with also requiring an admin action to set up a shared directory that tracks ownership information across a shared pool. It might also be nice to make it easy to associate a shared subdirectory for metainformation inside any storage pool based on top of a shared directory (although that approach doesn't really scale to other storage pools such as iscsi or LVM where the pool isn't really exposing a file system to hold a subdirectory). For that matter, there have already been requests to allow 'virsh managedsave' dump memory into a storage pool, rather than into /etc, since saved state can occupy a lot more space than the / partition is prepared to handle. Also, we have the question of coming up with a default name for saved state files in external snapshots. Both of these problems would also benefit from the ability to designate where libvirt should stick metadata associated with a storage pool, but where a fallback to a default within /var/lib/libvirt are still okay for out-of-the-box installation on a single machine. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list