[libvirt] vol-list and other vol-* functions
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? Thanks, -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems & Technology Group Mobile: +55 19 8135 0885 eotubo@linux.vnet.ibm.com
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. - Cole
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 :|
participants (3)
-
Cole Robinson -
Daniel P. Berrange -
Eduardo Otubo