Thanks a lot Marcus, will probably activate the recreate on reboot stuff. You said you manually reboot/recreate VRs after upgrade, instead of using the script - you finish all VRs upgrade/recreate before actually giving client access to cloudstack again?
I mean - there is operational risk as you pointed out, if after upgrade I dont use script for VR upgrade, and reboot/recreate each VR manually during the next couple of days...if clients are modifying their VPCs before the VR is upgraded... If for any reason I need to downgrade, I guess I would need to recreate all VRs/ssvm/cpvm again... Thanks again for sharing your experience. Andrija On Mar 11, 2015 5:26 PM, "Marcus" <shadow...@gmail.com> wrote: > I've never used the official script to upgrade. I always set to the > global setting to recreate on reboot of systemvms, it has been more > robust for me to do it the cloudy way and get a fresh vm on every > boot. With various issues that have arisen in the past (file system > filling up, fsck required on unclean shutdown, etc) it's just nice to > know that you're always a reboot away from getting a pristine config. > I was surprised when I heard about the patchviasocket issue as I've > run thousands of routers and upgraded them multiple times, never once > having an issue. Nor in my nested vm dev environment. Perhaps it was > just our fast storage or something. I think someone added in some > retries or something like that. > > Keep in mind that you usually don't need to drop in a new template for > a bugfix release, and it's sufficient to reboot. The exception to this > is if the bugfix release specifically indicates a new template, say > for a security fix on software in the OS of the template. Either way, > CloudStack will go through the full reprogramming process, and > stop/start the router to attach a new ISO with the new code and > install it on the router template, whether it images a fresh template > or uses an existing one. > > On Wed, Mar 11, 2015 at 3:59 AM, Andrija Panic <andrija.pa...@gmail.com> > wrote: > > Thanks Markus. > > > > So anyway, I need to make some time to upgrade to 4.3.2. > > > > Can I manually reboot VR/s one by one after the upgrade is done (instead > of > > using the script for rebooting ssvm, cpvm, and 66 VRs...) > > And is this reallt reboot inside OS - not destroying and recreating VRs > ??? > > > > Or would you still recommend rebooting VRs via sctipt - I understand that > > it reboots VRs one by one... > > > > I would not like to recreate VR, and then hit a bug with VR creation, > that > > I'm having right now... :( > > > > Thanks > > > > > > > > > > On 10 March 2015 at 20:14, Marcus <shadow...@gmail.com> wrote: > > > >> Hi, > >> It's impossible to know without looking at the changes in 4.3.1, > >> 4.3.2. Your routers will be running old code, and will probably work, > >> but might not, e.g. if a router script is called with parameters that > >> don't exist in the version of the script that the router runs. If you > >> don't plan on making any changes (add ACLs, spin up new VMs, etc) to > >> these VPCs they'll most likely run just fine as-is, but any changes > >> are a big ? > >> > >> As far as your question about replacing the template, I believe > >> CloudStack looks for the latest of a specific version, so if you > >> retire your existing template and install a new one per the 4.3 > >> upgrade instructions it should choose that. Note that for routers > >> specifically there s a global option 'router.template.kvm' that can be > >> pointed to a specific template name to use for routers. > >> > >> On Tue, Mar 10, 2015 at 7:46 AM, Andrija Panic <andrija.pa...@gmail.com > > > >> wrote: > >> > Hi, > >> > > >> > I was wondering is it possibe to update/replace the VR template > somehow > >> > without actually updating the ACS. > >> > > >> > I'm running ACS 4.3.0, and having some issues with remote IP not being > >> > really shown during Port Forwarding and Static NAT (VR also does SNAT > >> > beside the DNAT) > >> > > >> > I know question is a little bit weird - but... > >> > > >> > Another Q: I can see that after ACS is upgraded, there is restart of > each > >> > System VM needed - we have over 50-60 VPCs - this also means that I > need > >> to > >> > wait for 60 VRs to reboot. > >> > Is there any drawnback of runnng existing VRs after ACS 4.3.0 is > updated > >> to > >> > 4.3.2 and then later manually reboot each VR from > Infrastructure/Virtual > >> > Routers ? > >> > > >> > > >> > > >> > -- > >> > > >> > Andrija Panić > >> > > > > > > > > -- > > > > Andrija Panić >
