cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrija Panic <andrija.pa...@gmail.com>
Subject Re: Updating VR template, without ACS update
Date Wed, 11 Mar 2015 21:34:04 GMT
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" <shadowsor@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.panic@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 <shadowsor@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.panic@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ć
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message