[Libvirt-cim] [PATCH] [TEST] (#2) Improve enum volumes

[Kaitlin Rupert]

> The information that libvirt virsh pool-list is returning is not 
> completely correct:
> For ex:
> 
> virsh -c qemu:///system vol-list cimtest-diskpoolName Path
> -----------------------------------------
> .X0-lock /tmp/.X0-lock
> cimtest.uuid /tmp/cimtest.uuid
> default-kvm-dimage /tmp/default-kvm-dimage
> tmpnsIv8q /tmp/tmpnsIv8q
> 
> The last pool information tmpnsIv8q does not seem to exist on the 
> machine, hence when I ran the HostSystem/03_hs_to_settdefcap.py it 
> failed with the following error:
> 
> ------------------------------------------------------------------------------------------------------------------------------- 
> 
> ERROR - 'KVM_SettingsDefineCapabilities' returned 0 RASD objects instead 
> of 16
> CIM_ERR_INVALID_CLASS: Linux_ComputerSystem
> CIM_ERR_FAILED: Unable to get volume information: cannot open volume 
> '/tmp/tmpnsIv8q': No such file or directory
> ------------------------------------------------------------------------------------------------------------------------------- 
> 

Are you running with recent sources? This issue should have been fixed 
with Richard's patch:

"This patch removes the error throwed when volume info cannot be 
extracted in the disk template generation"

rev: 842, changeset: 2f4943568299

> 
> The test case passed after I created the file /tmp/tmpnsIv8q.

Items written to /tmp aren't permanent.  Programs often write temporary 
files here during execution, so we cannot count on all the files in /tmp 
to exist.

Actually, we really shouldn't place our images in /tmp. We should place 
them in something like /var/spool/libvirt-cim?  Some place more 
permanent, and a little more expected from a application.

A good admin would make sure that a directory based pool (the kind of 
pool cimtest creates) would only be populated with images.  So we should 
be doing the same with ours.

> I am not sure if this is the limitation from libvirt side or if its a 
> feature with libvirt.
> Anyways +1 for these changes.

-- 
Kaitlin Rupert
IBM Linux Technology Center
kaitlin at linux.vnet.ibm.com