Re: [Libvirt-cim] [PATCH] [TEST] (#2) Improve enum volumes
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(a)linux.vnet.ibm.com