<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.apple-style-span
        {mso-style-name:apple-style-span;}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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)?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank You,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Matthew<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Mike [mailto:mikeeo@msn.com] <br><b>Sent:</b> Tuesday, February 28, 2012 2:50 PM<br><b>To:</b> Matthew Ballard; 'Ryan Ratliff'; 'Beck, Andre'<br><b>Cc:</b> cisco-voip@puck.nether.net<br><b>Subject:</b> RE: [cisco-voip] Bridge upgrade vs. sub(s)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a> <a href="mailto:[mailto:cisco-voip-bounces@puck.nether.net]">[mailto:cisco-voip-bounces@puck.nether.net]</a> <b>On Behalf Of </b>Matthew Ballard<br><b>Sent:</b> Tuesday, February 28, 2012 4:07 PM<br><b>To:</b> Ryan Ratliff; Beck, Andre<br><b>Cc:</b> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br><b>Subject:</b> Re: [cisco-voip] Bridge upgrade vs. sub(s)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Matthew Ballard<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Network Manager<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Otis College of Art and Design<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><a href="mailto:mballard@otis.edu">mballard@otis.edu</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a> [<a href="mailto:cisco-voip-bounces@puck.nether.net">mailto:cisco-voip-bounces@puck.nether.net</a>] <b>On Behalf Of </b>Ryan Ratliff<br><b>Sent:</b> Tuesday, February 28, 2012 9:40 AM<br><b>To:</b> Beck, Andre<br><b>Cc:</b> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br><b>Subject:</b> Re: [cisco-voip] Bridge upgrade vs. sub(s)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>+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 ).<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>I've read the "not<br>supported except for bridged upgrade" warning signs as "won't work, except<br>allowing you to make a DRS backup", not "will probably work quite well,<br>just don't call TAC when it breaks".<o:p></o:p></p></blockquote><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>When I read the release notes correctly, upgrading to 8.6 will involve an<br>automatic reboot that is not optional. One may return to the original<br>partition after that, but it will cause an outage.<o:p></o:p></p></blockquote><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal>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. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal><span style='font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black'>-Ryan<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Feb 28, 2012, at 7:55 AM, Beck, Andre wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'>Hi Erick,<br><br>On Mon, Feb 27, 2012 at 12:35:05PM -0600, Erick Wellnitz wrote:<o:p></o:p></p><p class=MsoNormal>Does a reboot for the upgrade to switch from the inactive partition to the<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>active partion take longer than 15 minutes?<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><br>Dunno, but I've not even thought about that so far. I've read the "not<br>supported except for bridged upgrade" warning signs as "won't work, except<br>allowing you to make a DRS backup", not "will probably work quite well,<br>just don't call TAC when it breaks".<o:p></o:p></p><p class=MsoNormal>What I would do:<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>1. Run the upgrade without a reboot or switching versions<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><br>When I read the release notes correctly, upgrading to 8.6 will involve an<br>automatic reboot that is not optional. One may return to the original<br>partition after that, but it will cause an outage. Details are not<br>documented, and I never did such an upgrade before, thus I wanted to do<br>things in an isolated network where it's clear the live network could not<br>be killed by it.<o:p></o:p></p><p class=MsoNormal>2. During my outage window switch versions and reboot<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>---at this point your system is functioning on the old hardware<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><br>Provided that the bridged upgrade does not prevent any services that are<br>not essential for DRS from running. Or, in other words, the system working<br>well except for not being supported when kept running in this state. I<br>couldn't grok from the release notes what would happen, so I wanted to<br>play it safe. Also note that this will create a licensing problem: I<br>would have to aquire licenses to run 8.6 on the old hardware (MAC) and<br>later move them to the new hardware. I had hopes to avoid that by moving<br>to the new hardware through DRS before touching the licensing, and be<br>able to resolve any licensing issues (which I expect to crop up for sure,<br>knowing my Murphy lessons well) in the isolated setup without time pressure.<o:p></o:p></p><p class=MsoNormal>3. Take a DRS backup for restore to the new cluster<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>4. Restore to new cluster<o:p></o:p></p></blockquote><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>5. Switch TFTP settings<o:p></o:p></p></blockquote><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>--may need to reduce your DHCP lease time<o:p></o:p></p></blockquote><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>6. Reset all devices/point gateways to new cluster<o:p></o:p></p></blockquote><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>---at this point you are usig the new hardware<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><br>I'm not planning to have the cluster on other IPs after the upgrade. But<br>I could instead do all the preps starting with your step (4) in my<br>isolated network as well, so that's not a problem.<o:p></o:p></p><p class=MsoNormal>I'd imagine there would be less than 15 minutes downtime with this<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>procedure but I've not done a bridged upgrade with 8.6 yet<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><br>The basic problem with the procedure, from my PoV, is that it's all-or-<br>nothing with regard to it working correctly. If anything goes wrong in<br>the first two steps, I'm in a time-pressure situation to fix it ASAP,<br>while the main motive of my procedure is to play it safe and have the<br>old cluster run unaffected most of the time while I can freak around with<br>the new one (maybe for days until all issues are fixed).<br><br>Of course, it all hinges on the question whether "unsupported for anything<br>but DRS" is enforced or not.<br><br>Feels like I'm going to do some test scenarios in a virtualized cluster<br>prior to making decisions here, but that doesn't exactly allow to replicate<br>the "hardware no longer supported" case forcing me into the bridge upgrade<br>in the first place...<br><br>Thanks,<br>Andre. <br>-- <br>                   Cool .signatures are so 90s...<br><br>-> Andre Beck    +++ ABP-RIPE +++      IBH IT-Service GmbH, Dresden <-<br>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p></div></body></html>