ONTAP 9 Feature: Volume rehosting

Clustered Data ONTAP (now known as NetApp ONTAP) is a clustered file system that leverages virtualized storage containers known as Storage Virtual Machines (SVMs) that act as “blades” to create a secure, multi-tenant environment with a unified namespace.

These SVMs own objects such as network interfaces and Flexible Volumes (FlexVols) and act as their own segmented storage systems on shared hardware. In previous releases, the volumes were dedicated to the SVMs and could not be easily moved to another SVM in the cluster. You had to SnapMirror the volume over to the new SVM or copy the data. This process was time consuming and inefficient, so customers, for years, have asked for the ability to easily migrate volumes between SVMs.

In the 8.3.2 release, this functionality was added in limited fashion, for use with the new Copy-Free Transition feature. The volumes could only be migrated if they were marked as “transitioned” volumes from a 7-Mode system.

With ONTAP 9, we now have full reign to move volumes between SVMs without needing to copy anything! We cover ONTAP 9 in our podcast this month, so check it out.

How it works

Every SVM has a unique identifier known as a UUID. If you want to see it, you can run the following command from advanced priv:

ontap9-tme-8040::*> vserver show -vserver parisi,SVM1 -fields uuid
vserver uuid
------- ------------------------------------
SVM1 05e7ab78-2d84-11e6-a796-00a098696ec7
parisi 103879e8-2d84-11e6-a796-00a098696ec7
2 entries were displayed.

When a volume is “owned” by a SVM, that volume gets associated with the UUID of the SVM. It also gets its own file handle, based on the SVM root’s namespace.

In previous releases of cDOT, you could actually move volumes manually if you had a secret decoder ring of commands and enough gall to try it. What volume rehost does is automate the commands you’d need to make the necessary underlying changes to the cluster database tables to ensure nothing blows up.

Prove it!

So, now that I’ve told you about this cool new command, allow me to show you the details. This is the man page entry on an ONTAP 9 system in my lab. Keep in mind that this is a dev build, so things may change slightly when the release goes public.

ontap9-tme-8040::*> man volume rehost
volume rehost Data ONTAP 9.0 volume rehost

NAME
 volume rehost -- Rehost a volume from one Vserver into another Vserver

AVAILABILITY
 This command is available to cluster administrators at the admin privilege
 level.

DESCRIPTION
 The volume rehost command rehosts a volume from source Vserver onto desti-
 nation Vserver. The volume name must be unique among the other volumes on
 the destination Vserver.


PARAMETERS
 -vserver <vserver name> - Source Vserver name
 This specifies the Vserver on which the volume is located.

-volume <volume name> - Target volume name
 This specifies the volume that is to be rehosted.

-destination-vserver <vserver name> - Destination Vserver name
 This specifies the destination Vserver where the volume must be
 located post rehost operation.

{ [-force-unmap-luns {true|false}] - Unmap LUNs in volume
 This specifies whether the rehost operation should unmap LUNs
 present on volume. The default setting is false (the rehost opera-
 tion shall not unmap LUNs). When set to true, the command will unmap
 all mapped LUNs on the volume.

| [-auto-remap-luns {true|false}] } - Automatic Remap of LUNs
 This specifies whether the rehost operation should perform LUN map-
 ping operation at the destination Vserver for the LUNs mapped on the
 volume at the source Vserver. The default setting is false (the
 rehost operation shall not map LUNs at the destination Vserver).
 When set to true, at the destination Vserver the command will create
 initiators groups along with the initiators (if present) with same
 name as that of source Vserver. Then the LUNs on the volume are
 mapped to initiator groups at the destination Vserver as mapped in
 source Vserver.

The volume I intend to move is a volume called “move_me,” which is currently located in SVM1.

ontap9-tme-8040::*> volume show -vserver SVM1 -fields msid,dsid,uuid,vserver -volume move_me
vserver volume dsid msid uuid
------- ------- ---- ---------- ------------------------------------
SVM1 move_me 1027 2163225631 cc691049-2d84-11e6-a796-00a098696ec7

To move this volume, I simply use this command:

ontap9-tme-8040::*> volume rehost -vserver SVM1 -volume move_me -destination-vserver parisi

When I run this, I get this warning:

Warning: Rehosting a volume from one Vserver to another Vserver does not
 change the security information on that volume.
 If the security domains of the Vservers are not identical, unwanted
 access might be permitted, and desired access might be denied. An
 attempt to rehost a volume will disassociate the volume from all
 volume policies and policy rules. The volume must be reconfigured
 after a successful or unsuccessful rehost operation.

Basically, if I use a different AD domain or LDAP configuration in the SVM I am moving to, I could cause access issues.

The command takes a few seconds and I see this:

[Job 42] Job succeeded: Successful

Info: Volume is successfully rehosted on the target Vserver.
Set the desired volume configuration - such as the export policy and QoS policy - on the target Vserver.

Now, I check my volume. No longer on the old SVM:

ontap9-tme-8040::*> volume show -vserver SVM1 -fields msid,dsid,uuid,vserver -volume move_me
There are no entries matching your query.

Now is on the new SVM:

ontap9-tme-8040::*> volume show -vserver parisi -fields msid,dsid,uuid,vserver -volume move_me
vserver volume dsid msid uuid
------- ------- ---- ---------- ------------------------------------
parisi move_me 1028 2163225632 cc691049-2d84-11e6-a796-00a098696ec7

Different SVM. Different MSID/DSID. Same UUID for the volume, but belonging to a different UUID for the SVM. For NAS clients, you simply re-mount (as the file handle and IP address will change).

If you have LUNs, you can use the following flags:

{ [-force-unmap-luns {true|false}] - Unmap LUNs in volume
 This specifies whether the rehost operation should unmap LUNs
 present on volume. The default setting is false (the rehost opera-
 tion shall not unmap LUNs). When set to true, the command will unmap
 all mapped LUNs on the volume.

| [-auto-remap-luns {true|false}] } - Automatic Remap of LUNs
 This specifies whether the rehost operation should perform LUN map-
 ping operation at the destination Vserver for the LUNs mapped on the
 volume at the source Vserver. The default setting is false (the
 rehost operation shall not map LUNs at the destination Vserver).
 When set to true, at the destination Vserver the command will create
 initiators groups along with the initiators (if present) with same
 name as that of source Vserver. Then the LUNs on the volume are
 mapped to initiator groups at the destination Vserver as mapped in
 source Vserver.

What about FlexClones?

Sometimes, volumes will have FlexClones attached to them. FlexClones are RW copies of the volume that are backed by snapshots and don’t take any space until you start making changes to them – perfect for dev work!

So, what if I want to re-host a volume with FlexClones? Let’s find out!

ontap9-tme-8040::*> volume clone create -vserver parisi -flexclone clone -type RW -parent-vserver parisi -parent-volume move_me -junction-active true -foreground true
[Job 43] Job succeeded: Successful

Not supported… yet. 😉

ontap9-tme-8040::*> vol rehost -vserver parisi -volume move_me -destination-vserver SVM1 -force-unmap-luns false -allow-native-volumes false

Error: command failed: Cannot rehost volume "move_me" on Vserver "parisi"
 because the volume is a parent of a clone volume.


ontap9-tme-8040::*> vol rehost -vserver parisi -volume clone -destination-vserver SVM1 -force-unmap-luns false -allow-native-volumes false

Error: command failed: Cannot rehost volume "clone" on Vserver "parisi"
 because the volume is a clone volume.

So there you go. ONTAP 9 is bringing all sorts of goodies!

Other cool things

I ran across some other cool features I had not seen before in clustered Data ONTAP while writing this blog.

• First of all, when you create a new aggregate, the CLI will give you a preview before you commit the change:

ontap9-tme-8040::*> aggr create -aggregate aggr1_node1 -diskcount 14 -node ontap9-tme-8040-01

Info: The layout for aggregate "aggr1_node1" on node "ontap9-tme-8040-01" would
 be:

First Plex

RAID Group rg0, 14 disks (block checksum, raid_dp)
 Position Disk Type Size
 ---------- ------------------------- ---------- ---------------
 dparity 1.1.3 SSD -
 parity 1.1.4 SSD -
 data 1.1.5 SSD 744.9GB
 data 1.1.6 SSD 744.9GB
 data 1.1.7 SSD 744.9GB
 data 1.1.8 SSD 744.9GB
 data 1.1.9 SSD 744.9GB
 data 1.1.10 SSD 744.9GB
 data 1.1.11 SSD 744.9GB
 data 1.1.12 SSD 744.9GB
 data 1.1.13 SSD 744.9GB
 data 1.1.14 SSD 744.9GB
 data 1.1.15 SSD 744.9GB
 data 1.1.16 SSD 744.9GB

Aggregate capacity available for volume use would be 7.86TB.

Do you want to continue? {y|n}:

If you create a volume and don’t specify an export policy and the default export policy has no rules, ONTAP will warn you:

ontap9-tme-8040::*> vol create -vserver SVM1 -volume move_me -aggregate aggr1_node1 -size 10g -state online

Warning: The export-policy "default" has no rules in it. The volume will
 therefore be inaccessible.
Do you want to continue? {y|n}: y
[Job 41] Job succeeded: Successful

Oddities

Some things I ran across when setting this cluster up:

• If you have ports in the Cluster IPSpace that are down (I only connected 2 out of 4) and attempt to run “cluster create” or “cluster join,” the process will fail until you move those ports that are down to the Default IPSpace.
• If you’re trying to reinit a node and the node has ADP/disk partitions, the reinit may fail and suggest that you don’t have enough disks to create a root aggregate. To fix that, boot into maintenance mode and delete the partitions using “disk unpartition.”