Instead of doing that, always call stop with the forced flag = true. That causes CloudStack to do a best effort to stop the vm but even if it cannot be stopped, CloudStack will cleanup all resources.
--Alex > -----Original Message----- > From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] > Sent: Thursday, July 25, 2013 1:27 PM > To: Sebastien Goasguen; dev@cloudstack.apache.org; Ahmad Emneina > Subject: Re: Proofreading of our procedure to cleanly re-create vrouters and > restart CloudStack on a running VMware cluster after an interruption > > Its incorrect that system vms are being 'stopped' by modifying the DB. In this > case CS doesn't release the resources - that's why you see private ip address > still being allocated. So the correct way to do things would be: > > > 1. Don't stop anything > 2. Upgrade > 3. Run restartNetwork&clenaup=true for all the networks. It will re-create > the routers. Old ones will get destroyed (and their resources will be released > - ip address, cpu, ram, etc - in the CS DB); the new routers will get re- > created. > > -Alena. > > From: Sebastien Goasguen <run...@gmail.com<mailto:run...@gmail.com>> > Date: Thursday, July 25, 2013 12:13 PM > To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" > <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>, Ahmad > Emneina > <ahmad.emne...@citrix.com<mailto:ahmad.emne...@citrix.com>>, Alena > Prokharchyk > <alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> > Subject: Re: Proofreading of our procedure to cleanly re-create vrouters and > restart CloudStack on a running VMware cluster after an interruption > > 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<mailto: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\&respo > nse=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 >
