ADPv1 and ADPv2 (Temporary) Coexistence?

[grave ocean]

Scenario: I have a client with a AFF HA pair with several shelves attached. Two of these are old DS2246 shelves that are near EOL and we're trying to remove them. The system was originally initialized with ADPv1 (RD) partitioning. Our goal is to manually migrate the node root aggregates (following the KB-documented process), finish migrating volumes away from the data aggregates, and eventually destroy the old aggregates and remove the old shelves.

One other goal here was to move away from ADPv1 and move to ADPv2 (RDD). I have a whole shelf that was manually partitioned at the node shell using the command:
disk partition -n 3 -i 3 -b 39132288 <diskID> [<-The number is disk quantity and platform specific; this is 24 disks for a 1TB A700 root vol]
The CLI spit out the following warning and allowed me to continue:
“The partition method root-data1-data2 is not supported on this system. Partitions created from this method can only be used after migrating root to this partition method.”

Obviously, migrating to a new root on these P3 slices is the goal. But nowhere in the documentation have I been able to find if there is technical reason ONTAP would prevent ADPv1 and ADPv2 coexisting for a short period of time on the same HA pair (in the transitionary period). The warning noted above seems to imply that root migration would be supported/possible. But does it also imply the two ADP styles cannot coexist? There would be one ADPv1 data aggregate that needs to be vacated following the root aggregate migration, so I am looking for a subject matter expert to help validate if this would work (or perhaps some technical reason why it couldn't) and whether it would put data availability at risk. Thanks in advance for any wisdom/pointers here.

[granite urchin]

that disk partition command looks suspicious. Are you sure the partitions were created correctly? Normally you have to specify at least two partition sizes for RDD partitioning.
In any case, from my experience ONTAP will usually run fine with any partition scheme, but it will not be supported. Which means that it has not been tested, and in cases where e.g. a disk fails, the system usually cannot handle automatically partitioning and assigning the disk. Also during disk firmware updates there might be issues with the two nodes not being able to decide who uses what part of the disk. Oh, and the process of migrating the root volume with node migrate-root is pretty brittle and can randomly break if you have any unsupported configs like this, in which case you are better off using the old "manual" migration procedure which has (again, from my experience) never once failed me 🙂

[grave ocean]

Thanks for the reply. Yes--the disk partition command just needs the one input for the root slice portion and then the remainer is split in two to form the data slices. I've used the command before, but never on a system that had a different partition style present. I'm not really worried all that much about disk/partition handling with failures. We can certainly hold its hand in the transitionary period until we get to the final state. But you can't think of any reason why it shouldn't work?

Yeah--the migrate-root automated command was suspect to me. Kind of how I still prefer the manual non-disruptive head swap process. The migrate-root still didn't have a way to specify partitions rather than whole disks, so the tried and true manual process was the way to go.

[granite urchin]

awesome. If you are familiar with the manual process I think it will be fine. I can't think of a reason why mixing R-D and R-D2 partitioning would cause issues other than the ones I mentioned. I'd still wait for a bit in case someone else wants to chime in here with their (positive or negative) experience, just to get a second opinion 😉