On Tue, Jun 01, 2010 at 12:23:53PM -0400, Cole Robinson wrote: > On 05/31/2010 10:41 AM, Eduardo Otubo wrote: > > Hello all, > > > > When implementing the vol-list function I came up with the concept of > > 'path' which I am not sure if I understood. Does 'path' in this case > > represents where it is mounted on the guest system? On IBM Power > > Hypervisor, there's some logical volumes which I can get the path and > > there's some I can't, hence, I can't get LookUpByPath() function > > implemented correctly. Any ideas? > > > > For the libvirtd provided storage backends, 'path' is the full > filesystem pathname of the storage. So, for a directory pool pointing to > /tmp, a volume target path could be the file /tmp/foo.img > > If your storage backend doesn't have a notion of a 'path', maybe just > come up with some heirarchical name like /poolname/volname. Ideally the > path would be something unique to that piece of storage, so that > LookUpByPath wouldn't hit multiple storage volumes.. Also, I'd try match > up the storage path with whatever system you use to specify storage in > the domain XML. The second thing is the critical requirement. It is recommended that a volume path be a path that's visible on the host filesytem, but this is not a mandatory requirement. The only mandatory requirement is that whatever is used as the volume path, must also be valid in the domain XML disk paths. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list