To add to what Darrin said - the fix will only work for NOT producing NEW
garbage with new templates - i.e. old garbage - you need to clear manually.
THose VM names (as you said, UUID-like names) are references (if used, of
course...) in the template_spool_ref table, field local_path or
In general (at least in the more current versions, say 4.9 and up) - when
user register his ssh key via API, it is stored in the ssh_keypairs)
When you deploy a VM and choose to inject the ssh (public) key, mgmt server
will read the value for that key from the DB, feed it to the VR, it becomes
Hi Mike,
this bug has been addressed in the master branch and should be in version 4.15
Cheers
Darrin
From: Corey, Mike
Sent: Friday, October 16, 2020 4:44 PM
To: users@cloudstack.apache.org
Subject: Clean-up stale clones
Hi,
Running through my lab testing
Hi,
Running through my lab testing I seem to be collecting different copies of
clones in my vCenter. I'm talking about the initial clone created when the
very first instance is created from a template. I've since imported templates,
created instances, and destroyed both but the initial clone
Hi Everyone,
I hope that you are all coping with the weird world that we are in at the
moment. And my best wishes to anyone and everyone and hope that we can all
get together at a collab again soon.
I emailed a few months ago to make sure that there were no problems with
having a code freeze in
Hello Users and Dev
Is there a way a new DB schema changes can be applied automatically
whenever I install new packages? My setup was running with two month old
changes of 4.15 and when I deployed new packages with latest changes, all
the recent db scheme changes are not applied and I need to run
