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.