Hi all, I've hit a problem that I have been chewing on for the past few hours. A few months ago I changed the local storage path naming convention (examples below) and updated the corresponding records in the cloudstack database manually. This works great until old templates are used. I understand I could use symlinks to resolve this issue but I would prefer to have a sane dataset and a cleaner setup :)
--> My Physical Volumes <-- /mount/msa0-enc0-vm0 (OLD /mount/enc0-vm) /mount/msa0-enc0-vm1 /mount/msa0-enc1-vm0 (OLD /mount/enc1-vm) /mount/msa0-enc1-vm1 /mount/msa0-enc2-vm0 In the database there is no mention of /mount/enc0-vm or /mount/enc1-vm, from doing a global search on all content (and by dumping the database and grepping the output). However, libvirt still manages to receive commands to add these templates. virStorageBackendFileSystemRefresh:889 : internal error cannot probe backing volume info: /mount/enc1-vm/a0932ff2-e97c-446a-85f2-42ad0fb2cab7 virStorageBackendProbeTarget:118 : internal error cannot probe backing volume format: /mount/enc0-vm/8dc8d179-ac43-4475-812a-3bcc3e5d7b43 These UUID Paths do correspond to templates within the '* template_spool_ref' *table which then *presumably *are linked to `storage_pool` to pick out the folder 'path'? although this should give the correct, new mappings. I can rule out a storage pool issue within libvirt as I resolved that issue when I changed the naming convention and have rechecked it. Unlike VM `volumes`, templates don't seem to possess a folder 'path', the only possible field I can assume is `vm_template.checksum`, which is obviously questionable, but would explain why a plain text search for the old volumes is returning no results. So my question is: How does CS compose template paths and from what parts within the cloudstack database? If these are encrypted (as I am assuming the folder path is somewhere, what is the best way to change these values). Thanks in advance, Marty Sweet (Rapid2214)
