Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of aemneina@gmail.com designates
 209.85.212.170 as permitted sender)
MIME-Version: 1.0
Reply-To: aemneina@gmail.com
In-Reply-To: 
 <CAOBb5ab+hP=LhLMX88zFUz1_jbOwmKfWmd+8jsax=Zw2fx6Kdg@mail.gmail.com>
References: 
 <CAOBb5ab+hP=LhLMX88zFUz1_jbOwmKfWmd+8jsax=Zw2fx6Kdg@mail.gmail.com>
From: Ahmad Emneina <aemneina@gmail.com>
Date: Mon, 12 Aug 2013 14:23:24 -0700
Message-ID: 
 <CAO+D_1zR8cZv=E_46DW890d0fhjM0VCAKenE4CMxg+T1QpFoKw@mail.gmail.com>
Subject: Re: Template Folder Path (KVM/Libvirt)
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=f46d043bdfde373c4704e3c6bd6a

--f46d043bdfde373c4704e3c6bd6a
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d043bdfde373c4704e3c6bd6a--