Moving root vol from 32-bit to 64-bit

[dejanliuit]

I just upgraded our controllers to Ontap 8.1p1. As we have one 64-bit aggregate I thought it would be excellent moment to move over the root vol to 64-bit and continue converting all aggregates to 64-bit.

The problem is that when I followed the ontap instructions "Changing the root volume" in the Ontap 8.1 System administrators guide, everything was ok until I was about to change which aggregate is the root.

When I tried to assign the 64-bit aggregate as root, the system complained I had to do that in maintenance mode.

This is definitely NOT documented or mentioned, so I stopped there.

I did neither have service-time left, nor nerves to try anything out.

Can anyone tell me what I missed here?

[aborzenkov]

You do not assign root aggregate, you assign root volume. So system is correct ☺

Take new 64 bit volume and set root option: “vol options xxx root”

[dejanliuit]

Sure, if the documentation would claim that. The problem is that it clearly states in step 4 (before rebooting in step 5) that I have to set the aggregate as root when moving to the root volume to another aggregate.

"If you moved the root volume outside the current root aggregate, enter the following command to change the value of the aggregate

root option so that the aggregate containing the root volume becomes the root aggregate:

aggr options aggr_name root

aggr_name is the name of the new root aggregate.

For more information about the aggregate root option, see the na_aggr(1) man page."

[aborzenkov]

I never had to use “aggr options root” in the past 10 years. Of course, it is possible that something has changed in 8.1, although I would rather suspect documentation error. You can open support call with NetApp and ask them to clarify.

If you issue “aggr status” after “vol options xxx root”, which aggregate is marked as “diskroot” - containing old or new root volume?

[dejanliuit]

The old one was still marked as root, and the new one as diskroot.

Didn't dare to try and see what happend.

This is how it looked like after the new volume on 64-bit aggr was marked as root.

netapp-i> aggr status

           Aggr State           Status            Options

             VM online          raid_dp, aggr     root, raidsize=14

                                mirrored

                                32-bit

          VM_64 online          raid_dp, aggr     diskroot, raidsize=14

                                mirrored

                                64-bit

netapp-i> aggr options VM_64 root

aggr options: option 'root' can be modified only in maintenance mode

[scottgelb]

The documentation is correct but could be more clear... from maintenance mode you can't set a volume as root with "vol options volname root" but you can set an aggregate as root (maintenance mode only) then it creates a volume called AUTOROOT in that aggregate and boots with that.

[scottgelb]

from ONTAP you can set a volume as root (not in maintenance mode) as you did and diskroot means that volume will become root on reboot or after takeover/giveback.  Looks good.

[aborzenkov · Accepted solution]

That’s how it should be. “diskroot” means it will become root on next reboot. Keep in mind that the only way to clear “diskroot” is to set root for some other volume and the longer you delay reboot the more different current and future root become. Also any changes done on current root will not be present on copy, so if you will be forced to reboot you get inconsistent configuration. So do not delay rebooting or reset root volume back to original if you do not plan to reboot in next hours.

Also verify that new root volume has “diskroot” flag as well.

“aggr options root” is used in emergency when original root aggregate is for whatever reasons physically unavailable.

You may want to submit documentation feedback regarding this as well. This is highly confusing, I agree, and the part about “aggr options root” had not been present in any previous Data ONTAP version.

[dejanliuit]

I'm going to contact support regarding this. I'm fairly sure that I have moved the root volume something like 3 years ago (with vol root option only), but I had to follow instructions as this is a new version of Ontap, therefore as the docs seems to be incorrect (for normal usage) it should be adjusted so that others don't trip on the same problem as me.

Especially as a lot of systems are going for 64-bit only setup further on and a lot of them will have to move the root volume.

[thomas_glodde]

Root Volume migration:

ndmpd on

ndmpcopy -f /vol/old_root /vol/new_root

vol options new_root root (ignore any warnings about missing files etc, if you did ndmpcopy -f all is fine)

reboot (or cf takeover on the other node)

Done this like a gazillion times, no harm done. As mentioned above, you need to reboot or takeover the node to finish the move, so as mentiond by a few others here, dont wait a week for the next maintenance window with the reboot.

[foogeelah]

For 8.1 7-mode, I have been doing the following:

priv set diag

aggr 64bit-upgrade start aggr0

<wait 30 seconds to complete>

priv set admin

aggr status

I kind of do this as a matter of course for all new installs after upgrading to 8.1.  Although I've not had any requirement to upgrade existing systems yet, so it only applies to root vol (as that's the only volume on the system after initial setup and upgrade).

[scottgelb]

The risk is no support for an upgrade not adding disks and growing over 16TB. But instill like it :). But can't run at a customer without official support. I think there was a qa issue found and that is why it is diag only.

Sent from my iPhone 4S

[dejanliuit]

It should be like that, unfortunately the documentation talks about the "aggr option root" step.

I have contacted my support (IBM) and I'm awaiting their answer.

I will follow their directions and thus avoid problems with the support if I need help, should anything go wrong.

Also, I want a running system and avoid any possible unnessecary disruption.

IBM have never showed any flexibility in their support so I have to be extra careful in following the documented instructions.