Hello, I am trying to convert an AFF (A300) HA pair of controllers into a FAS8200. We got these nodes really cheap as an add-on to a much larger purchase and want to use it in your lab with SSD, SATA and SAS drives. I tried going into Loader and doing 'set-defaults', but noticed the 'bootarg.init.flash_optimized false' was still set so I tried running the command below and got an access denied message...
LOADER-A> setenv bootarg.init.flash_optimized false Cannot set variable *** command status = Access denied(-69)
Please help, how can I perform this conversion? Thanks!
It was possible in BIOS <=9.3 and ONTAP <=8.3.2 to change it, using the LOADER, which then writes the setting to the boot media, but it is now a WORM variable - it can be set, but not unset.
It's not impossible to change it, but not inside the box of what we provide as "ONTAP" - it's not supported or publically documented. If it's a mis-ship or a mis-quote, please contact your account team and support for procedure to fix. And if they need help - they're welcome to contact me.
So I was basically right when I said you could do it ONLY with 80X0 because as @AlexDawson mentioned, it is possible only with ONTAP 8.3.2 and lower (BIOS 9.3 and lower) to change the flash optimized option in the LOADER.
And only AFF80X0 systems support ONTAP 8.3 (See HWU) because AFF was introduced with ONTAP 8.3 for AFF80X0.
And the smallest versions for A300/FAS8200 are BIOS 11 and ONTAP 9.1 (See HWU). Therefore, you cannot change the flash optimized option in those models if you bought the system not in pieces but rather as a storage system.
But you can change the flash optimized option with ANY ONTAP/BIOS version for any AFF in the LOADER, in case if you bought your controller as a separate FRU (for example if you purchased X3172A separately; it is the main board for A300/FAS8200), and as Alex mentioned, you can do it only ONCE.
When we purchased these nodes, they did not have a purpose. I think NetApp at the time was really trying to push the AFF line (A300, etc) so they were almost giving them away (as they did for us). We had a really large purchase at the time, and with how fast we are growing our NetApp infrastructure, figured we could use them somewhere. Well, that somewhere is our lab so we can have supported gear there finally. As of now, we only have an old unsupported FAS6220. Since we want a hybrid system with both spinning disk and flash, we were hoping to just be able to remove the all flash personalities and make it a FAS8200 system since it's the same hardware. So, to answer your question @AlexDawson, no this wasn't a mis-ship/mis-config, it is a repurpose after the fact... So, what steps would I need to do to convert it (if it's even possible)? This system will only ever be a FAS8200, never going back to A300. Back-revving it to 8.3x is not an option since it's unsupported per HWU. Also, if doing this renders the A300's unsupported then that kind of defeats the purpose as well, so it would have to be a supported operation.
Our sales team has said this is unsupported, but are waiting confirmation.
I've reached out to Eddie Hu (I believe your account rep?) with details.
I think if you're after it for a supported system you plan to run long term, it probably isn't something supportable. The cases I've seen (and there's only been a handful) have needed to convert to enable a migration or something similar, and are then set back to AFF.
The AFF personality enables additional efficiencies both on disk and in terms of processing, as well as our parts management systems may eventually complain about shipping spinning disks to an AFF contract. There's the additional issue of AFF sales being something we report to the market (but maybe by capacity only, not number of controllers..) and to market analytics companies, so changing the number of AFF systems sold might create upstream headaches.
I just wanted to give you the reverse issue I have 🙂
A customer of mine was a part of an evergreen program (free upgrade of controllers efter 3 years)
So I have swapped out their AFF8060 for an AFF A300 (shipped my NetApp).
I used the document 215-12065_A0_UR005 (Using Aggregate Relocation to Upgrade Controller Hardware Running ONTAP 9.0 to 9.4).
And everything works as expected, and we migrated the shelfs to the new controller without any issues.
But... the cluster now reports the two nodes as FAS8200 and not A300. Which is not right... also it complains when you enable inline-compression on a colume (performance issue) which a normal FAS8200 will typically do... so somehing is a miss somewhere 🙂
This is not that critical, and the customer is carrying on despite this, but I have opened a case on this, as it is very strange.
The box the system came it, stated A300, the fron facia states A300, and the licenses which followed the system, also states A300...
I didn't check the BIOS setting, I just did the set-defaults, set the date and checked the parter-systemid, that's it... just as described in the document mentioned above...
This was my first controller upgrade of a running system... in the old days wirth 7mode you had to stop everything as you replaced the controllers... this way is much better 🙂
HI again, sorry for the delay in my reply... you know when a problem has been solved, it's on to the next one 🙂
The issus was, as I suspected the system delivered by NetApp as a replacement, didn't have the "bootarg.init.flash_optimized" environment variable set.
We were able to verify this without booting any of the controllers, by the maybe less known approach...
Basically you unlock the diag user, login to the systemshell and get the environment values, like this:
1. security login password diag
2. security login unlock diag
3. set diag;systemshell
4. (login with the diag user/pass from above)
5. issue the "kenv" command to get the same output as if you entered "printenv" from the "LOADER>" BIOS...
7. security login lock diag
I am not aware if you are able to set the environment variables from the systemshell, but we scheduled a service window for a few failovers and givebacks of the cluster, were we set the value to "true", and after that the system now reports AFF A300 🙂
I'm not sure what would happen if you were to set this value to "false" by mistake... is there a way to get it back to "true", or is it a truely WORM value? I guess we will never know? 😉
Just for information, we did open a case with NetApp support, just to verify that it was OK to change the values with data on the system, and apparently this is common for NetApp to send out new system like this, it could also happen if you were to do a controller swap is it was faulty... which i have done a few times, come yo think of it... guess I have been lucky to have controllers were this was set 🙂