Hi Dan, Ahmed, Thanks for your response. I can rule out the hypervisor theory as the ms was migrated to a new node and all hypervisors were reinstalled. I had previously used phpMyAdmin to check for the paths and have looked through the database manually (took just over an hour) with no results, I will dump and grep the results tonight, posting the results back to here and dev if I find anything.
Thanks, Marty Sweet On 12 Aug 2013, at 09:02, Daan Hoogland <[email protected]> wrote: > Marty, Ahmad, > > Can this artifact be on the hypervisor instead of in the ms? > > regards, > Daan > > On Mon, Aug 12, 2013 at 6:55 AM, Ahmad Emneina <[email protected]> wrote: >> Hey Marty, I would post this on dev as well... I can only imagine there is >> still an artifact of the old mount name in the db. I'd do a quick dump and >> grep to see if it exists in some table somewhere.... >> >> Ahmad >> >> On Aug 10, 2013, at 5:10 AM, Marty Sweet <[email protected]> wrote: >> >>> 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. 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)
