cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: upgrade cloudstack from 4.2.0 to 4.4.2
Date Fri, 17 Jul 2015 09:39:54 GMT
sorry sent to soon

On Fri, Jul 17, 2015 at 11:38 AM, Daan Hoogland <> wrote:
> ad 1. The roll back procedure is
 - restore the old db
- reinstall the old version of cloudstack
- recover the old etc dir (/etc/cloudstack)

that should do it

> ad 2. You only need to edit your cluster setting after the upgrade to
> set them to 4
> ad 3. yes they can remain running
> On Fri, Jul 17, 2015 at 5:03 AM,  <> wrote:
>> Hello,
>> My environment is cloudstack4.2.0+vmware5.0.I'm testing the upgrade process from
cloudstack4.2.0 to cloudstack 4.4.2 in this local envirionment.My reference is the <<cloudstack-release-notes-4.4.2>>.I
have successfully completed the upgrade process.The cloudstack is running normally after i
have upgraded it from 4.2.0 to 4.4.2.But i have some questions:
>> 1. I want to know procedures about upgrade-failure.What should i do if the process
of upgrading is error.According to the release note,my processes are the following:1)Install
new system-vm templates2)backup cloudstack database(MySQL)3)upgrade cloudstack management
server4)update hypervisors specific dependencies5)restart system-vms and virtual-routersPlease
give me some rollback processes.
>> 2. In the release note,it says:"After upgrading to 4.2 and later,Settings mem.overprovisioning.factor
and cpu.overprovisioning.factor are now at the cluster level and be set to 1 whick is the
default.If Global Settings mem.overprovisioning.factor and cpu.overprovisioning.factor have
been changed prior the upgrade to 4.2 and later,the upgrade process will be reset them to
1.Values can be changed by editing clusters settings.All clusters created after the upgrade
will get created with the Global Settings values for mem.overprovisioning.factor and cpu.overprovisioning.factor."
>> In my envirionment,cpu.overprovisioning.factor and mem.overprovisioning.factor are
set to 4.According to the release note,these two parameters will be set to 1 automatically
after the upgrade-process.So,will it have some problem about the cluster's overprovision.My
cluster's vms cannot all run if the parameter is set to 1.
>> If i shutdown all the vms before the upgrade process,maybe it can solve this problem.But
i prefer to keep all the vms running in the whole process.What should i do about this problem?
>> 3. Regardless of question 2,can all the vms keep the running state in the whole upgrade
process?I don't want to shutdown vms in the whole procedure.
>> Thank you.
> --
> Daan


View raw message