Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cisco: VOIP

Bridge upgrade vs. sub(s)

  

 
Cisco voip RSS feed   Index | Next | Previous | View Threaded


cisco-voip at ibh

Feb 27, 2012, 8:55 AM

Post #1 of 25 (1813 views)
Permalink
Bridge upgrade vs. sub(s)
Hi,

I'm preparing for an upgrade of a cluster (just one sub) running 7.1(3)
on DL380G4s (7845H2) to 8.6(2) on DL380G6s. To make things interesting,
the old version doesn't even recognize the new servers, and the new version
is not supported on the old metal except for bridge upgrade. Needless to
say, the upgrade has to be done with minimal downtime, something like
15min to switch would be acceptable, not more.

I'm planning to proceed as such:

1) Shut down the pub, while the sub continues serving the live network.
2) Boot the pub using GRML or such Linux live CD and make a full disk
copy to external storage. Maybe also break the mirrors and insert
additional disks to have a physical copy through RAID, putting the
original disks at a safe place.
3) Isolate the pub in a replica of the original network including
default gateway, DNS and NTP servers as needed. Boot it up again.
4) Do the upgrade procedure to 8.6(2) as documented, ending up with
a bridged upgrade only machine.
*** Here the docs state I have to also do this to the sub(s). Of
course I can't, they are serving the live network here. Is this
fatal, or is my procedure a proper workaround?
5) Do a DRS backup of the bridge-upgraded pub.
6) Restore the original pub using the copies made in step (2), plug it
back into the live network, boot it up and have the live network
working fully redundant again.
7) Install 8.6(2) on a new DL380G6 plugged into the replica network.
8) Restore the DRS backup from (5) to this new pub.
9) Make sure the pub is working correctly, except for the missing sub.
10) Now add a second DL380G6 to the replica network, install 8.6(2) as
a sub on it, and reestablish the cluster. Manually make sure all
files in the TFTP server of the original sub are available on the
new sub as well, as that one isn't restored from backup.
11) After making a lot of tests and sanity checks, swap in the new
cluster in a short downtime window.

Does this plan make any sense? Is there a better one? I'm specifically
bothered by the documented need to perform the bridged upgrade on all
nodes in unison, and then to restore first to the pub, then to all the
subs. Of course that's impossible without inacceptable downtimes. But
I assume that I cannot, after step (6), just isolate the old sub in
the same way as the pub before, doing a bridge upgrade of that isolated
sub only to get hold of a DRS backup of the sub?

Any hints or ideas welcome,
TIA,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


ewellnitzvoip at gmail

Feb 27, 2012, 10:35 AM

Post #2 of 25 (1765 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Does a reboot for the upgrade to switch from the inactive partition to the
active partion take longer than 15 minutes?

What I would do:
1. Run the upgrade without a reboot or switching versions
2. During my outage window switch versions and reboot
---at this point your system is functioning on the old hardware
3. Take a DRS backup for restore to the new cluster
4. Restore to new cluster
5. Switch TFTP settings
--may need to reduce your DHCP lease time
6. Reset all devices/point gateways to new cluster
---at this point you are usig the new hardware

I'd imagine there would be less than 15 minutes downtime with this
procedure but I've not done a bridged upgrade with 8.6 yet

On Mon, Feb 27, 2012 at 10:55 AM, Beck, Andre <cisco-voip [at] ibh> wrote:

> Hi,
>
> I'm preparing for an upgrade of a cluster (just one sub) running 7.1(3)
> on DL380G4s (7845H2) to 8.6(2) on DL380G6s. To make things interesting,
> the old version doesn't even recognize the new servers, and the new version
> is not supported on the old metal except for bridge upgrade. Needless to
> say, the upgrade has to be done with minimal downtime, something like
> 15min to switch would be acceptable, not more.
>
> I'm planning to proceed as such:
>
> 1) Shut down the pub, while the sub continues serving the live network.
> 2) Boot the pub using GRML or such Linux live CD and make a full disk
> copy to external storage. Maybe also break the mirrors and insert
> additional disks to have a physical copy through RAID, putting the
> original disks at a safe place.
> 3) Isolate the pub in a replica of the original network including
> default gateway, DNS and NTP servers as needed. Boot it up again.
> 4) Do the upgrade procedure to 8.6(2) as documented, ending up with
> a bridged upgrade only machine.
> *** Here the docs state I have to also do this to the sub(s). Of
> course I can't, they are serving the live network here. Is this
> fatal, or is my procedure a proper workaround?
> 5) Do a DRS backup of the bridge-upgraded pub.
> 6) Restore the original pub using the copies made in step (2), plug it
> back into the live network, boot it up and have the live network
> working fully redundant again.
> 7) Install 8.6(2) on a new DL380G6 plugged into the replica network.
> 8) Restore the DRS backup from (5) to this new pub.
> 9) Make sure the pub is working correctly, except for the missing sub.
> 10) Now add a second DL380G6 to the replica network, install 8.6(2) as
> a sub on it, and reestablish the cluster. Manually make sure all
> files in the TFTP server of the original sub are available on the
> new sub as well, as that one isn't restored from backup.
> 11) After making a lot of tests and sanity checks, swap in the new
> cluster in a short downtime window.
>
> Does this plan make any sense? Is there a better one? I'm specifically
> bothered by the documented need to perform the bridged upgrade on all
> nodes in unison, and then to restore first to the pub, then to all the
> subs. Of course that's impossible without inacceptable downtimes. But
> I assume that I cannot, after step (6), just isolate the old sub in
> the same way as the pub before, doing a bridge upgrade of that isolated
> sub only to get hold of a DRS backup of the sub?
>
> Any hints or ideas welcome,
> TIA,
> Andre.
> --
> Cool .signatures are so 90s...
>
> -> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>


me at mpking

Feb 28, 2012, 4:26 AM

Post #3 of 25 (1753 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Andre,

I'll leave it to others to comment on your procedure (I'm
not experienced enough to comment on it, other than it seems like it will
work to me).

My specific reply is to Point number 2.

We did this with a 4.0 to 7.1 upgrade. The H2 we used have a very
specific procedure for replacing the RAID. (I think's shut down, pull
drive, boot up. Shut down, Boot up. It is documented).

Also, I think the drive has to be replaced with an identical model as the
one you have in the server. (I don't know if this is true, but it's been
told to me by a consultant).

On Mon, Feb 27, 2012 at 11:55 AM, Beck, Andre <cisco-voip [at] ibh> wrote:

> Hi,
>
> I'm preparing for an upgrade of a cluster (just one sub) running 7.1(3)
> on DL380G4s (7845H2) to 8.6(2) on DL380G6s. To make things interesting,
> the old version doesn't even recognize the new servers, and the new version
> is not supported on the old metal except for bridge upgrade. Needless to
> say, the upgrade has to be done with minimal downtime, something like
> 15min to switch would be acceptable, not more.
>
> I'm planning to proceed as such:
>
> 1) Shut down the pub, while the sub continues serving the live network.
> 2) Boot the pub using GRML or such Linux live CD and make a full disk
> copy to external storage. Maybe also break the mirrors and insert
> additional disks to have a physical copy through RAID, putting the
> original disks at a safe place.
> 3) Isolate the pub in a replica of the original network including
> default gateway, DNS and NTP servers as needed. Boot it up again.
> 4) Do the upgrade procedure to 8.6(2) as documented, ending up with
> a bridged upgrade only machine.
> *** Here the docs state I have to also do this to the sub(s). Of
> course I can't, they are serving the live network here. Is this
> fatal, or is my procedure a proper workaround?
> 5) Do a DRS backup of the bridge-upgraded pub.
> 6) Restore the original pub using the copies made in step (2), plug it
> back into the live network, boot it up and have the live network
> working fully redundant again.
> 7) Install 8.6(2) on a new DL380G6 plugged into the replica network.
> 8) Restore the DRS backup from (5) to this new pub.
> 9) Make sure the pub is working correctly, except for the missing sub.
> 10) Now add a second DL380G6 to the replica network, install 8.6(2) as
> a sub on it, and reestablish the cluster. Manually make sure all
> files in the TFTP server of the original sub are available on the
> new sub as well, as that one isn't restored from backup.
> 11) After making a lot of tests and sanity checks, swap in the new
> cluster in a short downtime window.
>
> Does this plan make any sense? Is there a better one? I'm specifically
> bothered by the documented need to perform the bridged upgrade on all
> nodes in unison, and then to restore first to the pub, then to all the
> subs. Of course that's impossible without inacceptable downtimes. But
> I assume that I cannot, after step (6), just isolate the old sub in
> the same way as the pub before, doing a bridge upgrade of that isolated
> sub only to get hold of a DRS backup of the sub?
>
> Any hints or ideas welcome,
> TIA,
> Andre.
> --
> Cool .signatures are so 90s...
>
> -> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>


cisco-voip at ibh

Feb 28, 2012, 4:55 AM

Post #4 of 25 (1756 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Hi Erick,

On Mon, Feb 27, 2012 at 12:35:05PM -0600, Erick Wellnitz wrote:
> Does a reboot for the upgrade to switch from the inactive partition to the
> active partion take longer than 15 minutes?

Dunno, but I've not even thought about that so far. I've read the "not
supported except for bridged upgrade" warning signs as "won't work, except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".

> What I would do:
> 1. Run the upgrade without a reboot or switching versions

When I read the release notes correctly, upgrading to 8.6 will involve an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage. Details are not
documented, and I never did such an upgrade before, thus I wanted to do
things in an isolated network where it's clear the live network could not
be killed by it.

> 2. During my outage window switch versions and reboot
> ---at this point your system is functioning on the old hardware

Provided that the bridged upgrade does not prevent any services that are
not essential for DRS from running. Or, in other words, the system working
well except for not being supported when kept running in this state. I
couldn't grok from the release notes what would happen, so I wanted to
play it safe. Also note that this will create a licensing problem: I
would have to aquire licenses to run 8.6 on the old hardware (MAC) and
later move them to the new hardware. I had hopes to avoid that by moving
to the new hardware through DRS before touching the licensing, and be
able to resolve any licensing issues (which I expect to crop up for sure,
knowing my Murphy lessons well) in the isolated setup without time pressure.

> 3. Take a DRS backup for restore to the new cluster
> 4. Restore to new cluster
> 5. Switch TFTP settings
> --may need to reduce your DHCP lease time
> 6. Reset all devices/point gateways to new cluster
> ---at this point you are usig the new hardware

I'm not planning to have the cluster on other IPs after the upgrade. But
I could instead do all the preps starting with your step (4) in my
isolated network as well, so that's not a problem.

> I'd imagine there would be less than 15 minutes downtime with this
> procedure but I've not done a bridged upgrade with 8.6 yet

The basic problem with the procedure, from my PoV, is that it's all-or-
nothing with regard to it working correctly. If anything goes wrong in
the first two steps, I'm in a time-pressure situation to fix it ASAP,
while the main motive of my procedure is to play it safe and have the
old cluster run unaffected most of the time while I can freak around with
the new one (maybe for days until all issues are fixed).

Of course, it all hinges on the question whether "unsupported for anything
but DRS" is enforced or not.

Feels like I'm going to do some test scenarios in a virtualized cluster
prior to making decisions here, but that doesn't exactly allow to replicate
the "hardware no longer supported" case forcing me into the bridge upgrade
in the first place...

Thanks,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


mikeeo at msn

Feb 28, 2012, 5:57 AM

Post #5 of 25 (1759 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
This may not be practical, but have you considered a swing server? We have
done this in the past. You take an IBM/HP equivalent (7816-I4) load existing
version on that and restore from production. Then upgrade that to 8.6 and
backup. Then load 8.6 on your new DL380s and restore.

This leaves your production environment untouched and now you have a
complete copy running 8.6. Just swap the Ethernet cables and reset the
phones and you are set.

-----Original Message-----
From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Beck, Andre
Sent: Monday, February 27, 2012 11:55 AM
To: cisco-voip [at] puck
Subject: [cisco-voip] Bridge upgrade vs. sub(s)

Hi,

I'm preparing for an upgrade of a cluster (just one sub) running 7.1(3) on
DL380G4s (7845H2) to 8.6(2) on DL380G6s. To make things interesting, the old
version doesn't even recognize the new servers, and the new version is not
supported on the old metal except for bridge upgrade. Needless to say, the
upgrade has to be done with minimal downtime, something like 15min to switch
would be acceptable, not more.

I'm planning to proceed as such:

1) Shut down the pub, while the sub continues serving the live network.
2) Boot the pub using GRML or such Linux live CD and make a full disk
copy to external storage. Maybe also break the mirrors and insert
additional disks to have a physical copy through RAID, putting the
original disks at a safe place.
3) Isolate the pub in a replica of the original network including
default gateway, DNS and NTP servers as needed. Boot it up again.
4) Do the upgrade procedure to 8.6(2) as documented, ending up with
a bridged upgrade only machine.
*** Here the docs state I have to also do this to the sub(s). Of
course I can't, they are serving the live network here. Is this
fatal, or is my procedure a proper workaround?
5) Do a DRS backup of the bridge-upgraded pub.
6) Restore the original pub using the copies made in step (2), plug it
back into the live network, boot it up and have the live network
working fully redundant again.
7) Install 8.6(2) on a new DL380G6 plugged into the replica network.
8) Restore the DRS backup from (5) to this new pub.
9) Make sure the pub is working correctly, except for the missing sub.
10) Now add a second DL380G6 to the replica network, install 8.6(2) as
a sub on it, and reestablish the cluster. Manually make sure all
files in the TFTP server of the original sub are available on the
new sub as well, as that one isn't restored from backup.
11) After making a lot of tests and sanity checks, swap in the new
cluster in a short downtime window.

Does this plan make any sense? Is there a better one? I'm specifically
bothered by the documented need to perform the bridged upgrade on all nodes
in unison, and then to restore first to the pub, then to all the subs. Of
course that's impossible without inacceptable downtimes. But I assume that I
cannot, after step (6), just isolate the old sub in the same way as the pub
before, doing a bridge upgrade of that isolated sub only to get hold of a
DRS backup of the sub?

Any hints or ideas welcome,
TIA,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


rratliff at cisco

Feb 28, 2012, 9:40 AM

Post #6 of 25 (1753 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
+1 for Mike's suggestion of having extra server(s) to use for purposes like this (and a lab mock up of the cluster, doesn't everyone have one of these? ;P ).

> I've read the "not
> supported except for bridged upgrade" warning signs as "won't work, except
> allowing you to make a DRS backup", not "will probably work quite well,
> just don't call TAC when it breaks".

A word on bridge upgrades. The bridge upgrade means that the only services that will run are the ones necessary for you to take a backup. That is it. You get no phone service, no tftp, only DRF. There are no licensing requirements (aside from rehosting for the new hardware) because nothing that would even read the license files is running.

> When I read the release notes correctly, upgrading to 8.6 will involve an
> automatic reboot that is not optional. One may return to the original
> partition after that, but it will cause an outage.

You are reading correctly. Basically we can't actually run the files necessary to upgrade the OS due to incompatibilities between RHEL versions. That middle reboot is actually doing an entirely fresh install on the inactive partition and as such there's no web services to monitor the upgrade, no ssh, etc. If you were to watch the console of the server you'd see the same old blue screens as it progresses through. When it's all said and done as long as you aren't on the older 7825/28s you can still switch back to the old version though.
Testing in the lab is highly recommended so you are familiar with the process. VMs are cheap and for lab purposes it's a great exercise to mock up your entire cluster and run through the upgrade just to see what it involves.

-Ryan

On Feb 28, 2012, at 7:55 AM, Beck, Andre wrote:

Hi Erick,

On Mon, Feb 27, 2012 at 12:35:05PM -0600, Erick Wellnitz wrote:
> Does a reboot for the upgrade to switch from the inactive partition to the
> active partion take longer than 15 minutes?

Dunno, but I've not even thought about that so far. I've read the "not
supported except for bridged upgrade" warning signs as "won't work, except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".

> What I would do:
> 1. Run the upgrade without a reboot or switching versions

When I read the release notes correctly, upgrading to 8.6 will involve an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage. Details are not
documented, and I never did such an upgrade before, thus I wanted to do
things in an isolated network where it's clear the live network could not
be killed by it.

> 2. During my outage window switch versions and reboot
> ---at this point your system is functioning on the old hardware

Provided that the bridged upgrade does not prevent any services that are
not essential for DRS from running. Or, in other words, the system working
well except for not being supported when kept running in this state. I
couldn't grok from the release notes what would happen, so I wanted to
play it safe. Also note that this will create a licensing problem: I
would have to aquire licenses to run 8.6 on the old hardware (MAC) and
later move them to the new hardware. I had hopes to avoid that by moving
to the new hardware through DRS before touching the licensing, and be
able to resolve any licensing issues (which I expect to crop up for sure,
knowing my Murphy lessons well) in the isolated setup without time pressure.

> 3. Take a DRS backup for restore to the new cluster
> 4. Restore to new cluster
> 5. Switch TFTP settings
> --may need to reduce your DHCP lease time
> 6. Reset all devices/point gateways to new cluster
> ---at this point you are usig the new hardware

I'm not planning to have the cluster on other IPs after the upgrade. But
I could instead do all the preps starting with your step (4) in my
isolated network as well, so that's not a problem.

> I'd imagine there would be less than 15 minutes downtime with this
> procedure but I've not done a bridged upgrade with 8.6 yet

The basic problem with the procedure, from my PoV, is that it's all-or-
nothing with regard to it working correctly. If anything goes wrong in
the first two steps, I'm in a time-pressure situation to fix it ASAP,
while the main motive of my procedure is to play it safe and have the
old cluster run unaffected most of the time while I can freak around with
the new one (maybe for days until all issues are fixed).

Of course, it all hinges on the question whether "unsupported for anything
but DRS" is enforced or not.

Feels like I'm going to do some test scenarios in a virtualized cluster
prior to making decisions here, but that doesn't exactly allow to replicate
the "hardware no longer supported" case forcing me into the bridge upgrade
in the first place...

Thanks,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


ewellnitzvoip at gmail

Feb 28, 2012, 9:42 AM

Post #7 of 25 (1758 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Since the OS is upgraded in 8.6 Mike's idea seems like a winner.

On Feb 28, 2012, at 11:40 AM, Ryan Ratliff <rratliff [at] cisco> wrote:

> +1 for Mike's suggestion of having extra server(s) to use for purposes like this (and a lab mock up of the cluster, doesn't everyone have one of these? ;P ).
>
>> I've read the "not
>> supported except for bridged upgrade" warning signs as "won't work, except
>> allowing you to make a DRS backup", not "will probably work quite well,
>> just don't call TAC when it breaks".
>
> A word on bridge upgrades. The bridge upgrade means that the only services that will run are the ones necessary for you to take a backup. That is it. You get no phone service, no tftp, only DRF. There are no licensing requirements (aside from rehosting for the new hardware) because nothing that would even read the license files is running.
>
>> When I read the release notes correctly, upgrading to 8.6 will involve an
>> automatic reboot that is not optional. One may return to the original
>> partition after that, but it will cause an outage.
>
> You are reading correctly. Basically we can't actually run the files necessary to upgrade the OS due to incompatibilities between RHEL versions. That middle reboot is actually doing an entirely fresh install on the inactive partition and as such there's no web services to monitor the upgrade, no ssh, etc. If you were to watch the console of the server you'd see the same old blue screens as it progresses through. When it's all said and done as long as you aren't on the older 7825/28s you can still switch back to the old version though.
> Testing in the lab is highly recommended so you are familiar with the process. VMs are cheap and for lab purposes it's a great exercise to mock up your entire cluster and run through the upgrade just to see what it involves.
>
> -Ryan
>
> On Feb 28, 2012, at 7:55 AM, Beck, Andre wrote:
>
> Hi Erick,
>
> On Mon, Feb 27, 2012 at 12:35:05PM -0600, Erick Wellnitz wrote:
>> Does a reboot for the upgrade to switch from the inactive partition to the
>> active partion take longer than 15 minutes?
>
> Dunno, but I've not even thought about that so far. I've read the "not
> supported except for bridged upgrade" warning signs as "won't work, except
> allowing you to make a DRS backup", not "will probably work quite well,
> just don't call TAC when it breaks".
>
>> What I would do:
>> 1. Run the upgrade without a reboot or switching versions
>
> When I read the release notes correctly, upgrading to 8.6 will involve an
> automatic reboot that is not optional. One may return to the original
> partition after that, but it will cause an outage. Details are not
> documented, and I never did such an upgrade before, thus I wanted to do
> things in an isolated network where it's clear the live network could not
> be killed by it.
>
>> 2. During my outage window switch versions and reboot
>> ---at this point your system is functioning on the old hardware
>
> Provided that the bridged upgrade does not prevent any services that are
> not essential for DRS from running. Or, in other words, the system working
> well except for not being supported when kept running in this state. I
> couldn't grok from the release notes what would happen, so I wanted to
> play it safe. Also note that this will create a licensing problem: I
> would have to aquire licenses to run 8.6 on the old hardware (MAC) and
> later move them to the new hardware. I had hopes to avoid that by moving
> to the new hardware through DRS before touching the licensing, and be
> able to resolve any licensing issues (which I expect to crop up for sure,
> knowing my Murphy lessons well) in the isolated setup without time pressure.
>
>> 3. Take a DRS backup for restore to the new cluster
>> 4. Restore to new cluster
>> 5. Switch TFTP settings
>> --may need to reduce your DHCP lease time
>> 6. Reset all devices/point gateways to new cluster
>> ---at this point you are usig the new hardware
>
> I'm not planning to have the cluster on other IPs after the upgrade. But
> I could instead do all the preps starting with your step (4) in my
> isolated network as well, so that's not a problem.
>
>> I'd imagine there would be less than 15 minutes downtime with this
>> procedure but I've not done a bridged upgrade with 8.6 yet
>
> The basic problem with the procedure, from my PoV, is that it's all-or-
> nothing with regard to it working correctly. If anything goes wrong in
> the first two steps, I'm in a time-pressure situation to fix it ASAP,
> while the main motive of my procedure is to play it safe and have the
> old cluster run unaffected most of the time while I can freak around with
> the new one (maybe for days until all issues are fixed).
>
> Of course, it all hinges on the question whether "unsupported for anything
> but DRS" is enforced or not.
>
> Feels like I'm going to do some test scenarios in a virtualized cluster
> prior to making decisions here, but that doesn't exactly allow to replicate
> the "hardware no longer supported" case forcing me into the bridge upgrade
> in the first place...
>
> Thanks,
> Andre.
> --
> Cool .signatures are so 90s...
>
> -> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


mballard at otis

Feb 28, 2012, 1:06 PM

Post #8 of 25 (1753 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Just had a thought on the whole imaging process - if moving to UCS on
VMWare, while I know 7.1.3 (what I am running now, and I will be doing
the migration soon) doesn't officially support VMWare, is it possible to
restore to a VM (on an isolated network), and do the upgrade on the VM
instead of the original production box, and then just switch from the
old hardware based to the new VM based running on 8.6?



Matthew Ballard

Network Manager

Otis College of Art and Design

mballard [at] otis





From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Ryan Ratliff
Sent: Tuesday, February 28, 2012 9:40 AM
To: Beck, Andre
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)



+1 for Mike's suggestion of having extra server(s) to use for purposes
like this (and a lab mock up of the cluster, doesn't everyone have one
of these? ;P ).



I've read the "not
supported except for bridged upgrade" warning signs as "won't
work, except
allowing you to make a DRS backup", not "will probably work
quite well,
just don't call TAC when it breaks".



A word on bridge upgrades. The bridge upgrade means that the only
services that will run are the ones necessary for you to take a backup.
That is it. You get no phone service, no tftp, only DRF. There are no
licensing requirements (aside from rehosting for the new hardware)
because nothing that would even read the license files is running.



When I read the release notes correctly, upgrading to 8.6 will
involve an
automatic reboot that is not optional. One may return to the
original
partition after that, but it will cause an outage.



You are reading correctly. Basically we can't actually run the files
necessary to upgrade the OS due to incompatibilities between RHEL
versions. That middle reboot is actually doing an entirely fresh
install on the inactive partition and as such there's no web services to
monitor the upgrade, no ssh, etc. If you were to watch the console of
the server you'd see the same old blue screens as it progresses through.
When it's all said and done as long as you aren't on the older 7825/28s
you can still switch back to the old version though.

Testing in the lab is highly recommended so you are familiar with the
process. VMs are cheap and for lab purposes it's a great exercise to
mock up your entire cluster and run through the upgrade just to see what
it involves.



-Ryan



On Feb 28, 2012, at 7:55 AM, Beck, Andre wrote:



Hi Erick,

On Mon, Feb 27, 2012 at 12:35:05PM -0600, Erick Wellnitz wrote:



Does a reboot for the upgrade to switch from the inactive partition to
the

active partion take longer than 15 minutes?


Dunno, but I've not even thought about that so far. I've read the "not
supported except for bridged upgrade" warning signs as "won't work,
except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".




What I would do:

1. Run the upgrade without a reboot or switching versions


When I read the release notes correctly, upgrading to 8.6 will involve
an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage. Details are not
documented, and I never did such an upgrade before, thus I wanted to do
things in an isolated network where it's clear the live network could
not
be killed by it.




2. During my outage window switch versions and reboot

---at this point your system is functioning on the old hardware


Provided that the bridged upgrade does not prevent any services that are
not essential for DRS from running. Or, in other words, the system
working
well except for not being supported when kept running in this state. I
couldn't grok from the release notes what would happen, so I wanted to
play it safe. Also note that this will create a licensing problem: I
would have to aquire licenses to run 8.6 on the old hardware (MAC) and
later move them to the new hardware. I had hopes to avoid that by moving
to the new hardware through DRS before touching the licensing, and be
able to resolve any licensing issues (which I expect to crop up for
sure,
knowing my Murphy lessons well) in the isolated setup without time
pressure.




3. Take a DRS backup for restore to the new cluster

4. Restore to new cluster

5. Switch TFTP settings

--may need to reduce your DHCP lease time

6. Reset all devices/point gateways to new cluster

---at this point you are usig the new hardware


I'm not planning to have the cluster on other IPs after the upgrade. But
I could instead do all the preps starting with your step (4) in my
isolated network as well, so that's not a problem.




I'd imagine there would be less than 15 minutes downtime with this

procedure but I've not done a bridged upgrade with 8.6 yet


The basic problem with the procedure, from my PoV, is that it's all-or-
nothing with regard to it working correctly. If anything goes wrong in
the first two steps, I'm in a time-pressure situation to fix it ASAP,
while the main motive of my procedure is to play it safe and have the
old cluster run unaffected most of the time while I can freak around
with
the new one (maybe for days until all issues are fixed).

Of course, it all hinges on the question whether "unsupported for
anything
but DRS" is enforced or not.

Feels like I'm going to do some test scenarios in a virtualized cluster
prior to making decisions here, but that doesn't exactly allow to
replicate
the "hardware no longer supported" case forcing me into the bridge
upgrade
in the first place...

Thanks,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


rratliff at cisco

Feb 28, 2012, 2:10 PM

Post #9 of 25 (1756 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Not in a supported manner, no.

-Ryan

On Feb 28, 2012, at 4:06 PM, Matthew Ballard wrote:

Just had a thought on the whole imaging process – if moving to UCS on VMWare, while I know 7.1.3 (what I am running now, and I will be doing the migration soon) doesn’t officially support VMWare, is it possible to restore to a VM (on an isolated network), and do the upgrade on the VM instead of the original production box, and then just switch from the old hardware based to the new VM based running on 8.6?

Matthew Ballard
Network Manager
Otis College of Art and Design
mballard [at] otis


From: cisco-voip-bounces [at] puck [mailto:cisco-voip-bounces [at] puck] On Behalf Of Ryan Ratliff
Sent: Tuesday, February 28, 2012 9:40 AM
To: Beck, Andre
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)

+1 for Mike's suggestion of having extra server(s) to use for purposes like this (and a lab mock up of the cluster, doesn't everyone have one of these? ;P ).

I've read the "not
supported except for bridged upgrade" warning signs as "won't work, except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".

A word on bridge upgrades. The bridge upgrade means that the only services that will run are the ones necessary for you to take a backup. That is it. You get no phone service, no tftp, only DRF. There are no licensing requirements (aside from rehosting for the new hardware) because nothing that would even read the license files is running.

When I read the release notes correctly, upgrading to 8.6 will involve an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage.

You are reading correctly. Basically we can't actually run the files necessary to upgrade the OS due to incompatibilities between RHEL versions. That middle reboot is actually doing an entirely fresh install on the inactive partition and as such there's no web services to monitor the upgrade, no ssh, etc. If you were to watch the console of the server you'd see the same old blue screens as it progresses through. When it's all said and done as long as you aren't on the older 7825/28s you can still switch back to the old version though.
Testing in the lab is highly recommended so you are familiar with the process. VMs are cheap and for lab purposes it's a great exercise to mock up your entire cluster and run through the upgrade just to see what it involves.

-Ryan

On Feb 28, 2012, at 7:55 AM, Beck, Andre wrote:

Hi Erick,

On Mon, Feb 27, 2012 at 12:35:05PM -0600, Erick Wellnitz wrote:

Does a reboot for the upgrade to switch from the inactive partition to the
active partion take longer than 15 minutes?

Dunno, but I've not even thought about that so far. I've read the "not
supported except for bridged upgrade" warning signs as "won't work, except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".


What I would do:
1. Run the upgrade without a reboot or switching versions

When I read the release notes correctly, upgrading to 8.6 will involve an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage. Details are not
documented, and I never did such an upgrade before, thus I wanted to do
things in an isolated network where it's clear the live network could not
be killed by it.


2. During my outage window switch versions and reboot
---at this point your system is functioning on the old hardware

Provided that the bridged upgrade does not prevent any services that are
not essential for DRS from running. Or, in other words, the system working
well except for not being supported when kept running in this state. I
couldn't grok from the release notes what would happen, so I wanted to
play it safe. Also note that this will create a licensing problem: I
would have to aquire licenses to run 8.6 on the old hardware (MAC) and
later move them to the new hardware. I had hopes to avoid that by moving
to the new hardware through DRS before touching the licensing, and be
able to resolve any licensing issues (which I expect to crop up for sure,
knowing my Murphy lessons well) in the isolated setup without time pressure.


3. Take a DRS backup for restore to the new cluster
4. Restore to new cluster
5. Switch TFTP settings
--may need to reduce your DHCP lease time
6. Reset all devices/point gateways to new cluster
---at this point you are usig the new hardware

I'm not planning to have the cluster on other IPs after the upgrade. But
I could instead do all the preps starting with your step (4) in my
isolated network as well, so that's not a problem.


I'd imagine there would be less than 15 minutes downtime with this
procedure but I've not done a bridged upgrade with 8.6 yet

The basic problem with the procedure, from my PoV, is that it's all-or-
nothing with regard to it working correctly. If anything goes wrong in
the first two steps, I'm in a time-pressure situation to fix it ASAP,
while the main motive of my procedure is to play it safe and have the
old cluster run unaffected most of the time while I can freak around with
the new one (maybe for days until all issues are fixed).

Of course, it all hinges on the question whether "unsupported for anything
but DRS" is enforced or not.

Feels like I'm going to do some test scenarios in a virtualized cluster
prior to making decisions here, but that doesn't exactly allow to replicate
the "hardware no longer supported" case forcing me into the bridge upgrade
in the first place...

Thanks,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


mikeeo at msn

Feb 28, 2012, 2:49 PM

Post #10 of 25 (1761 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Once you install any release prior 8.x on VMWARE it marks the database as
unsupported even when you upgrade to ver8.x. It's a huge issue in the field
and I wish Cisco would address it.



From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Matthew Ballard
Sent: Tuesday, February 28, 2012 4:07 PM
To: Ryan Ratliff; Beck, Andre
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)



Just had a thought on the whole imaging process - if moving to UCS on
VMWare, while I know 7.1.3 (what I am running now, and I will be doing the
migration soon) doesn't officially support VMWare, is it possible to restore
to a VM (on an isolated network), and do the upgrade on the VM instead of
the original production box, and then just switch from the old hardware
based to the new VM based running on 8.6?



Matthew Ballard

Network Manager

Otis College of Art and Design

mballard [at] otis





From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Ryan Ratliff
Sent: Tuesday, February 28, 2012 9:40 AM
To: Beck, Andre
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)



+1 for Mike's suggestion of having extra server(s) to use for purposes like
this (and a lab mock up of the cluster, doesn't everyone have one of these?
;P ).



I've read the "not
supported except for bridged upgrade" warning signs as "won't work, except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".



A word on bridge upgrades. The bridge upgrade means that the only services
that will run are the ones necessary for you to take a backup. That is it.
You get no phone service, no tftp, only DRF. There are no licensing
requirements (aside from rehosting for the new hardware) because nothing
that would even read the license files is running.



When I read the release notes correctly, upgrading to 8.6 will involve an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage.



You are reading correctly. Basically we can't actually run the files
necessary to upgrade the OS due to incompatibilities between RHEL versions.
That middle reboot is actually doing an entirely fresh install on the
inactive partition and as such there's no web services to monitor the
upgrade, no ssh, etc. If you were to watch the console of the server you'd
see the same old blue screens as it progresses through. When it's all said
and done as long as you aren't on the older 7825/28s you can still switch
back to the old version though.

Testing in the lab is highly recommended so you are familiar with the
process. VMs are cheap and for lab purposes it's a great exercise to mock
up your entire cluster and run through the upgrade just to see what it
involves.



-Ryan



On Feb 28, 2012, at 7:55 AM, Beck, Andre wrote:



Hi Erick,

On Mon, Feb 27, 2012 at 12:35:05PM -0600, Erick Wellnitz wrote:

Does a reboot for the upgrade to switch from the inactive partition to the

active partion take longer than 15 minutes?


Dunno, but I've not even thought about that so far. I've read the "not
supported except for bridged upgrade" warning signs as "won't work, except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".



What I would do:

1. Run the upgrade without a reboot or switching versions


When I read the release notes correctly, upgrading to 8.6 will involve an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage. Details are not
documented, and I never did such an upgrade before, thus I wanted to do
things in an isolated network where it's clear the live network could not
be killed by it.



2. During my outage window switch versions and reboot

---at this point your system is functioning on the old hardware


Provided that the bridged upgrade does not prevent any services that are
not essential for DRS from running. Or, in other words, the system working
well except for not being supported when kept running in this state. I
couldn't grok from the release notes what would happen, so I wanted to
play it safe. Also note that this will create a licensing problem: I
would have to aquire licenses to run 8.6 on the old hardware (MAC) and
later move them to the new hardware. I had hopes to avoid that by moving
to the new hardware through DRS before touching the licensing, and be
able to resolve any licensing issues (which I expect to crop up for sure,
knowing my Murphy lessons well) in the isolated setup without time pressure.



3. Take a DRS backup for restore to the new cluster

4. Restore to new cluster

5. Switch TFTP settings

--may need to reduce your DHCP lease time

6. Reset all devices/point gateways to new cluster

---at this point you are usig the new hardware


I'm not planning to have the cluster on other IPs after the upgrade. But
I could instead do all the preps starting with your step (4) in my
isolated network as well, so that's not a problem.



I'd imagine there would be less than 15 minutes downtime with this

procedure but I've not done a bridged upgrade with 8.6 yet


The basic problem with the procedure, from my PoV, is that it's all-or-
nothing with regard to it working correctly. If anything goes wrong in
the first two steps, I'm in a time-pressure situation to fix it ASAP,
while the main motive of my procedure is to play it safe and have the
old cluster run unaffected most of the time while I can freak around with
the new one (maybe for days until all issues are fixed).

Of course, it all hinges on the question whether "unsupported for anything
but DRS" is enforced or not.

Feels like I'm going to do some test scenarios in a virtualized cluster
prior to making decisions here, but that doesn't exactly allow to replicate
the "hardware no longer supported" case forcing me into the bridge upgrade
in the first place...

Thanks,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


mballard at otis

Feb 28, 2012, 2:54 PM

Post #11 of 25 (1749 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
What happens if you do a DRS from the upgraded version on VMWare to a
fresh install of 8.x of VMWare? Will that restore it to a supported
state in the database (trying to think of options to avoid doing the
upgrade on my main production system to minimize downtime and off-hours
work)?



Thank You,

Matthew





From: Mike [mailto:mikeeo [at] msn]
Sent: Tuesday, February 28, 2012 2:50 PM
To: Matthew Ballard; 'Ryan Ratliff'; 'Beck, Andre'
Cc: cisco-voip [at] puck
Subject: RE: [cisco-voip] Bridge upgrade vs. sub(s)



Once you install any release prior 8.x on VMWARE it marks the database
as unsupported even when you upgrade to ver8.x. It's a huge issue in the
field and I wish Cisco would address it.



From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Matthew Ballard
Sent: Tuesday, February 28, 2012 4:07 PM
To: Ryan Ratliff; Beck, Andre
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)



Just had a thought on the whole imaging process - if moving to UCS on
VMWare, while I know 7.1.3 (what I am running now, and I will be doing
the migration soon) doesn't officially support VMWare, is it possible to
restore to a VM (on an isolated network), and do the upgrade on the VM
instead of the original production box, and then just switch from the
old hardware based to the new VM based running on 8.6?



Matthew Ballard

Network Manager

Otis College of Art and Design

mballard [at] otis





From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Ryan Ratliff
Sent: Tuesday, February 28, 2012 9:40 AM
To: Beck, Andre
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)



+1 for Mike's suggestion of having extra server(s) to use for purposes
like this (and a lab mock up of the cluster, doesn't everyone have one
of these? ;P ).



I've read the "not
supported except for bridged upgrade" warning signs as "won't
work, except
allowing you to make a DRS backup", not "will probably work
quite well,
just don't call TAC when it breaks".



A word on bridge upgrades. The bridge upgrade means that the only
services that will run are the ones necessary for you to take a backup.
That is it. You get no phone service, no tftp, only DRF. There are no
licensing requirements (aside from rehosting for the new hardware)
because nothing that would even read the license files is running.



When I read the release notes correctly, upgrading to 8.6 will
involve an
automatic reboot that is not optional. One may return to the
original
partition after that, but it will cause an outage.



You are reading correctly. Basically we can't actually run the files
necessary to upgrade the OS due to incompatibilities between RHEL
versions. That middle reboot is actually doing an entirely fresh
install on the inactive partition and as such there's no web services to
monitor the upgrade, no ssh, etc. If you were to watch the console of
the server you'd see the same old blue screens as it progresses through.
When it's all said and done as long as you aren't on the older 7825/28s
you can still switch back to the old version though.

Testing in the lab is highly recommended so you are familiar with the
process. VMs are cheap and for lab purposes it's a great exercise to
mock up your entire cluster and run through the upgrade just to see what
it involves.



-Ryan



On Feb 28, 2012, at 7:55 AM, Beck, Andre wrote:



Hi Erick,

On Mon, Feb 27, 2012 at 12:35:05PM -0600, Erick Wellnitz wrote:

Does a reboot for the upgrade to switch from the inactive partition to
the

active partion take longer than 15 minutes?


Dunno, but I've not even thought about that so far. I've read the "not
supported except for bridged upgrade" warning signs as "won't work,
except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".

What I would do:

1. Run the upgrade without a reboot or switching versions


When I read the release notes correctly, upgrading to 8.6 will involve
an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage. Details are not
documented, and I never did such an upgrade before, thus I wanted to do
things in an isolated network where it's clear the live network could
not
be killed by it.

2. During my outage window switch versions and reboot

---at this point your system is functioning on the old hardware


Provided that the bridged upgrade does not prevent any services that are
not essential for DRS from running. Or, in other words, the system
working
well except for not being supported when kept running in this state. I
couldn't grok from the release notes what would happen, so I wanted to
play it safe. Also note that this will create a licensing problem: I
would have to aquire licenses to run 8.6 on the old hardware (MAC) and
later move them to the new hardware. I had hopes to avoid that by moving
to the new hardware through DRS before touching the licensing, and be
able to resolve any licensing issues (which I expect to crop up for
sure,
knowing my Murphy lessons well) in the isolated setup without time
pressure.

3. Take a DRS backup for restore to the new cluster

4. Restore to new cluster

5. Switch TFTP settings

--may need to reduce your DHCP lease time

6. Reset all devices/point gateways to new cluster

---at this point you are usig the new hardware


I'm not planning to have the cluster on other IPs after the upgrade. But
I could instead do all the preps starting with your step (4) in my
isolated network as well, so that's not a problem.

I'd imagine there would be less than 15 minutes downtime with this

procedure but I've not done a bridged upgrade with 8.6 yet


The basic problem with the procedure, from my PoV, is that it's all-or-
nothing with regard to it working correctly. If anything goes wrong in
the first two steps, I'm in a time-pressure situation to fix it ASAP,
while the main motive of my procedure is to play it safe and have the
old cluster run unaffected most of the time while I can freak around
with
the new one (maybe for days until all issues are fixed).

Of course, it all hinges on the question whether "unsupported for
anything
but DRS" is enforced or not.

Feels like I'm going to do some test scenarios in a virtualized cluster
prior to making decisions here, but that doesn't exactly allow to
replicate
the "hardware no longer supported" case forcing me into the bridge
upgrade
in the first place...

Thanks,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


mikeeo at msn

Feb 28, 2012, 3:12 PM

Post #12 of 25 (1750 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
I don't understand the question, but to give you a good rule of thumb is to
always upgrade from releases prior to 8x on MCS hardware or equivalents and
then move to VMWARE.



From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Matthew Ballard
Sent: Tuesday, February 28, 2012 5:54 PM
To: Mike ; Ryan Ratliff; Beck, Andre
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)



What happens if you do a DRS from the upgraded version on VMWare to a fresh
install of 8.x of VMWare? Will that restore it to a supported state in the
database (trying to think of options to avoid doing the upgrade on my main
production system to minimize downtime and off-hours work)?



Thank You,

Matthew





From: Mike [mailto:mikeeo [at] msn]
Sent: Tuesday, February 28, 2012 2:50 PM
To: Matthew Ballard; 'Ryan Ratliff'; 'Beck, Andre'
Cc: cisco-voip [at] puck
Subject: RE: [cisco-voip] Bridge upgrade vs. sub(s)



Once you install any release prior 8.x on VMWARE it marks the database as
unsupported even when you upgrade to ver8.x. It's a huge issue in the field
and I wish Cisco would address it.



From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Matthew Ballard
Sent: Tuesday, February 28, 2012 4:07 PM
To: Ryan Ratliff; Beck, Andre
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)



Just had a thought on the whole imaging process - if moving to UCS on
VMWare, while I know 7.1.3 (what I am running now, and I will be doing the
migration soon) doesn't officially support VMWare, is it possible to restore
to a VM (on an isolated network), and do the upgrade on the VM instead of
the original production box, and then just switch from the old hardware
based to the new VM based running on 8.6?



Matthew Ballard

Network Manager

Otis College of Art and Design

mballard [at] otis





From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Ryan Ratliff
Sent: Tuesday, February 28, 2012 9:40 AM
To: Beck, Andre
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)



+1 for Mike's suggestion of having extra server(s) to use for purposes like
this (and a lab mock up of the cluster, doesn't everyone have one of these?
;P ).



I've read the "not
supported except for bridged upgrade" warning signs as "won't work, except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".



A word on bridge upgrades. The bridge upgrade means that the only services
that will run are the ones necessary for you to take a backup. That is it.
You get no phone service, no tftp, only DRF. There are no licensing
requirements (aside from rehosting for the new hardware) because nothing
that would even read the license files is running.



When I read the release notes correctly, upgrading to 8.6 will involve an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage.



You are reading correctly. Basically we can't actually run the files
necessary to upgrade the OS due to incompatibilities between RHEL versions.
That middle reboot is actually doing an entirely fresh install on the
inactive partition and as such there's no web services to monitor the
upgrade, no ssh, etc. If you were to watch the console of the server you'd
see the same old blue screens as it progresses through. When it's all said
and done as long as you aren't on the older 7825/28s you can still switch
back to the old version though.

Testing in the lab is highly recommended so you are familiar with the
process. VMs are cheap and for lab purposes it's a great exercise to mock
up your entire cluster and run through the upgrade just to see what it
involves.



-Ryan



On Feb 28, 2012, at 7:55 AM, Beck, Andre wrote:



Hi Erick,

On Mon, Feb 27, 2012 at 12:35:05PM -0600, Erick Wellnitz wrote:

Does a reboot for the upgrade to switch from the inactive partition to the

active partion take longer than 15 minutes?


Dunno, but I've not even thought about that so far. I've read the "not
supported except for bridged upgrade" warning signs as "won't work, except
allowing you to make a DRS backup", not "will probably work quite well,
just don't call TAC when it breaks".

What I would do:

1. Run the upgrade without a reboot or switching versions


When I read the release notes correctly, upgrading to 8.6 will involve an
automatic reboot that is not optional. One may return to the original
partition after that, but it will cause an outage. Details are not
documented, and I never did such an upgrade before, thus I wanted to do
things in an isolated network where it's clear the live network could not
be killed by it.

2. During my outage window switch versions and reboot

---at this point your system is functioning on the old hardware


Provided that the bridged upgrade does not prevent any services that are
not essential for DRS from running. Or, in other words, the system working
well except for not being supported when kept running in this state. I
couldn't grok from the release notes what would happen, so I wanted to
play it safe. Also note that this will create a licensing problem: I
would have to aquire licenses to run 8.6 on the old hardware (MAC) and
later move them to the new hardware. I had hopes to avoid that by moving
to the new hardware through DRS before touching the licensing, and be
able to resolve any licensing issues (which I expect to crop up for sure,
knowing my Murphy lessons well) in the isolated setup without time pressure.

3. Take a DRS backup for restore to the new cluster

4. Restore to new cluster

5. Switch TFTP settings

--may need to reduce your DHCP lease time

6. Reset all devices/point gateways to new cluster

---at this point you are usig the new hardware


I'm not planning to have the cluster on other IPs after the upgrade. But
I could instead do all the preps starting with your step (4) in my
isolated network as well, so that's not a problem.

I'd imagine there would be less than 15 minutes downtime with this

procedure but I've not done a bridged upgrade with 8.6 yet


The basic problem with the procedure, from my PoV, is that it's all-or-
nothing with regard to it working correctly. If anything goes wrong in
the first two steps, I'm in a time-pressure situation to fix it ASAP,
while the main motive of my procedure is to play it safe and have the
old cluster run unaffected most of the time while I can freak around with
the new one (maybe for days until all issues are fixed).

Of course, it all hinges on the question whether "unsupported for anything
but DRS" is enforced or not.

Feels like I'm going to do some test scenarios in a virtualized cluster
prior to making decisions here, but that doesn't exactly allow to replicate
the "hardware no longer supported" case forcing me into the bridge upgrade
in the first place...

Thanks,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


jalbertini at ymail

Feb 29, 2012, 6:04 AM

Post #13 of 25 (1747 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
I thought to restore the CUCM database to another server it had to have the same IP address of the existing PUB server? This procedure would also require new license generation as well.

Regards,
Joe

On Feb 28, 2012, at 8:57, "Mike " <mikeeo [at] msn> wrote:

> This may not be practical, but have you considered a swing server? We have
> done this in the past. You take an IBM/HP equivalent (7816-I4) load existing
> version on that and restore from production. Then upgrade that to 8.6 and
> backup. Then load 8.6 on your new DL380s and restore.
>
> This leaves your production environment untouched and now you have a
> complete copy running 8.6. Just swap the Ethernet cables and reset the
> phones and you are set.
>
> -----Original Message-----
> From: cisco-voip-bounces [at] puck
> [mailto:cisco-voip-bounces [at] puck] On Behalf Of Beck, Andre
> Sent: Monday, February 27, 2012 11:55 AM
> To: cisco-voip [at] puck
> Subject: [cisco-voip] Bridge upgrade vs. sub(s)
>
> Hi,
>
> I'm preparing for an upgrade of a cluster (just one sub) running 7.1(3) on
> DL380G4s (7845H2) to 8.6(2) on DL380G6s. To make things interesting, the old
> version doesn't even recognize the new servers, and the new version is not
> supported on the old metal except for bridge upgrade. Needless to say, the
> upgrade has to be done with minimal downtime, something like 15min to switch
> would be acceptable, not more.
>
> I'm planning to proceed as such:
>
> 1) Shut down the pub, while the sub continues serving the live network.
> 2) Boot the pub using GRML or such Linux live CD and make a full disk
> copy to external storage. Maybe also break the mirrors and insert
> additional disks to have a physical copy through RAID, putting the
> original disks at a safe place.
> 3) Isolate the pub in a replica of the original network including
> default gateway, DNS and NTP servers as needed. Boot it up again.
> 4) Do the upgrade procedure to 8.6(2) as documented, ending up with
> a bridged upgrade only machine.
> *** Here the docs state I have to also do this to the sub(s). Of
> course I can't, they are serving the live network here. Is this
> fatal, or is my procedure a proper workaround?
> 5) Do a DRS backup of the bridge-upgraded pub.
> 6) Restore the original pub using the copies made in step (2), plug it
> back into the live network, boot it up and have the live network
> working fully redundant again.
> 7) Install 8.6(2) on a new DL380G6 plugged into the replica network.
> 8) Restore the DRS backup from (5) to this new pub.
> 9) Make sure the pub is working correctly, except for the missing sub.
> 10) Now add a second DL380G6 to the replica network, install 8.6(2) as
> a sub on it, and reestablish the cluster. Manually make sure all
> files in the TFTP server of the original sub are available on the
> new sub as well, as that one isn't restored from backup.
> 11) After making a lot of tests and sanity checks, swap in the new
> cluster in a short downtime window.
>
> Does this plan make any sense? Is there a better one? I'm specifically
> bothered by the documented need to perform the bridged upgrade on all nodes
> in unison, and then to restore first to the pub, then to all the subs. Of
> course that's impossible without inacceptable downtimes. But I assume that I
> cannot, after step (6), just isolate the old sub in the same way as the pub
> before, doing a bridge upgrade of that isolated sub only to get hold of a
> DRS backup of the sub?
>
> Any hints or ideas welcome,
> TIA,
> Andre.
> --
> Cool .signatures are so 90s...
>
> -> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


gwenzel at conres

Feb 29, 2012, 6:07 AM

Post #14 of 25 (1745 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
During your upgrade to the bridge server (aka swing server) you have the
opportunity to change the destination ip address and hostname. If you
didn't change the name or ip address then you must restore it on the
identical server.
Hostname
Ip address



-----Original Message-----
From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Joe Albertini
Sent: Wednesday, February 29, 2012 9:05 AM
To: Mike
Cc: <cisco-voip [at] puck>
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)

I thought to restore the CUCM database to another server it had to have
the same IP address of the existing PUB server? This procedure would
also require new license generation as well.

Regards,
Joe

On Feb 28, 2012, at 8:57, "Mike " <mikeeo [at] msn> wrote:

> This may not be practical, but have you considered a swing server? We
> have done this in the past. You take an IBM/HP equivalent (7816-I4)
> load existing version on that and restore from production. Then
> upgrade that to 8.6 and backup. Then load 8.6 on your new DL380s and
restore.
>
> This leaves your production environment untouched and now you have a
> complete copy running 8.6. Just swap the Ethernet cables and reset the

> phones and you are set.
>
> -----Original Message-----
> From: cisco-voip-bounces [at] puck
> [mailto:cisco-voip-bounces [at] puck] On Behalf Of Beck, Andre
> Sent: Monday, February 27, 2012 11:55 AM
> To: cisco-voip [at] puck
> Subject: [cisco-voip] Bridge upgrade vs. sub(s)
>
> Hi,
>
> I'm preparing for an upgrade of a cluster (just one sub) running
> 7.1(3) on DL380G4s (7845H2) to 8.6(2) on DL380G6s. To make things
> interesting, the old version doesn't even recognize the new servers,
> and the new version is not supported on the old metal except for
> bridge upgrade. Needless to say, the upgrade has to be done with
> minimal downtime, something like 15min to switch would be acceptable,
not more.
>
> I'm planning to proceed as such:
>
> 1) Shut down the pub, while the sub continues serving the live
network.
> 2) Boot the pub using GRML or such Linux live CD and make a full disk
> copy to external storage. Maybe also break the mirrors and insert
> additional disks to have a physical copy through RAID, putting the
> original disks at a safe place.
> 3) Isolate the pub in a replica of the original network including
> default gateway, DNS and NTP servers as needed. Boot it up again.
> 4) Do the upgrade procedure to 8.6(2) as documented, ending up with
> a bridged upgrade only machine.
> *** Here the docs state I have to also do this to the sub(s). Of
> course I can't, they are serving the live network here. Is this
> fatal, or is my procedure a proper workaround?
> 5) Do a DRS backup of the bridge-upgraded pub.
> 6) Restore the original pub using the copies made in step (2), plug it
> back into the live network, boot it up and have the live network
> working fully redundant again.
> 7) Install 8.6(2) on a new DL380G6 plugged into the replica network.
> 8) Restore the DRS backup from (5) to this new pub.
> 9) Make sure the pub is working correctly, except for the missing sub.
> 10) Now add a second DL380G6 to the replica network, install 8.6(2) as
> a sub on it, and reestablish the cluster. Manually make sure all
> files in the TFTP server of the original sub are available on the
> new sub as well, as that one isn't restored from backup.
> 11) After making a lot of tests and sanity checks, swap in the new
> cluster in a short downtime window.
>
> Does this plan make any sense? Is there a better one? I'm specifically

> bothered by the documented need to perform the bridged upgrade on all
> nodes in unison, and then to restore first to the pub, then to all the

> subs. Of course that's impossible without inacceptable downtimes. But
> I assume that I cannot, after step (6), just isolate the old sub in
> the same way as the pub before, doing a bridge upgrade of that
> isolated sub only to get hold of a DRS backup of the sub?
>
> Any hints or ideas welcome,
> TIA,
> Andre.
> --
> Cool .signatures are so 90s...
>
> -> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

This message w/attachments (message) is solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any products.


_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


jalbertini at ymail

Feb 29, 2012, 6:10 AM

Post #15 of 25 (1742 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Aah, got it.  Thanks Greg.



________________________________
From: Gregory Wenzel <gwenzel [at] conres>
To: Joe Albertini <jalbertini [at] ymail>; Mike <mikeeo [at] msn>
Cc: cisco-voip [at] puck
Sent: Wednesday, February 29, 2012 9:07 AM
Subject: RE: [cisco-voip] Bridge upgrade vs. sub(s)

During your upgrade to the bridge server (aka swing server) you have the
opportunity to change the destination ip address and hostname. If you
didn't change the name or ip address then you must restore it on the
identical server.
Hostname
Ip address



-----Original Message-----
From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Joe Albertini
Sent: Wednesday, February 29, 2012 9:05 AM
To: Mike
Cc: <cisco-voip [at] puck>
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)

I thought to restore the CUCM database to another server it had to have
the same IP address of the existing PUB server? This procedure would
also require new license generation as well.

Regards,
Joe

On Feb 28, 2012, at 8:57, "Mike " <mikeeo [at] msn> wrote:

> This may not be practical, but have you considered a swing server? We
> have done this in the past. You take an IBM/HP equivalent (7816-I4)
> load existing version on that and restore from production. Then
> upgrade that to 8.6 and backup. Then load 8.6 on your new DL380s and
restore.
>
> This leaves your production environment untouched and now you have a
> complete copy running 8.6. Just swap the Ethernet cables and reset the

> phones and you are set.
>
> -----Original Message-----
> From: cisco-voip-bounces [at] puck
> [mailto:cisco-voip-bounces [at] puck] On Behalf Of Beck, Andre
> Sent: Monday, February 27, 2012 11:55 AM
> To: cisco-voip [at] puck
> Subject: [cisco-voip] Bridge upgrade vs. sub(s)
>
> Hi,
>
> I'm preparing for an upgrade of a cluster (just one sub) running
> 7.1(3) on DL380G4s (7845H2) to 8.6(2) on DL380G6s. To make things
> interesting, the old version doesn't even recognize the new servers,
> and the new version is not supported on the old metal except for
> bridge upgrade. Needless to say, the upgrade has to be done with
> minimal downtime, something like 15min to switch would be acceptable,
not more.
>
> I'm planning to proceed as such:
>
> 1) Shut down the pub, while the sub continues serving the live
network.
> 2) Boot the pub using GRML or such Linux live CD and make a full disk
>  copy to external storage. Maybe also break the mirrors and insert
>  additional disks to have a physical copy through RAID, putting the
>  original disks at a safe place.
> 3) Isolate the pub in a replica of the original network including
>  default gateway, DNS and NTP servers as needed. Boot it up again.
> 4) Do the upgrade procedure to 8.6(2) as documented, ending up with
>  a bridged upgrade only machine.
>  *** Here the docs state I have to also do this to the sub(s). Of
>  course I can't, they are serving the live network here. Is this
>  fatal, or is my procedure a proper workaround?
> 5) Do a DRS backup of the bridge-upgraded pub.
> 6) Restore the original pub using the copies made in step (2), plug it
>  back into the live network, boot it up and have the live network
>  working fully redundant again.
> 7) Install 8.6(2) on a new DL380G6 plugged into the replica network.
> 8) Restore the DRS backup from (5) to this new pub.
> 9) Make sure the pub is working correctly, except for the missing sub.
> 10) Now add a second DL380G6 to the replica network, install 8.6(2) as
>    a sub on it, and reestablish the cluster. Manually make sure all
>    files in the TFTP server of the original sub are available on the
>    new sub as well, as that one isn't restored from backup.
> 11) After making a lot of tests and sanity checks, swap in the new
>    cluster in a short downtime window.
>
> Does this plan make any sense? Is there a better one? I'm specifically

> bothered by the documented need to perform the bridged upgrade on all
> nodes in unison, and then to restore first to the pub, then to all the

> subs. Of course that's impossible without inacceptable downtimes. But
> I assume that I cannot, after step (6), just isolate the old sub in
> the same way as the pub before, doing a bridge upgrade of that
> isolated sub only to get hold of a DRS backup of the sub?
>
> Any hints or ideas welcome,
> TIA,
> Andre.
> --
>                    Cool .signatures are so 90s...
>
> -> Andre Beck    +++ ABP-RIPE +++      IBH IT-Service GmbH, Dresden <-
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

This message w/attachments (message) is solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any products.


cisco-voip at ibh

Feb 29, 2012, 6:47 AM

Post #16 of 25 (1738 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Hi Ryan,

On Tue, Feb 28, 2012 at 12:40:04PM -0500, Ryan Ratliff wrote:
> +1 for Mike's suggestion of having extra server(s) to use for purposes like this (and a lab mock up of the cluster, doesn't everyone have one of these? ;P ).

Sadly I don't have an equivalent class of server to do that, if I had it
would have been my preferred procedure. The point in this installation
is, the hardware was a tad too new when we had to roll out, the DL380G6s
could not run 7.x and 8.x was slow in coming to release, but the customer
insisted on not buying old hardware. So we reactivated a couple of old
G4s and the G6s served as ESX servers meanwhile, until 8.x would become
ready. As usual, the provisorium became entrenched and other things were
more important, so the real transition is happening more than two years
later. Main driver being the end of support of the G4s BTW, the customer
isn't really driven by features.

> > I've read the "not
> > supported except for bridged upgrade" warning signs as "won't work, except
> > allowing you to make a DRS backup", not "will probably work quite well,
> > just don't call TAC when it breaks".
>
> A word on bridge upgrades. The bridge upgrade means that the only services that will run are the ones necessary for you to take a backup. That is it. You get no phone service, no tftp, only DRF. There are no licensing requirements (aside from rehosting for the new hardware) because nothing that would even read the license files is running.

Thanks for spelling that out clearly. I *expected* something like that,
but didn't know how to qualify - except maybe by posting here. I wasn't
left in the cold ;)

> > When I read the release notes correctly, upgrading to 8.6 will involve an
> > automatic reboot that is not optional. One may return to the original
> > partition after that, but it will cause an outage.
>
> You are reading correctly. Basically we can't actually run the files necessary to upgrade the OS due to incompatibilities between RHEL versions. That middle reboot is actually doing an entirely fresh install on the inactive partition and as such there's no web services to monitor the upgrade, no ssh, etc. If you were to watch the console of the server you'd see the same old blue screens as it progresses through.

Ah yep. Thanks for explaining the reasoning, I perfectly understand these
issues. There's a limit to forward compatibility of 6 year old enterprise
Linux distributions, even if hidden in an appliance ;)

Luckily, virtualization is coming to the rescue, snapshots instead of
partitions will do the job better.

> When it's all said and done as long as you aren't on the older 7825/28s you can still switch back to the old version though.

7825/28 is DL320 style hardware with those pesky BIOS "RAID" things? I
always avoided that device class. I did never understand why they were
supported, while DL360s (with real RAIDs) were not. Probably a "good
enough" decision with lots of Layer 8 (finances) involved.

> Testing in the lab is highly recommended so you are familiar with the process. VMs are cheap and for lab purposes it's a great exercise to mock up your entire cluster and run through the upgrade just to see what it involves.

Second that. It just doesnt help with hardware-specific issues. I'll see
how to deal with that. Maybe a spare G4 can be gotten hold of somehow...

> -Ryan

Thanks a lot for the clarifications,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


cisco-voip at ibh

Feb 29, 2012, 7:46 AM

Post #17 of 25 (1740 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Hi Mike,

On Tue, Feb 28, 2012 at 05:49:37PM -0500, Mike wrote:
> Once you install any release prior 8.x on VMWARE it marks the database as
> unsupported even when you upgrade to ver8.x. It's a huge issue in the field
> and I wish Cisco would address it.

Oops.

Unce upon a time, I ported my CCM 5.1 to 7.0 via an intermediate ESX VM.
I don't remember the exact steps involved (it turned out to be a little
sophisticated), but I'm somewhat sure the DB, or even the entire
installation, was on a VM for some time. Can I check whether the DB
is now marked as unsupported?

TIA,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


cisco-voip at ibh

Feb 29, 2012, 8:07 AM

Post #18 of 25 (1737 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Re Mike,

On Tue, Feb 28, 2012 at 08:57:44AM -0500, Mike wrote:
> This may not be practical, but have you considered a swing server? We have
> done this in the past. You take an IBM/HP equivalent (7816-I4) load existing
> version on that and restore from production. Then upgrade that to 8.6 and
> backup. Then load 8.6 on your new DL380s and restore.

I haven't considered that as there is no identical server available, at
least not easily. But you said something very interesting: Take any MCS-
equivalent server that supports running both versions. If that really
is sufficient (I don't think I need working licenses just to perform
the DRS backup, and even if, the MAC could be - ahem - tinkered with
in the isolated network), that would ease things considerably.

> This leaves your production environment untouched and now you have a
> complete copy running 8.6. Just swap the Ethernet cables and reset the
> phones and you are set.

I'll see if any supported server is available. There's quite a chance
of that, and as you said, it would make the transition even less risky
(human error during the initial steps in my procedure could still wipe
the original pub blank).

Thanks,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


mikeeo at msn

Feb 29, 2012, 9:05 AM

Post #19 of 25 (1737 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
I used to know the database value, but I'm sure TAC can tell you.

-----Original Message-----
From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Beck, Andre
Sent: Wednesday, February 29, 2012 10:47 AM
To: Mike
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)

Hi Mike,

On Tue, Feb 28, 2012 at 05:49:37PM -0500, Mike wrote:
> Once you install any release prior 8.x on VMWARE it marks the database
> as unsupported even when you upgrade to ver8.x. It's a huge issue in
> the field and I wish Cisco would address it.

Oops.

Unce upon a time, I ported my CCM 5.1 to 7.0 via an intermediate ESX VM.
I don't remember the exact steps involved (it turned out to be a little
sophisticated), but I'm somewhat sure the DB, or even the entire
installation, was on a VM for some time. Can I check whether the DB is now
marked as unsupported?

TIA,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


mikeeo at msn

Feb 29, 2012, 9:36 AM

Post #20 of 25 (1744 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Any IBM x3250 (7816-I4) is less than 500.00 on Ebay.

-----Original Message-----
From: Beck, Andre [mailto:cisco-voip [at] ibh]
Sent: Wednesday, February 29, 2012 11:07 AM
To: Mike
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)

Re Mike,

On Tue, Feb 28, 2012 at 08:57:44AM -0500, Mike wrote:
> This may not be practical, but have you considered a swing server? We
> have done this in the past. You take an IBM/HP equivalent (7816-I4)
> load existing version on that and restore from production. Then
> upgrade that to 8.6 and backup. Then load 8.6 on your new DL380s and
restore.

I haven't considered that as there is no identical server available, at
least not easily. But you said something very interesting: Take any MCS-
equivalent server that supports running both versions. If that really is
sufficient (I don't think I need working licenses just to perform the DRS
backup, and even if, the MAC could be - ahem - tinkered with in the isolated
network), that would ease things considerably.

> This leaves your production environment untouched and now you have a
> complete copy running 8.6. Just swap the Ethernet cables and reset the
> phones and you are set.

I'll see if any supported server is available. There's quite a chance of
that, and as you said, it would make the transition even less risky (human
error during the initial steps in my procedure could still wipe the original
pub blank).

Thanks,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


mynewlogin at gmail

Feb 29, 2012, 11:43 PM

Post #21 of 25 (1726 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Hi all!

I need to make upgrade of CUCM version 4.1 to 8.6.
Now CUCM is on DL380-G3.
New servers are UCS C200M2 with ESXi hypervisor.

So, we can't make direct upgrade from 4.1 to 8.6 and on DL380-G3 we can't
upgrade to any 8.x version.

What can be the best upgrade scenarios?


2012/2/29 Mike <mikeeo [at] msn>

> I used to know the database value, but I'm sure TAC can tell you.
>
> -----Original Message-----
> From: cisco-voip-bounces [at] puck
> [mailto:cisco-voip-bounces [at] puck] On Behalf Of Beck, Andre
> Sent: Wednesday, February 29, 2012 10:47 AM
> To: Mike
> Cc: cisco-voip [at] puck
> Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)
>
> Hi Mike,
>
> On Tue, Feb 28, 2012 at 05:49:37PM -0500, Mike wrote:
> > Once you install any release prior 8.x on VMWARE it marks the database
> > as unsupported even when you upgrade to ver8.x. It's a huge issue in
> > the field and I wish Cisco would address it.
>
> Oops.
>
> Unce upon a time, I ported my CCM 5.1 to 7.0 via an intermediate ESX VM.
> I don't remember the exact steps involved (it turned out to be a little
> sophisticated), but I'm somewhat sure the DB, or even the entire
> installation, was on a VM for some time. Can I check whether the DB is now
> marked as unsupported?
>
> TIA,
> Andre.
> --
> Cool .signatures are so 90s...
>
> -> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>



--
ú ÐÏ×ÁÇÏÀ, áÎÄÒ¦Ê íÁÔÌÁ×ÓØËÉÊ.


mikeeo at msn

Mar 1, 2012, 5:31 AM

Post #22 of 25 (1711 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
You will need to build them side by side. Export/import is your friend.



From: Andrii Matlavskyi [mailto:mynewlogin [at] gmail]
Sent: Thursday, March 01, 2012 2:43 AM
To: Mike
Cc: Beck, Andre; cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)




Hi all!

I need to make upgrade of CUCM version 4.1 to 8.6.
Now CUCM is on DL380-G3.
New servers are UCS C200M2 with ESXi hypervisor.

So, we can't make direct upgrade from 4.1 to 8.6 and on DL380-G3 we can't
upgrade to any 8.x version.

What can be the best upgrade scenarios?



2012/2/29 Mike <mikeeo [at] msn>

I used to know the database value, but I'm sure TAC can tell you.


-----Original Message-----
From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Beck, Andre
Sent: Wednesday, February 29, 2012 10:47 AM
To: Mike
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)

Hi Mike,

On Tue, Feb 28, 2012 at 05:49:37PM -0500, Mike wrote:
> Once you install any release prior 8.x on VMWARE it marks the database
> as unsupported even when you upgrade to ver8.x. It's a huge issue in
> the field and I wish Cisco would address it.

Oops.

Unce upon a time, I ported my CCM 5.1 to 7.0 via an intermediate ESX VM.
I don't remember the exact steps involved (it turned out to be a little
sophisticated), but I'm somewhat sure the DB, or even the entire
installation, was on a VM for some time. Can I check whether the DB is now
marked as unsupported?

TIA,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip




--
Ç ïîâàãîþ, Àíäð³é Ìàòëàâñüêèé.


rratliff at cisco

Mar 1, 2012, 11:24 AM

Post #23 of 25 (1698 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
There's also the DMA option up to 7.1(5) and then to 8.5 where he can backup and restore onto the vm.

Personally I think it'll be much faster and less disruptive to just bring them up side by side and manually move things over. Take this as an opportunity to clean up your config, optimize dialplan, etc.


-Ryan

On Mar 1, 2012, at 8:31 AM, Mike wrote:

You will need to build them side by side. Export/import is your friend.

From: Andrii Matlavskyi [mailto:mynewlogin [at] gmail]
Sent: Thursday, March 01, 2012 2:43 AM
To: Mike
Cc: Beck, Andre; cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)


Hi all!

I need to make upgrade of CUCM version 4.1 to 8.6.
Now CUCM is on DL380-G3.
New servers are UCS C200M2 with ESXi hypervisor.

So, we can't make direct upgrade from 4.1 to 8.6 and on DL380-G3 we can't upgrade to any 8.x version.

What can be the best upgrade scenarios?


2012/2/29 Mike <mikeeo [at] msn>
I used to know the database value, but I'm sure TAC can tell you.

-----Original Message-----
From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Beck, Andre
Sent: Wednesday, February 29, 2012 10:47 AM
To: Mike
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] Bridge upgrade vs. sub(s)

Hi Mike,

On Tue, Feb 28, 2012 at 05:49:37PM -0500, Mike wrote:
> Once you install any release prior 8.x on VMWARE it marks the database
> as unsupported even when you upgrade to ver8.x. It's a huge issue in
> the field and I wish Cisco would address it.

Oops.

Unce upon a time, I ported my CCM 5.1 to 7.0 via an intermediate ESX VM.
I don't remember the exact steps involved (it turned out to be a little
sophisticated), but I'm somewhat sure the DB, or even the entire
installation, was on a VM for some time. Can I check whether the DB is now
marked as unsupported?

TIA,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip



--
Ç ïîâàãîþ, Àíäð³é Ìàòëàâñüêèé.
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


mynewlogin at gmail

Mar 2, 2012, 2:02 AM

Post #24 of 25 (1709 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Hi Beck!
Thank you for the information.

Could you please give any recommendations for upgrade steps considering the
fact that I don't have any server for intermediate upgrade steps to 6.x/7.x
version?

Mike, where can I find additional information about unsupportable database
in case of installation of CUCM version 7.x on VMWare and upgrading to 8.x?


2012/3/1 Beck, Andre <beck [at] ibh>

> Hi Andrii,
>
> On Thu, Mar 01, 2012 at 09:43:02AM +0200, Andrii Matlavskyi wrote:
> > Hi all!
> >
> > I need to make upgrade of CUCM version 4.1 to 8.6.
>
> Ugh. Tough luck. My upgrade from 4.1(3) was to 5.0. The last upgrade I
> had to do of a 4.x version turned out to be a manual takeover of all
> configuration (luckily, it was a small setup of less than 100 phones
> and a welcome break with old stuff and opportunity to clean up historic
> cuft). The reason for doing it manually was that I didn't trust DMA
> enough to install it on the SPOF fragile old non-clustered 4.x box
> (remember, DMA actually drops an entire RDBMS on the poor machine),
> and we couldn't get hold of *ANY* installation media for the OS in
> question. Original media was MIA, Cisco could provide CCM install media
> to no avail, but Win2k3 appliance OS media - no chance. So I tried
> for a while to prep a W2k3 install to accept CCM, but gave up on that
> finally - burned too much time. Time better used for a fresh start.
>
> What you can do depends entirely on software and hardware you have
> available or can get hold of.
>
> > Now CUCM is on DL380-G3.
> > New servers are UCS C200M2 with ESXi hypervisor.
>
> Uhm. So you want to go virtualized. That makes things a little harder,
> given
> Mike's advice to not run 7.x in a VM even as an intermediate step. The
> problem
> being, you cannot go from 4.x to 8.x directly as the DMA was phased out
> with
> 7.x the last supported target. And you need DMA.
>
> > So, we can't make direct upgrade from 4.1 to 8.6 and on DL380-G3 we can't
> > upgrade to any 8.x version.
> >
> > What can be the best upgrade scenarios?
>
> I would try to proceed as such:
>
> 1) Clone the existing 4.1 onto another machine. That could be another
> DL380G3. If you can live with some downtime, it can be the one you
> already have. If you must minimize downtime, and want to risk a DMA
> on the original pub, there is no need to clone.
> 2) Install DMA (on the cloned or original 4.1) and produce a DMA dump
> of the DB. Be aware that DMA is a full Informix install, a bunch
> of scripts reading the old DB and merging it into new structures in
> Informix, and finally a full dump of the Informix tables into an
> external file.
> 3) On some hardware that is feasible, install 7.1(3) or something that
> is similarly reliable, works on your hardware and you can get hold of
> the media easily for (anything 6.x or 7.x should do). Import the DMA
> to this machine.
> 4) Upgrade this machine to 8.6 and export using DRS (the standard backup
> system that replaced BARS). The upgrade could be direct or bridged,
> depending on hardware. It makes no difference, as all you want to
> produce is a DRS backup.
> 5) Do a completely new installation of 8.6 in a VM on your target platform,
> based on machine templates provided by Cisco, then restore from the DRS
> backup. If it looks plausible, deal with licensing. Regarding licensing,
> it *MAY* be necessary to deal with that already on the DMA import step
> to 7.x. There was no device licensing on 4.x, so Cisco would just sign
> you a license file produced in the DMA step. As licensing has changed
> again in 8.6, it may be too late to start that process here. I simply
> don't know, I don't even know if the process for licensing all your
> phones on DMA upgrade is still available, but I assume it is.
>
> That's the raw sketchy outline of a plan I would start with. Details like
> to fill in themselves in the process, sometimes vigorously rearchitecting
> your nice theory ;)
>
> HTH,
> Andre.
> --
> Cool .signatures are so 90s...
>
> -> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
>



--
ú ÐÏ×ÁÇÏÀ, áÎÄÒ¦Ê íÁÔÌÁ×ÓØËÉÊ.


cisco-voip at ibh

May 15, 2012, 9:00 AM

Post #25 of 25 (1438 views)
Permalink
Re: Bridge upgrade vs. sub(s) [In reply to]
Re folks,

just to follow up:

On Wed, Feb 29, 2012 at 03:47:32PM +0100, Beck, Andre wrote:
>
> The point in this installation
> is, the hardware was a tad too new when we had to roll out, the DL380G6s
> could not run 7.x and 8.x was slow in coming to release, but the customer
> insisted on not buying old hardware. So we reactivated a couple of old
> G4s and the G6s served as ESX servers meanwhile, until 8.x would become
> ready.

The procedure became a lot easier than expected. The key to that was, I had
tested 7.x on the DL360G6s using the 7.0 bootable media, which didn't even
find the SATA DVD drive. This time though, I had bootable 7.1.3 media
available, and before going the unsupported VMware way, I just tried that
media on the physical DL380G6s. What should I say - it discovered the
server flawlessly and proceeded to installation...

So it actually was just a matter of installing a new cluster running 7.1.3
on the DL380G6s, importing the latest DRF, upgrading that cluster to
8.6.2.latest (involved a penalty roundtrip over licensing) and then
swapping that in at a proper time.

It went well mostly, with some details going really wrong ;)

Thanks for the brainstorming,
Andre.
--
Cool .signatures are so 90s...

-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

Cisco voip RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.