Accepted Solution

Data ontap upgrading from 7.3.5 to 8.1

Hi all,

I was looking for the procedure to upgrade data-ontap from 7.3.5 to 8.1 .It was said that we have to go through 8.0.1 ,since it was different family..

if we can upgrade , what will be different from normal upgrade..


Re: Data ontap upgrading from 7.3.5 to 8.1

The upgrade advisor is really nice. Without it many upgrades wouldn't be as smooth. In your case with you would update ontap twice. The procedure should be step by step in the output. You can ndu to 8.0.x then ndu again to 8.1 as long as you meet the requirements which upgrade advisor will check.

Re: Data ontap upgrading from 7.3.5 to 8.1

The Upgrade advisor is really helpful. At the same time I suggest you to have a look at the Data ONTAP 8.1 Upgrade and Revert/Downgrade Guide.


Re: Data ontap upgrading from 7.3.5 to 8.1

You do not need to leap-frog the upgrade.  You can go directly to 8.1 from 7.3.5.  As Scott stated the upgrade advisor is your frend if you are sending ASUPs.  This particular upgrade from 7G to 8.x is a bit different from upgrades and NDUs you have experienced in the past.  1st make sure ALL your hardware and firmware are up to date first, don't rely on the ONTAP package to do it for you. Also update the qual_devices files.  Also make sure you have MPHA cabling as we don't allow single path anymore (sysconfig -a at the top will tell you).  Once you get that all done then upgrade 8.1 using NDU steps.  Plan for each controller upgrade to take about 30-50 minutes since you are going from the 7G kernel to the 8x kernel (which are different).

Re: Data ontap upgrading from 7.3.5 to 8.1

While it may seem like a pain, when doing NDU between major releases it is a best practice to do interim upgrades.  With NDU, it's less important to do what's convenient than it is to do what's safe and reliable.  At a minimum, you want to upgrade to the latest GA release of the current major version (7.3.7 in this case) and then to the next major version (I've upgraded lab systems from 7.3.6 to 8.1...but that's lab systems).  There are a lot of things that get changed during major release upgrades so you want to put as much of that workload on the interim upgrades to ensure failover/giveback don't exceed client timeouts.  The jump from 7.3 to 8.x is a particularly large leap because we have to install FreeBSD.  As Spence mentioned, there's also all the firmware updates you want to get out of the way.

Re: Data ontap upgrading from 7.3.5 to 8.1


I see some logic behind doing two 'smaller' upgrades instead of one 'bigger' (it sounds safer), but NetApp Upgrade Advisor doesn't mention it & provides steps for a direct upgrade.

Also it is a bit controversial whether two failovers & failbacks are better (safer) than just one.


Re: Data ontap upgrading from 7.3.5 to 8.1

Agreed. As usual I usually upgrade to latest 7.3.x then 8.0.x then 8.1 even if not needed. An extra bit of time but not much.

Also root volume size can be an issue. Minimum sizes with 8.0 and 8.1 of 250 and 300g on 6200 with 8.1. Need to increase before the 7.3 upgrade.

Sent from my iPhone 4S

Re: Data ontap upgrading from 7.3.5 to 8.1

I tend to go one major release at a time even though extra work. A bit old school and maybe some superstition but since it always has worked and allows a more incremental revert capability I prefer it. But exceptions to that rule sometimes. And I can see it being more of a cifs and San hassle if mpio issues.

Re: Data ontap upgrading from 7.3.5 to 8.1

Something I started doing a year or more ago as a "best practice" is asking the customer to test MPIO/DSM before we start.  Then I run WireGauge and perform a failover/giveback.  I want to find any pre-existing issues and single-points-of-failure before I start making changes.  It's never fun to have something go wrong and although you're certain it wasn't something you did, it looks that way to the customer.

Re: Data ontap upgrading from 7.3.5 to 8.1

I’m really liking OnCommand Insight (SanScreen) now too with the compliance reports and alerts with servers that can’t multipath.