[libvirt] vol-list and other vol-* functions

Daniel P. Berrange berrange at redhat.com
Tue Jun 1 16:36:32 UTC 2010


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 :|




More information about the libvir-list mailing list