You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Andrija Panic <an...@gmail.com> on 2015/03/10 15:46:51 UTC
Updating VR template, without ACS update
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ć
Re: Updating VR template, without ACS update
Posted by Andrija Panic <an...@gmail.com>.
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" <sh...@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 <an...@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 <sh...@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ć
>
Re: Updating VR template, without ACS update
Posted by Andrija Panic <an...@gmail.com>.
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" <sh...@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 <an...@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 <sh...@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ć
>
Re: Updating VR template, without ACS update
Posted by Marcus <sh...@gmail.com>.
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 <an...@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 <sh...@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 <an...@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ć
Re: Updating VR template, without ACS update
Posted by Marcus <sh...@gmail.com>.
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 <an...@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 <sh...@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 <an...@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ć
Re: Updating VR template, without ACS update
Posted by Andrija Panic <an...@gmail.com>.
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 <sh...@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 <an...@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ć
Re: Updating VR template, without ACS update
Posted by Andrija Panic <an...@gmail.com>.
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 <sh...@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 <an...@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ć
Re: Updating VR template, without ACS update
Posted by Marcus <sh...@gmail.com>.
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 <an...@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ć
Re: Updating VR template, without ACS update
Posted by Marcus <sh...@gmail.com>.
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 <an...@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ć