Hi David,
0. Good :) (needless to say, always drop the messed-up DBs, and then import
the backup in, don't just try to import over the existing/messed-up DBs)
1. You are right, you HAVE TO use the **exact** name as it's stated in the
upgrade notes (ACS code base is searching for a template with
Reporting in, I was able to roll-back the cloudstack packages and reload the
backup of the cloud database and get the UI going again.
So that's good, but a couple questions on this page (and registering the
template in the UI):
-
OK, got it, digging in...
Thanks everyone,
David
David Merrill
Senior Systems Engineer,
Managed and Private/Hybrid Cloud Services
OTELCO
92 Oak Street, Portland ME 04101
office 207.772.5678
http://www.otelco.com/cloud-and-managed-services
Confidentiality Message
The information contained in
David,
the procedure you laid out is correct - rollback DB, downgrade, etc
As Luis mentioned, make sure to also rollback the "mysql-connector-java" in
case it was upgraded (if you left the mysql repo enabled during the
upgrade).
There are ways to hack the DB, vm_template table and also use the
The database upgrade does not happen unless the systemVM templates have
been added, so nothing non-reversible has happened yet. You can just use
yum to downgrade to 4.11.2 and you'll be fine (we've also accidentally done
this at some point!).
I'd recommend disabling your cloudstack yum repo so
Dont forget to downgrade the database connector or it will not work
Sent from Yahoo Mail on Android
On Sun, May 17, 2020 at 3:47 PM, David Merrill
wrote: Hi All,
I've got a CloudStack 4.11.2 lab running on a single host & made the (dumb)
mistake of running OS updates without updating
Hi All,
I've got a CloudStack 4.11.2 lab running on a single host & made the (dumb)
mistake of running OS updates without updating the system VMs beforehand. The
CloudStack packages upgraded to 4.11.3 just fine but now CloudStack management
services wont start (see below).
Here's my question:
