You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Marty Sweet <cl...@martysweet.com> on 2013/08/10 14:10:19 UTC
Template Folder Path (KVM/Libvirt)
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)
Re: Template Folder Path (KVM/Libvirt)
Posted by Marty Sweet <ms...@gmail.com>.
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 <da...@gmail.com> 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 <ae...@gmail.com> 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 <cl...@martysweet.com> 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)
Re: Template Folder Path (KVM/Libvirt)
Posted by Daan Hoogland <da...@gmail.com>.
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 <ae...@gmail.com> 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 <cl...@martysweet.com> 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)
Re: Template Folder Path (KVM/Libvirt)
Posted by Ahmad Emneina <ae...@gmail.com>.
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 <cl...@martysweet.com> 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)