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.