On 7/31/12 1:02 AM, "Wido den Hollander" <w...@widodh.nl> wrote:

>
>
>On 07/31/2012 02:32 AM, Kelcey Damage (BBITS) wrote:
>> It would be great if we could look at creating a system (even just a
>>utility
>> script) that would allow us to re-attach a secondary storage server and
>> salvage existing templates housed on it.
>>
>>
>>
>> I'm thinking it could crawl the template tree and prompt the user for a
>>new
>> z/p/c to attach the templates to.
>>
>>
>>
>> If anyone is interested in trying to make this, that would be awesome.
>
>Could you open an issue for this in the bugtracker?
>http://bugs.cloudstack.org/
>
>I get the use-case of this feature, it seems logical to have this.
>
>When a bug is opened it can be picked up by a developer in a later stage.
>
>Wido
>
>>
>>
>>
>> Thanks
>>
>>
>>
>> Kelcey Jamison-Damage
>>
>> Infrastructure Systems Architect
There is a template.properties file in the same directory as the template.
The contents look like this:
#Thu Sep 15 04:28:35 UTC 2011
ova.virtualsize=459320832
filename=2824f035-bd01-3b6a-b029-5705dc26d63f.ova
ova.filename=2824f035-bd01-3b6a-b029-5705dc26d63f.ova
id=7
public=true
uniquename=centos53-x64
virtualsize=2147483648
checksum=
hvm=false
description=centos53-x64
ova=true
ova.size=459320832
physicalSize=459320832
size=459320832


When the SSVM starts up it crawls the template directory and parses each
properties file 
and sends up this info to the management server. The MS correlates this
with the entries in the template_host_ref table and the vm_template table.
If the unique_name matches, the MS should update the template_host_ref
with the size and install location information.

This suggests to me that you can call the registerTemplate API with a
dummy url that should result in a download error. Stop the SSVM (or kill
the java process inside it).
Make sure the template exists in the SS and create an appropriate
template.properties with the same unique name. Restart the SSVM.

Reply via email to