Kaitlin Rupert wrote:
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 No I had not tested with the latest revision. Yes this passed with the latest changes.
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.
Yes its essential for us to keep the images in someother directory other than /tmp/ , how about /etc/libvirt-cim like the one we have for /etc/libvirt?
I am not sure if this is the limitation from libvirt side or if its a feature with libvirt. Anyways +1 for these changes.
-- Thanks and Regards, Deepti B. Kalakeri IBM Linux Technology Center deeptik@linux.vnet.ibm.com