sorry sent to soon On Fri, Jul 17, 2015 at 11:38 AM, Daan Hoogland <daan.hoogl...@gmail.com> 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, <fight300...@sina.com> 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 -- Daan
