You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Ivan Kudryavtsev <ku...@bw-sw.com> on 2019/04/15 13:40:29 UTC
CloudStack 4.11.2 SS problem
Hello, community.
Today, We've met the problem with ACS SS, which looks like a critical
error. In some point of time, new templates stopped to upload and the old
ones were unable to be removed.
After the SSVM recreation, I've met the situation when some templates are
not activated and have their "template.properties" size set to 0.
More to add, certain already working templates were tried to be
redownloaded and got errors like:
Failed post download script: checksum
"{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given value,
"{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
I've checked the following:
- no lack of spare space on SS;
- no problems with management servers in the last months;
- no problems with SSVM.
It's ACS 4.11.2, all VMs are working, of course as templates are copied to
primary, but we've lost almost half of the template repository.
Is there a way to recreate "template.properties" from DB or another
approach? All the templates are still in place, but they are not activated
upon SSVM start.
Many thanks.
--
With best regards, Ivan Kudryavtsev
Bitworks LLC
Cell RU: +7-923-414-1515
Cell USA: +1-201-257-1512
WWW: http://bitworks.software/ <http://bw-sw.com/>
Re: CloudStack 4.11.2 SS problem
Posted by Andrija Panic <an...@gmail.com>.
I agree that would be a bug Ivan, but please try to confirm what happened
actually through logs ?
Now that I checked, I do recall one similar case actually, where template
seems to be present physically on storage (images itself that is - can you
also confirm your templates are present on SS, beside template.properties
being nulled ???) - and also template is present in template_zone_ref.
Can you please do the check above ?
I'm wondering what else you might be missing (if anything) in DB or on SS
filesystem, beside the row in the template_store_ref.
On Mon, 15 Apr 2019 at 18:38, Ivan Kudryavtsev <ku...@bw-sw.com>
wrote:
> Well, we don't remove templates usually, just rename them and reset public,
> featured flags.
>
> I'll check, but suppose, that template api removal call shouldn't produce
> the case like this? How this could be achieved thru API, when storage_ref
> is removed, but template is in place?
>
> The records for certain templates are absent in template_store_ref, while
> others are just fine... it looks like a very serious bug for regular users,
> who don't manage templates and ISO programmatically.
>
> пн, 15 апр. 2019 г., 12:21 Andrija Panic <an...@gmail.com>:
>
> > Assuming it's not Assange :), perhaps check with teammates if any changes
> > on these templates were done - are your records completely missing or
> just
> > altered in bad way ?
> >
> > Can you double check the API log for any delete template API calls ?
> >
> >
> > On Mon, 15 Apr 2019 at 17:39, Ivan Kudryavtsev <kudryavtsev_ia@bw-sw.com
> >
> > wrote:
> >
> > > Andrija,
> > >
> > > yes, I have the case with missing records in 'template_store_ref'.
> What I
> > > don't get is how it could happen...
> > >
> > > пн, 15 апр. 2019 г. в 11:24, Andrija Panic <an...@gmail.com>:
> > >
> > > > Hi Ivan,
> > > >
> > > > is it possible that your DB got somehow corrupted or that you are
> > missing
> > > > records in template_store_ref etc - this might be the reason why
> SSVM
> > is
> > > > trying to download templates again - if you check the logs for
> > > > non-problematic templates, you will see something like "template
> > already
> > > on
> > > > store this and that, no need to download again, skipping". For the
> rest
> > > > (which are considered not downloaded), it will try to download again
> > from
> > > > the URL in the main vm_template table.
> > > >
> > > > Can you also check for the records on the template_spool_ref (Primary
> > > > Storage) - I assume these might be OK, ca you spin new VM from an
> > > existing
> > > > (problematic) template ?
> > > >
> > > > Behavior (from your second email) is expected - same kind of errors
> you
> > > > would get if you just added another Secondary Storage to your
> > CloudStack
> > > > setup, but original URL is unavailable (you could play with hacking
> MD5
> > > in
> > > > DB, but that is not a solution at all).
> > > >
> > > > As for the restoration of the template.properties - do you have a
> > backup
> > > ?
> > > >
> > > > Best,
> > > > Andrija
> > > >
> > > > On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev <
> > kudryavtsev_ia@bw-sw.com
> > > >
> > > > wrote:
> > > >
> > > > > To follow up. When SSVM boots it tries to redownload all the
> > templates
> > > > from
> > > > > original sources this leads to next oucomes:
> > > > > - if the source is not available, the result is:
> > > > > No route to host (Host unreachable) - If the template is changed on
> > > > source:
> > > > > then it leads to MD5 sum error.
> > > > >
> > > > > Any ideas, why SSVM tries to download all the templates on SSVM
> > again?
> > > > > Never seen that before.
> > > > >
> > > > >
> > > > > пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <
> > > kudryavtsev_ia@bw-sw.com
> > > > >:
> > > > >
> > > > > > Hello, community.
> > > > > >
> > > > > > Today, We've met the problem with ACS SS, which looks like a
> > critical
> > > > > > error. In some point of time, new templates stopped to upload and
> > the
> > > > old
> > > > > > ones were unable to be removed.
> > > > > >
> > > > > > After the SSVM recreation, I've met the situation when some
> > templates
> > > > are
> > > > > > not activated and have their "template.properties" size set to 0.
> > > > > >
> > > > > > More to add, certain already working templates were tried to be
> > > > > > redownloaded and got errors like:
> > > > > > Failed post download script: checksum
> > > > > > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given
> > value,
> > > > > > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> > > > > > I've checked the following:
> > > > > > - no lack of spare space on SS;
> > > > > > - no problems with management servers in the last months;
> > > > > > - no problems with SSVM.
> > > > > >
> > > > > > It's ACS 4.11.2, all VMs are working, of course as templates are
> > > copied
> > > > > to
> > > > > > primary, but we've lost almost half of the template repository.
> > > > > >
> > > > > > Is there a way to recreate "template.properties" from DB or
> another
> > > > > > approach? All the templates are still in place, but they are not
> > > > > activated
> > > > > > upon SSVM start.
> > > > > >
> > > > > > Many thanks.
> > > > > >
> > > > > >
> > > > > > --
> > > > > > With best regards, Ivan Kudryavtsev
> > > > > > Bitworks LLC
> > > > > > Cell RU: +7-923-414-1515
> > > > > > Cell USA: +1-201-257-1512
> > > > > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > With best regards, Ivan Kudryavtsev
> > > > > Bitworks LLC
> > > > > Cell RU: +7-923-414-1515
> > > > > Cell USA: +1-201-257-1512
> > > > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Andrija Panić
> > > >
> > >
> > >
> > > --
> > > With best regards, Ivan Kudryavtsev
> > > Bitworks LLC
> > > Cell RU: +7-923-414-1515
> > > Cell USA: +1-201-257-1512
> > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > >
> >
> >
> > --
> >
> > Andrija Panić
> >
>
--
Andrija Panić
Re: CloudStack 4.11.2 SS problem
Posted by Andrija Panic <an...@gmail.com>.
I agree that would be a bug Ivan, but please try to confirm what happened
actually through logs ?
Now that I checked, I do recall one similar case actually, where template
seems to be present physically on storage (images itself that is - can you
also confirm your templates are present on SS, beside template.properties
being nulled ???) - and also template is present in template_zone_ref.
Can you please do the check above ?
I'm wondering what else you might be missing (if anything) in DB or on SS
filesystem, beside the row in the template_store_ref.
On Mon, 15 Apr 2019 at 18:38, Ivan Kudryavtsev <ku...@bw-sw.com>
wrote:
> Well, we don't remove templates usually, just rename them and reset public,
> featured flags.
>
> I'll check, but suppose, that template api removal call shouldn't produce
> the case like this? How this could be achieved thru API, when storage_ref
> is removed, but template is in place?
>
> The records for certain templates are absent in template_store_ref, while
> others are just fine... it looks like a very serious bug for regular users,
> who don't manage templates and ISO programmatically.
>
> пн, 15 апр. 2019 г., 12:21 Andrija Panic <an...@gmail.com>:
>
> > Assuming it's not Assange :), perhaps check with teammates if any changes
> > on these templates were done - are your records completely missing or
> just
> > altered in bad way ?
> >
> > Can you double check the API log for any delete template API calls ?
> >
> >
> > On Mon, 15 Apr 2019 at 17:39, Ivan Kudryavtsev <kudryavtsev_ia@bw-sw.com
> >
> > wrote:
> >
> > > Andrija,
> > >
> > > yes, I have the case with missing records in 'template_store_ref'.
> What I
> > > don't get is how it could happen...
> > >
> > > пн, 15 апр. 2019 г. в 11:24, Andrija Panic <an...@gmail.com>:
> > >
> > > > Hi Ivan,
> > > >
> > > > is it possible that your DB got somehow corrupted or that you are
> > missing
> > > > records in template_store_ref etc - this might be the reason why
> SSVM
> > is
> > > > trying to download templates again - if you check the logs for
> > > > non-problematic templates, you will see something like "template
> > already
> > > on
> > > > store this and that, no need to download again, skipping". For the
> rest
> > > > (which are considered not downloaded), it will try to download again
> > from
> > > > the URL in the main vm_template table.
> > > >
> > > > Can you also check for the records on the template_spool_ref (Primary
> > > > Storage) - I assume these might be OK, ca you spin new VM from an
> > > existing
> > > > (problematic) template ?
> > > >
> > > > Behavior (from your second email) is expected - same kind of errors
> you
> > > > would get if you just added another Secondary Storage to your
> > CloudStack
> > > > setup, but original URL is unavailable (you could play with hacking
> MD5
> > > in
> > > > DB, but that is not a solution at all).
> > > >
> > > > As for the restoration of the template.properties - do you have a
> > backup
> > > ?
> > > >
> > > > Best,
> > > > Andrija
> > > >
> > > > On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev <
> > kudryavtsev_ia@bw-sw.com
> > > >
> > > > wrote:
> > > >
> > > > > To follow up. When SSVM boots it tries to redownload all the
> > templates
> > > > from
> > > > > original sources this leads to next oucomes:
> > > > > - if the source is not available, the result is:
> > > > > No route to host (Host unreachable) - If the template is changed on
> > > > source:
> > > > > then it leads to MD5 sum error.
> > > > >
> > > > > Any ideas, why SSVM tries to download all the templates on SSVM
> > again?
> > > > > Never seen that before.
> > > > >
> > > > >
> > > > > пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <
> > > kudryavtsev_ia@bw-sw.com
> > > > >:
> > > > >
> > > > > > Hello, community.
> > > > > >
> > > > > > Today, We've met the problem with ACS SS, which looks like a
> > critical
> > > > > > error. In some point of time, new templates stopped to upload and
> > the
> > > > old
> > > > > > ones were unable to be removed.
> > > > > >
> > > > > > After the SSVM recreation, I've met the situation when some
> > templates
> > > > are
> > > > > > not activated and have their "template.properties" size set to 0.
> > > > > >
> > > > > > More to add, certain already working templates were tried to be
> > > > > > redownloaded and got errors like:
> > > > > > Failed post download script: checksum
> > > > > > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given
> > value,
> > > > > > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> > > > > > I've checked the following:
> > > > > > - no lack of spare space on SS;
> > > > > > - no problems with management servers in the last months;
> > > > > > - no problems with SSVM.
> > > > > >
> > > > > > It's ACS 4.11.2, all VMs are working, of course as templates are
> > > copied
> > > > > to
> > > > > > primary, but we've lost almost half of the template repository.
> > > > > >
> > > > > > Is there a way to recreate "template.properties" from DB or
> another
> > > > > > approach? All the templates are still in place, but they are not
> > > > > activated
> > > > > > upon SSVM start.
> > > > > >
> > > > > > Many thanks.
> > > > > >
> > > > > >
> > > > > > --
> > > > > > With best regards, Ivan Kudryavtsev
> > > > > > Bitworks LLC
> > > > > > Cell RU: +7-923-414-1515
> > > > > > Cell USA: +1-201-257-1512
> > > > > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > With best regards, Ivan Kudryavtsev
> > > > > Bitworks LLC
> > > > > Cell RU: +7-923-414-1515
> > > > > Cell USA: +1-201-257-1512
> > > > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Andrija Panić
> > > >
> > >
> > >
> > > --
> > > With best regards, Ivan Kudryavtsev
> > > Bitworks LLC
> > > Cell RU: +7-923-414-1515
> > > Cell USA: +1-201-257-1512
> > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > >
> >
> >
> > --
> >
> > Andrija Panić
> >
>
--
Andrija Panić
Re: CloudStack 4.11.2 SS problem
Posted by Ivan Kudryavtsev <ku...@bw-sw.com>.
Well, we don't remove templates usually, just rename them and reset public,
featured flags.
I'll check, but suppose, that template api removal call shouldn't produce
the case like this? How this could be achieved thru API, when storage_ref
is removed, but template is in place?
The records for certain templates are absent in template_store_ref, while
others are just fine... it looks like a very serious bug for regular users,
who don't manage templates and ISO programmatically.
пн, 15 апр. 2019 г., 12:21 Andrija Panic <an...@gmail.com>:
> Assuming it's not Assange :), perhaps check with teammates if any changes
> on these templates were done - are your records completely missing or just
> altered in bad way ?
>
> Can you double check the API log for any delete template API calls ?
>
>
> On Mon, 15 Apr 2019 at 17:39, Ivan Kudryavtsev <ku...@bw-sw.com>
> wrote:
>
> > Andrija,
> >
> > yes, I have the case with missing records in 'template_store_ref'. What I
> > don't get is how it could happen...
> >
> > пн, 15 апр. 2019 г. в 11:24, Andrija Panic <an...@gmail.com>:
> >
> > > Hi Ivan,
> > >
> > > is it possible that your DB got somehow corrupted or that you are
> missing
> > > records in template_store_ref etc - this might be the reason why SSVM
> is
> > > trying to download templates again - if you check the logs for
> > > non-problematic templates, you will see something like "template
> already
> > on
> > > store this and that, no need to download again, skipping". For the rest
> > > (which are considered not downloaded), it will try to download again
> from
> > > the URL in the main vm_template table.
> > >
> > > Can you also check for the records on the template_spool_ref (Primary
> > > Storage) - I assume these might be OK, ca you spin new VM from an
> > existing
> > > (problematic) template ?
> > >
> > > Behavior (from your second email) is expected - same kind of errors you
> > > would get if you just added another Secondary Storage to your
> CloudStack
> > > setup, but original URL is unavailable (you could play with hacking MD5
> > in
> > > DB, but that is not a solution at all).
> > >
> > > As for the restoration of the template.properties - do you have a
> backup
> > ?
> > >
> > > Best,
> > > Andrija
> > >
> > > On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev <
> kudryavtsev_ia@bw-sw.com
> > >
> > > wrote:
> > >
> > > > To follow up. When SSVM boots it tries to redownload all the
> templates
> > > from
> > > > original sources this leads to next oucomes:
> > > > - if the source is not available, the result is:
> > > > No route to host (Host unreachable) - If the template is changed on
> > > source:
> > > > then it leads to MD5 sum error.
> > > >
> > > > Any ideas, why SSVM tries to download all the templates on SSVM
> again?
> > > > Never seen that before.
> > > >
> > > >
> > > > пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <
> > kudryavtsev_ia@bw-sw.com
> > > >:
> > > >
> > > > > Hello, community.
> > > > >
> > > > > Today, We've met the problem with ACS SS, which looks like a
> critical
> > > > > error. In some point of time, new templates stopped to upload and
> the
> > > old
> > > > > ones were unable to be removed.
> > > > >
> > > > > After the SSVM recreation, I've met the situation when some
> templates
> > > are
> > > > > not activated and have their "template.properties" size set to 0.
> > > > >
> > > > > More to add, certain already working templates were tried to be
> > > > > redownloaded and got errors like:
> > > > > Failed post download script: checksum
> > > > > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given
> value,
> > > > > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> > > > > I've checked the following:
> > > > > - no lack of spare space on SS;
> > > > > - no problems with management servers in the last months;
> > > > > - no problems with SSVM.
> > > > >
> > > > > It's ACS 4.11.2, all VMs are working, of course as templates are
> > copied
> > > > to
> > > > > primary, but we've lost almost half of the template repository.
> > > > >
> > > > > Is there a way to recreate "template.properties" from DB or another
> > > > > approach? All the templates are still in place, but they are not
> > > > activated
> > > > > upon SSVM start.
> > > > >
> > > > > Many thanks.
> > > > >
> > > > >
> > > > > --
> > > > > With best regards, Ivan Kudryavtsev
> > > > > Bitworks LLC
> > > > > Cell RU: +7-923-414-1515
> > > > > Cell USA: +1-201-257-1512
> > > > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > > > >
> > > > >
> > > >
> > > > --
> > > > With best regards, Ivan Kudryavtsev
> > > > Bitworks LLC
> > > > Cell RU: +7-923-414-1515
> > > > Cell USA: +1-201-257-1512
> > > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > > >
> > >
> > >
> > > --
> > >
> > > Andrija Panić
> > >
> >
> >
> > --
> > With best regards, Ivan Kudryavtsev
> > Bitworks LLC
> > Cell RU: +7-923-414-1515
> > Cell USA: +1-201-257-1512
> > WWW: http://bitworks.software/ <http://bw-sw.com/>
> >
>
>
> --
>
> Andrija Panić
>
Re: CloudStack 4.11.2 SS problem
Posted by Ivan Kudryavtsev <ku...@bw-sw.com>.
Well, we don't remove templates usually, just rename them and reset public,
featured flags.
I'll check, but suppose, that template api removal call shouldn't produce
the case like this? How this could be achieved thru API, when storage_ref
is removed, but template is in place?
The records for certain templates are absent in template_store_ref, while
others are just fine... it looks like a very serious bug for regular users,
who don't manage templates and ISO programmatically.
пн, 15 апр. 2019 г., 12:21 Andrija Panic <an...@gmail.com>:
> Assuming it's not Assange :), perhaps check with teammates if any changes
> on these templates were done - are your records completely missing or just
> altered in bad way ?
>
> Can you double check the API log for any delete template API calls ?
>
>
> On Mon, 15 Apr 2019 at 17:39, Ivan Kudryavtsev <ku...@bw-sw.com>
> wrote:
>
> > Andrija,
> >
> > yes, I have the case with missing records in 'template_store_ref'. What I
> > don't get is how it could happen...
> >
> > пн, 15 апр. 2019 г. в 11:24, Andrija Panic <an...@gmail.com>:
> >
> > > Hi Ivan,
> > >
> > > is it possible that your DB got somehow corrupted or that you are
> missing
> > > records in template_store_ref etc - this might be the reason why SSVM
> is
> > > trying to download templates again - if you check the logs for
> > > non-problematic templates, you will see something like "template
> already
> > on
> > > store this and that, no need to download again, skipping". For the rest
> > > (which are considered not downloaded), it will try to download again
> from
> > > the URL in the main vm_template table.
> > >
> > > Can you also check for the records on the template_spool_ref (Primary
> > > Storage) - I assume these might be OK, ca you spin new VM from an
> > existing
> > > (problematic) template ?
> > >
> > > Behavior (from your second email) is expected - same kind of errors you
> > > would get if you just added another Secondary Storage to your
> CloudStack
> > > setup, but original URL is unavailable (you could play with hacking MD5
> > in
> > > DB, but that is not a solution at all).
> > >
> > > As for the restoration of the template.properties - do you have a
> backup
> > ?
> > >
> > > Best,
> > > Andrija
> > >
> > > On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev <
> kudryavtsev_ia@bw-sw.com
> > >
> > > wrote:
> > >
> > > > To follow up. When SSVM boots it tries to redownload all the
> templates
> > > from
> > > > original sources this leads to next oucomes:
> > > > - if the source is not available, the result is:
> > > > No route to host (Host unreachable) - If the template is changed on
> > > source:
> > > > then it leads to MD5 sum error.
> > > >
> > > > Any ideas, why SSVM tries to download all the templates on SSVM
> again?
> > > > Never seen that before.
> > > >
> > > >
> > > > пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <
> > kudryavtsev_ia@bw-sw.com
> > > >:
> > > >
> > > > > Hello, community.
> > > > >
> > > > > Today, We've met the problem with ACS SS, which looks like a
> critical
> > > > > error. In some point of time, new templates stopped to upload and
> the
> > > old
> > > > > ones were unable to be removed.
> > > > >
> > > > > After the SSVM recreation, I've met the situation when some
> templates
> > > are
> > > > > not activated and have their "template.properties" size set to 0.
> > > > >
> > > > > More to add, certain already working templates were tried to be
> > > > > redownloaded and got errors like:
> > > > > Failed post download script: checksum
> > > > > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given
> value,
> > > > > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> > > > > I've checked the following:
> > > > > - no lack of spare space on SS;
> > > > > - no problems with management servers in the last months;
> > > > > - no problems with SSVM.
> > > > >
> > > > > It's ACS 4.11.2, all VMs are working, of course as templates are
> > copied
> > > > to
> > > > > primary, but we've lost almost half of the template repository.
> > > > >
> > > > > Is there a way to recreate "template.properties" from DB or another
> > > > > approach? All the templates are still in place, but they are not
> > > > activated
> > > > > upon SSVM start.
> > > > >
> > > > > Many thanks.
> > > > >
> > > > >
> > > > > --
> > > > > With best regards, Ivan Kudryavtsev
> > > > > Bitworks LLC
> > > > > Cell RU: +7-923-414-1515
> > > > > Cell USA: +1-201-257-1512
> > > > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > > > >
> > > > >
> > > >
> > > > --
> > > > With best regards, Ivan Kudryavtsev
> > > > Bitworks LLC
> > > > Cell RU: +7-923-414-1515
> > > > Cell USA: +1-201-257-1512
> > > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > > >
> > >
> > >
> > > --
> > >
> > > Andrija Panić
> > >
> >
> >
> > --
> > With best regards, Ivan Kudryavtsev
> > Bitworks LLC
> > Cell RU: +7-923-414-1515
> > Cell USA: +1-201-257-1512
> > WWW: http://bitworks.software/ <http://bw-sw.com/>
> >
>
>
> --
>
> Andrija Panić
>
Re: CloudStack 4.11.2 SS problem
Posted by Andrija Panic <an...@gmail.com>.
Assuming it's not Assange :), perhaps check with teammates if any changes
on these templates were done - are your records completely missing or just
altered in bad way ?
Can you double check the API log for any delete template API calls ?
On Mon, 15 Apr 2019 at 17:39, Ivan Kudryavtsev <ku...@bw-sw.com>
wrote:
> Andrija,
>
> yes, I have the case with missing records in 'template_store_ref'. What I
> don't get is how it could happen...
>
> пн, 15 апр. 2019 г. в 11:24, Andrija Panic <an...@gmail.com>:
>
> > Hi Ivan,
> >
> > is it possible that your DB got somehow corrupted or that you are missing
> > records in template_store_ref etc - this might be the reason why SSVM is
> > trying to download templates again - if you check the logs for
> > non-problematic templates, you will see something like "template already
> on
> > store this and that, no need to download again, skipping". For the rest
> > (which are considered not downloaded), it will try to download again from
> > the URL in the main vm_template table.
> >
> > Can you also check for the records on the template_spool_ref (Primary
> > Storage) - I assume these might be OK, ca you spin new VM from an
> existing
> > (problematic) template ?
> >
> > Behavior (from your second email) is expected - same kind of errors you
> > would get if you just added another Secondary Storage to your CloudStack
> > setup, but original URL is unavailable (you could play with hacking MD5
> in
> > DB, but that is not a solution at all).
> >
> > As for the restoration of the template.properties - do you have a backup
> ?
> >
> > Best,
> > Andrija
> >
> > On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev <kudryavtsev_ia@bw-sw.com
> >
> > wrote:
> >
> > > To follow up. When SSVM boots it tries to redownload all the templates
> > from
> > > original sources this leads to next oucomes:
> > > - if the source is not available, the result is:
> > > No route to host (Host unreachable) - If the template is changed on
> > source:
> > > then it leads to MD5 sum error.
> > >
> > > Any ideas, why SSVM tries to download all the templates on SSVM again?
> > > Never seen that before.
> > >
> > >
> > > пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <
> kudryavtsev_ia@bw-sw.com
> > >:
> > >
> > > > Hello, community.
> > > >
> > > > Today, We've met the problem with ACS SS, which looks like a critical
> > > > error. In some point of time, new templates stopped to upload and the
> > old
> > > > ones were unable to be removed.
> > > >
> > > > After the SSVM recreation, I've met the situation when some templates
> > are
> > > > not activated and have their "template.properties" size set to 0.
> > > >
> > > > More to add, certain already working templates were tried to be
> > > > redownloaded and got errors like:
> > > > Failed post download script: checksum
> > > > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given value,
> > > > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> > > > I've checked the following:
> > > > - no lack of spare space on SS;
> > > > - no problems with management servers in the last months;
> > > > - no problems with SSVM.
> > > >
> > > > It's ACS 4.11.2, all VMs are working, of course as templates are
> copied
> > > to
> > > > primary, but we've lost almost half of the template repository.
> > > >
> > > > Is there a way to recreate "template.properties" from DB or another
> > > > approach? All the templates are still in place, but they are not
> > > activated
> > > > upon SSVM start.
> > > >
> > > > Many thanks.
> > > >
> > > >
> > > > --
> > > > With best regards, Ivan Kudryavtsev
> > > > Bitworks LLC
> > > > Cell RU: +7-923-414-1515
> > > > Cell USA: +1-201-257-1512
> > > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > > >
> > > >
> > >
> > > --
> > > With best regards, Ivan Kudryavtsev
> > > Bitworks LLC
> > > Cell RU: +7-923-414-1515
> > > Cell USA: +1-201-257-1512
> > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > >
> >
> >
> > --
> >
> > Andrija Panić
> >
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ <http://bw-sw.com/>
>
--
Andrija Panić
Re: CloudStack 4.11.2 SS problem
Posted by Andrija Panic <an...@gmail.com>.
Assuming it's not Assange :), perhaps check with teammates if any changes
on these templates were done - are your records completely missing or just
altered in bad way ?
Can you double check the API log for any delete template API calls ?
On Mon, 15 Apr 2019 at 17:39, Ivan Kudryavtsev <ku...@bw-sw.com>
wrote:
> Andrija,
>
> yes, I have the case with missing records in 'template_store_ref'. What I
> don't get is how it could happen...
>
> пн, 15 апр. 2019 г. в 11:24, Andrija Panic <an...@gmail.com>:
>
> > Hi Ivan,
> >
> > is it possible that your DB got somehow corrupted or that you are missing
> > records in template_store_ref etc - this might be the reason why SSVM is
> > trying to download templates again - if you check the logs for
> > non-problematic templates, you will see something like "template already
> on
> > store this and that, no need to download again, skipping". For the rest
> > (which are considered not downloaded), it will try to download again from
> > the URL in the main vm_template table.
> >
> > Can you also check for the records on the template_spool_ref (Primary
> > Storage) - I assume these might be OK, ca you spin new VM from an
> existing
> > (problematic) template ?
> >
> > Behavior (from your second email) is expected - same kind of errors you
> > would get if you just added another Secondary Storage to your CloudStack
> > setup, but original URL is unavailable (you could play with hacking MD5
> in
> > DB, but that is not a solution at all).
> >
> > As for the restoration of the template.properties - do you have a backup
> ?
> >
> > Best,
> > Andrija
> >
> > On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev <kudryavtsev_ia@bw-sw.com
> >
> > wrote:
> >
> > > To follow up. When SSVM boots it tries to redownload all the templates
> > from
> > > original sources this leads to next oucomes:
> > > - if the source is not available, the result is:
> > > No route to host (Host unreachable) - If the template is changed on
> > source:
> > > then it leads to MD5 sum error.
> > >
> > > Any ideas, why SSVM tries to download all the templates on SSVM again?
> > > Never seen that before.
> > >
> > >
> > > пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <
> kudryavtsev_ia@bw-sw.com
> > >:
> > >
> > > > Hello, community.
> > > >
> > > > Today, We've met the problem with ACS SS, which looks like a critical
> > > > error. In some point of time, new templates stopped to upload and the
> > old
> > > > ones were unable to be removed.
> > > >
> > > > After the SSVM recreation, I've met the situation when some templates
> > are
> > > > not activated and have their "template.properties" size set to 0.
> > > >
> > > > More to add, certain already working templates were tried to be
> > > > redownloaded and got errors like:
> > > > Failed post download script: checksum
> > > > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given value,
> > > > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> > > > I've checked the following:
> > > > - no lack of spare space on SS;
> > > > - no problems with management servers in the last months;
> > > > - no problems with SSVM.
> > > >
> > > > It's ACS 4.11.2, all VMs are working, of course as templates are
> copied
> > > to
> > > > primary, but we've lost almost half of the template repository.
> > > >
> > > > Is there a way to recreate "template.properties" from DB or another
> > > > approach? All the templates are still in place, but they are not
> > > activated
> > > > upon SSVM start.
> > > >
> > > > Many thanks.
> > > >
> > > >
> > > > --
> > > > With best regards, Ivan Kudryavtsev
> > > > Bitworks LLC
> > > > Cell RU: +7-923-414-1515
> > > > Cell USA: +1-201-257-1512
> > > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > > >
> > > >
> > >
> > > --
> > > With best regards, Ivan Kudryavtsev
> > > Bitworks LLC
> > > Cell RU: +7-923-414-1515
> > > Cell USA: +1-201-257-1512
> > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > >
> >
> >
> > --
> >
> > Andrija Panić
> >
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ <http://bw-sw.com/>
>
--
Andrija Panić
Re: CloudStack 4.11.2 SS problem
Posted by Ivan Kudryavtsev <ku...@bw-sw.com>.
Andrija,
yes, I have the case with missing records in 'template_store_ref'. What I
don't get is how it could happen...
пн, 15 апр. 2019 г. в 11:24, Andrija Panic <an...@gmail.com>:
> Hi Ivan,
>
> is it possible that your DB got somehow corrupted or that you are missing
> records in template_store_ref etc - this might be the reason why SSVM is
> trying to download templates again - if you check the logs for
> non-problematic templates, you will see something like "template already on
> store this and that, no need to download again, skipping". For the rest
> (which are considered not downloaded), it will try to download again from
> the URL in the main vm_template table.
>
> Can you also check for the records on the template_spool_ref (Primary
> Storage) - I assume these might be OK, ca you spin new VM from an existing
> (problematic) template ?
>
> Behavior (from your second email) is expected - same kind of errors you
> would get if you just added another Secondary Storage to your CloudStack
> setup, but original URL is unavailable (you could play with hacking MD5 in
> DB, but that is not a solution at all).
>
> As for the restoration of the template.properties - do you have a backup ?
>
> Best,
> Andrija
>
> On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev <ku...@bw-sw.com>
> wrote:
>
> > To follow up. When SSVM boots it tries to redownload all the templates
> from
> > original sources this leads to next oucomes:
> > - if the source is not available, the result is:
> > No route to host (Host unreachable) - If the template is changed on
> source:
> > then it leads to MD5 sum error.
> >
> > Any ideas, why SSVM tries to download all the templates on SSVM again?
> > Never seen that before.
> >
> >
> > пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <kudryavtsev_ia@bw-sw.com
> >:
> >
> > > Hello, community.
> > >
> > > Today, We've met the problem with ACS SS, which looks like a critical
> > > error. In some point of time, new templates stopped to upload and the
> old
> > > ones were unable to be removed.
> > >
> > > After the SSVM recreation, I've met the situation when some templates
> are
> > > not activated and have their "template.properties" size set to 0.
> > >
> > > More to add, certain already working templates were tried to be
> > > redownloaded and got errors like:
> > > Failed post download script: checksum
> > > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given value,
> > > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> > > I've checked the following:
> > > - no lack of spare space on SS;
> > > - no problems with management servers in the last months;
> > > - no problems with SSVM.
> > >
> > > It's ACS 4.11.2, all VMs are working, of course as templates are copied
> > to
> > > primary, but we've lost almost half of the template repository.
> > >
> > > Is there a way to recreate "template.properties" from DB or another
> > > approach? All the templates are still in place, but they are not
> > activated
> > > upon SSVM start.
> > >
> > > Many thanks.
> > >
> > >
> > > --
> > > With best regards, Ivan Kudryavtsev
> > > Bitworks LLC
> > > Cell RU: +7-923-414-1515
> > > Cell USA: +1-201-257-1512
> > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > >
> > >
> >
> > --
> > With best regards, Ivan Kudryavtsev
> > Bitworks LLC
> > Cell RU: +7-923-414-1515
> > Cell USA: +1-201-257-1512
> > WWW: http://bitworks.software/ <http://bw-sw.com/>
> >
>
>
> --
>
> Andrija Panić
>
--
With best regards, Ivan Kudryavtsev
Bitworks LLC
Cell RU: +7-923-414-1515
Cell USA: +1-201-257-1512
WWW: http://bitworks.software/ <http://bw-sw.com/>
Re: CloudStack 4.11.2 SS problem
Posted by Ivan Kudryavtsev <ku...@bw-sw.com>.
Andrija,
yes, I have the case with missing records in 'template_store_ref'. What I
don't get is how it could happen...
пн, 15 апр. 2019 г. в 11:24, Andrija Panic <an...@gmail.com>:
> Hi Ivan,
>
> is it possible that your DB got somehow corrupted or that you are missing
> records in template_store_ref etc - this might be the reason why SSVM is
> trying to download templates again - if you check the logs for
> non-problematic templates, you will see something like "template already on
> store this and that, no need to download again, skipping". For the rest
> (which are considered not downloaded), it will try to download again from
> the URL in the main vm_template table.
>
> Can you also check for the records on the template_spool_ref (Primary
> Storage) - I assume these might be OK, ca you spin new VM from an existing
> (problematic) template ?
>
> Behavior (from your second email) is expected - same kind of errors you
> would get if you just added another Secondary Storage to your CloudStack
> setup, but original URL is unavailable (you could play with hacking MD5 in
> DB, but that is not a solution at all).
>
> As for the restoration of the template.properties - do you have a backup ?
>
> Best,
> Andrija
>
> On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev <ku...@bw-sw.com>
> wrote:
>
> > To follow up. When SSVM boots it tries to redownload all the templates
> from
> > original sources this leads to next oucomes:
> > - if the source is not available, the result is:
> > No route to host (Host unreachable) - If the template is changed on
> source:
> > then it leads to MD5 sum error.
> >
> > Any ideas, why SSVM tries to download all the templates on SSVM again?
> > Never seen that before.
> >
> >
> > пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <kudryavtsev_ia@bw-sw.com
> >:
> >
> > > Hello, community.
> > >
> > > Today, We've met the problem with ACS SS, which looks like a critical
> > > error. In some point of time, new templates stopped to upload and the
> old
> > > ones were unable to be removed.
> > >
> > > After the SSVM recreation, I've met the situation when some templates
> are
> > > not activated and have their "template.properties" size set to 0.
> > >
> > > More to add, certain already working templates were tried to be
> > > redownloaded and got errors like:
> > > Failed post download script: checksum
> > > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given value,
> > > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> > > I've checked the following:
> > > - no lack of spare space on SS;
> > > - no problems with management servers in the last months;
> > > - no problems with SSVM.
> > >
> > > It's ACS 4.11.2, all VMs are working, of course as templates are copied
> > to
> > > primary, but we've lost almost half of the template repository.
> > >
> > > Is there a way to recreate "template.properties" from DB or another
> > > approach? All the templates are still in place, but they are not
> > activated
> > > upon SSVM start.
> > >
> > > Many thanks.
> > >
> > >
> > > --
> > > With best regards, Ivan Kudryavtsev
> > > Bitworks LLC
> > > Cell RU: +7-923-414-1515
> > > Cell USA: +1-201-257-1512
> > > WWW: http://bitworks.software/ <http://bw-sw.com/>
> > >
> > >
> >
> > --
> > With best regards, Ivan Kudryavtsev
> > Bitworks LLC
> > Cell RU: +7-923-414-1515
> > Cell USA: +1-201-257-1512
> > WWW: http://bitworks.software/ <http://bw-sw.com/>
> >
>
>
> --
>
> Andrija Panić
>
--
With best regards, Ivan Kudryavtsev
Bitworks LLC
Cell RU: +7-923-414-1515
Cell USA: +1-201-257-1512
WWW: http://bitworks.software/ <http://bw-sw.com/>
Re: CloudStack 4.11.2 SS problem
Posted by Andrija Panic <an...@gmail.com>.
Hi Ivan,
is it possible that your DB got somehow corrupted or that you are missing
records in template_store_ref etc - this might be the reason why SSVM is
trying to download templates again - if you check the logs for
non-problematic templates, you will see something like "template already on
store this and that, no need to download again, skipping". For the rest
(which are considered not downloaded), it will try to download again from
the URL in the main vm_template table.
Can you also check for the records on the template_spool_ref (Primary
Storage) - I assume these might be OK, ca you spin new VM from an existing
(problematic) template ?
Behavior (from your second email) is expected - same kind of errors you
would get if you just added another Secondary Storage to your CloudStack
setup, but original URL is unavailable (you could play with hacking MD5 in
DB, but that is not a solution at all).
As for the restoration of the template.properties - do you have a backup ?
Best,
Andrija
On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev <ku...@bw-sw.com>
wrote:
> To follow up. When SSVM boots it tries to redownload all the templates from
> original sources this leads to next oucomes:
> - if the source is not available, the result is:
> No route to host (Host unreachable) - If the template is changed on source:
> then it leads to MD5 sum error.
>
> Any ideas, why SSVM tries to download all the templates on SSVM again?
> Never seen that before.
>
>
> пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <ku...@bw-sw.com>:
>
> > Hello, community.
> >
> > Today, We've met the problem with ACS SS, which looks like a critical
> > error. In some point of time, new templates stopped to upload and the old
> > ones were unable to be removed.
> >
> > After the SSVM recreation, I've met the situation when some templates are
> > not activated and have their "template.properties" size set to 0.
> >
> > More to add, certain already working templates were tried to be
> > redownloaded and got errors like:
> > Failed post download script: checksum
> > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given value,
> > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> > I've checked the following:
> > - no lack of spare space on SS;
> > - no problems with management servers in the last months;
> > - no problems with SSVM.
> >
> > It's ACS 4.11.2, all VMs are working, of course as templates are copied
> to
> > primary, but we've lost almost half of the template repository.
> >
> > Is there a way to recreate "template.properties" from DB or another
> > approach? All the templates are still in place, but they are not
> activated
> > upon SSVM start.
> >
> > Many thanks.
> >
> >
> > --
> > With best regards, Ivan Kudryavtsev
> > Bitworks LLC
> > Cell RU: +7-923-414-1515
> > Cell USA: +1-201-257-1512
> > WWW: http://bitworks.software/ <http://bw-sw.com/>
> >
> >
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ <http://bw-sw.com/>
>
--
Andrija Panić
Re: CloudStack 4.11.2 SS problem
Posted by Andrija Panic <an...@gmail.com>.
Hi Ivan,
is it possible that your DB got somehow corrupted or that you are missing
records in template_store_ref etc - this might be the reason why SSVM is
trying to download templates again - if you check the logs for
non-problematic templates, you will see something like "template already on
store this and that, no need to download again, skipping". For the rest
(which are considered not downloaded), it will try to download again from
the URL in the main vm_template table.
Can you also check for the records on the template_spool_ref (Primary
Storage) - I assume these might be OK, ca you spin new VM from an existing
(problematic) template ?
Behavior (from your second email) is expected - same kind of errors you
would get if you just added another Secondary Storage to your CloudStack
setup, but original URL is unavailable (you could play with hacking MD5 in
DB, but that is not a solution at all).
As for the restoration of the template.properties - do you have a backup ?
Best,
Andrija
On Mon, 15 Apr 2019 at 16:26, Ivan Kudryavtsev <ku...@bw-sw.com>
wrote:
> To follow up. When SSVM boots it tries to redownload all the templates from
> original sources this leads to next oucomes:
> - if the source is not available, the result is:
> No route to host (Host unreachable) - If the template is changed on source:
> then it leads to MD5 sum error.
>
> Any ideas, why SSVM tries to download all the templates on SSVM again?
> Never seen that before.
>
>
> пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <ku...@bw-sw.com>:
>
> > Hello, community.
> >
> > Today, We've met the problem with ACS SS, which looks like a critical
> > error. In some point of time, new templates stopped to upload and the old
> > ones were unable to be removed.
> >
> > After the SSVM recreation, I've met the situation when some templates are
> > not activated and have their "template.properties" size set to 0.
> >
> > More to add, certain already working templates were tried to be
> > redownloaded and got errors like:
> > Failed post download script: checksum
> > "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given value,
> > "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> > I've checked the following:
> > - no lack of spare space on SS;
> > - no problems with management servers in the last months;
> > - no problems with SSVM.
> >
> > It's ACS 4.11.2, all VMs are working, of course as templates are copied
> to
> > primary, but we've lost almost half of the template repository.
> >
> > Is there a way to recreate "template.properties" from DB or another
> > approach? All the templates are still in place, but they are not
> activated
> > upon SSVM start.
> >
> > Many thanks.
> >
> >
> > --
> > With best regards, Ivan Kudryavtsev
> > Bitworks LLC
> > Cell RU: +7-923-414-1515
> > Cell USA: +1-201-257-1512
> > WWW: http://bitworks.software/ <http://bw-sw.com/>
> >
> >
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ <http://bw-sw.com/>
>
--
Andrija Panić
Re: CloudStack 4.11.2 SS problem
Posted by Ivan Kudryavtsev <ku...@bw-sw.com>.
To follow up. When SSVM boots it tries to redownload all the templates from
original sources this leads to next oucomes:
- if the source is not available, the result is:
No route to host (Host unreachable) - If the template is changed on source:
then it leads to MD5 sum error.
Any ideas, why SSVM tries to download all the templates on SSVM again?
Never seen that before.
пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <ku...@bw-sw.com>:
> Hello, community.
>
> Today, We've met the problem with ACS SS, which looks like a critical
> error. In some point of time, new templates stopped to upload and the old
> ones were unable to be removed.
>
> After the SSVM recreation, I've met the situation when some templates are
> not activated and have their "template.properties" size set to 0.
>
> More to add, certain already working templates were tried to be
> redownloaded and got errors like:
> Failed post download script: checksum
> "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given value,
> "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> I've checked the following:
> - no lack of spare space on SS;
> - no problems with management servers in the last months;
> - no problems with SSVM.
>
> It's ACS 4.11.2, all VMs are working, of course as templates are copied to
> primary, but we've lost almost half of the template repository.
>
> Is there a way to recreate "template.properties" from DB or another
> approach? All the templates are still in place, but they are not activated
> upon SSVM start.
>
> Many thanks.
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ <http://bw-sw.com/>
>
>
--
With best regards, Ivan Kudryavtsev
Bitworks LLC
Cell RU: +7-923-414-1515
Cell USA: +1-201-257-1512
WWW: http://bitworks.software/ <http://bw-sw.com/>
Re: CloudStack 4.11.2 SS problem
Posted by Ivan Kudryavtsev <ku...@bw-sw.com>.
To follow up. When SSVM boots it tries to redownload all the templates from
original sources this leads to next oucomes:
- if the source is not available, the result is:
No route to host (Host unreachable) - If the template is changed on source:
then it leads to MD5 sum error.
Any ideas, why SSVM tries to download all the templates on SSVM again?
Never seen that before.
пн, 15 апр. 2019 г. в 09:40, Ivan Kudryavtsev <ku...@bw-sw.com>:
> Hello, community.
>
> Today, We've met the problem with ACS SS, which looks like a critical
> error. In some point of time, new templates stopped to upload and the old
> ones were unable to be removed.
>
> After the SSVM recreation, I've met the situation when some templates are
> not activated and have their "template.properties" size set to 0.
>
> More to add, certain already working templates were tried to be
> redownloaded and got errors like:
> Failed post download script: checksum
> "{MD5}9f8c94ed7e4b19a78d4f0e3fc406d81b" didn't match the given value,
> "{MD5}7eed347f4cc7e66f55e4f668cd9a5151"
> I've checked the following:
> - no lack of spare space on SS;
> - no problems with management servers in the last months;
> - no problems with SSVM.
>
> It's ACS 4.11.2, all VMs are working, of course as templates are copied to
> primary, but we've lost almost half of the template repository.
>
> Is there a way to recreate "template.properties" from DB or another
> approach? All the templates are still in place, but they are not activated
> upon SSVM start.
>
> Many thanks.
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ <http://bw-sw.com/>
>
>
--
With best regards, Ivan Kudryavtsev
Bitworks LLC
Cell RU: +7-923-414-1515
Cell USA: +1-201-257-1512
WWW: http://bitworks.software/ <http://bw-sw.com/>