Hey Guillaume, not sure why you have to manually edit the db. After an upgrade. Assuming you followed the steps in the release notes, you could make the api call to rebootrouter on all the routers and that should do the trick of recreating them properly. On Jul 25, 2013 12:13 PM, "Sebastien Goasguen" <run...@gmail.com> wrote:
> Ahmad, Alena, you might have some thoughts on Guillaume's email below ? > > -sebastien > > On Jul 25, 2013, at 1:57 PM, Fraysse Guillaume <gfraysse...@gmail.com> > wrote: > > > Hello everyone, > > > > We had an unexpected problem on our infrastructure while we were > > upgrading CloudStack from 2.2.13 to 4.1 which led us to stop > > CloudStack before being able to finalize the update.We still have the > > vrouters to update but have a production platform that is a bit messy. > > We're trying to find out how to finish he upgrade of the vrouters and > > restart CloudStack when the VMware cluster has "lived his life" in the > > meantime and some VM are in different states that when CLoudStack was > > stopped. > > > > Here is the procedure we are testing in a preproduction environment, > > any advice/comment would be greatly appreciated as this is a risky > > operation to perform on our production environment: > > > > * Removing all vRouters from vCenter > > > > * Updating vRouters states to « Stopped » in CloudStack database : > > mysql> update vm_instance set state = 'Stopped' where state <> > > 'Expunging' and type = 'DomainRouter'; > > > > * Get the list of all vms : > > mysql> select id, instance_name, state from vm_instance where state <> > > 'Expunging' and type = 'User'; > > > > * Updating table vm_instance to set the correct states and hosts of > > vms. Example of SQL query : > > mysql> update vm_instance set state = 'Running', host_id = 17, > > last_host_id = 17 where id = 43; > > > > * Restarting CloudStack > > > > * Restarting all networks with « cleanup » option via CloudStack API. > > Example of HTTP request : > > $ curl > http://cloudstack:8096/?command=restartNetwork\&cleanup=true\&response=json\&id=227 > > > > This procedure seems to be working except for a little detail : we see > > that we use more Management IP adresses than expected, like they are > > not de-allocated, could it be a side effect of the procedure ? > > > > If you see any problem in this procedure or any problem it might lead > > us to, your help would be appreciated. > > > > Best regards, > > Guillaume > >
