Template Folder Path (KVM/Libvirt)

[Marty Sweet <ms...@gmail.com>]

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)

Re: Template Folder Path (KVM/Libvirt)

[Ahmad Emneina <ae...@gmail.com>]

just dawned on me, you might have to forget the storage pools (if no vm's
are running) on the hosts. Then reconnect the kvm agents (by restarting the
service on the hosts or from cloudstack-> force reconnect command). they
should get programmed correctly!


On Mon, Aug 12, 2013 at 2:16 PM, Marty Sweet <ms...@gmail.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 (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)
>

Re: Template Folder Path (KVM/Libvirt)

[Wido den Hollander <wi...@widodh.nl>]

On 08/12/2013 11:16 PM, Marty Sweet 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 (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
>

I think it is libvirt which is still caching this data. You are right 
that this data is not stored in the CloudStack database, it doesn't 
care, it simply mounts it under /mnt/<uuid>

Did you reboot the hypervisors afterwards? I'd recommend you do so so 
libvirt doesn't store that data anymore.

Also, make sure all the Instances are restarted, since they might still 
have the path in their XML definitions in libvirt.

Wido

> 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)
>