On 10/31/2012 03:51 AM, Douglas Russell wrote: >> What is typically done is creating LVM volumes in the host, and then >> assigning that as a block device for the guest to use as though it were >> a raw disk. The guest then does _another_ layer of PVM/LVM >> partitioning, if the guest is something that uses LVM in the first >> place. If you want the guest to see an LVM partition created by the >> host as an LVM within the guest, without an additional layer, then you >> have to expose the PVM as the block device to the guest; this is not a >> typical setup, in part because it is then up to you to ensure that the >> host and guest are not modifying the same storage at the same time (or >> put another way, that the guest is not reading from any other LVM >> partitions than the one you wanted it to use). >> > > Ok, I understand your answer and I feel I'm close to the solution, but I'm > still unclear on the storage pools part. In what you've described below, > these aren't used? I assume you've used attach-disk to add the LVM volume > to the guest as a block device? I definitely never intended to add the > logical volume to the guest and have it appear as a logical volume. I was, > as you say, trying to attach it as a block device. Right now, we have a disconnect in the libvirt design, that I'd like to fix someday. virDomainPtr <domain> XML could care less that storage pools exist - it only cares about <disk> elements having an absolute path to storage, and the storage does not have to belong to a pool. Likewise, virStoragePoolPtr and virStorageVolPtr could care less that domains exist - they only care that storage volumes belong to a storage pool (that is, virStorageVolPtr can't exist without a pool). What I _want_ to have, someday in the future, is the ability to have an alternate XML representation for <domain> that lets you list pool=poolname volume=volname instead of path=/path/to/name. I'd also like to have API that given a domain, you can get back virStorageVolPtr for every disk referenced by that domain, even if it means creating transient virStoragePoolPtr for the directory containing the path; that means that EVERY disk image would belong to a pool, whether or not you explicitly created a pool. Conversely, I'd also like an API that given a virStorageVolPtr, you can then get at all other volumes and domains that are currently referring to the storage volume (either as domain <disk> or as backing files of things like qcow2 files). But since that does not exist, all you need to know now is that if you want libvirt to help you create LVM volumes, then create a storage pool; but if the LVM volumes are already created, merely set the <disk> in your domain to point to its absolute path, without having to worry about pools. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
