Move volume on other aggregate when your aggrigate is full

[#1]

Hello.

I have 2 aggregates FSAS and SAS drives, the aggregate with FSAS has been expanded, aggregatewith SAS disks is full 99% (3 volumes of 9TB full provision), can I move volumes to FSAS without downtime. The luns is served to more than 100 hosts.
And another question where the delta will be written when moving the volume.

System FAS8040 Cluster data ontap 8.3.2 uses protocol FC

[#2]

Hi, 

Thank you for reaching NetApp communities. Please refer to the Volume Move express guide to understand and complete proceudre to move volumes with LUNS.

VOLUME MOVE EXPRESS GUIDE

Thanks,

Nayab

[#3]

Thank you, i find next:
A volume move operation might take more time than expected because moves are designed to
occur nondisruptively in the background in a manner that preserves client access and overall
system performance

Requirements are to the destination aggregate but not to the source, does this mean that the delta of the changed data will be written in the destination aggregate?

[#4]

Hello, to confirm, your clients will not start using the destination volume until the move operation has completed. All data written during the move process will be to the source volume, it will then be subsequently transferred to the destination volume during the volume move update phases. Only after the cutover will the clients start to write to the destination volume.

Hopefully this clarifies for you.

Thanks,

Grant.

[#5 · Accepted solution]

To add more points, What exactly happens during cutover phase.

1.All LUNs in the source volume are in a suspended I/O (quiesced) state. The quiesced state empties the LUNs of pending I/Os and prevents new I/Os from being scheduled. Any new I/O      post-LUN quiesce is simply dropped and no response is sent to the initiator.

2. The source volume is quiesced. The volume quiesce fails new commands on the volume with busy status and drains pending commands on the volume. As part of the quiesce operation, WAFL captures the final delta lag in a Snapshot copy, which is named according to the convention ndvm_final_<timestamp>.

3. The destination volume is then synchronized completely with the source volume with the delta from ndvm_final_<timestamp>. This is the last SnapMirror update between the two volumes before servicing the I/O from the destination volume.

4. The identities of the source volume and the destination volume are swapped.

5. The migrated volume is brought online with the identity of the original source volume and the LUNs are unquiesced, at which point they are in a mapped state and ready to accept I/O.

6. The source volume is deleted, unless the user specified retaining it. The volume can be retained using the vol move -k command. If the source volume it retained, the vol move operation will rename it as <source volume name>_old_<timestamp>.

7. The ndvm_final_<timestamp> Snapshot copy is retained in the moved volume at the destination. However, once cutover is complete, you can delete it.

If the volume move is not completed within the specified cutover period (default 60 seconds), then the cutover phase is timed out, logging the appropriate error messages, and the volume move reverts to the data copy phase.

If the cutover phase is successful, it results in the following:

• The contents of the destination volume are identical to the source volume.
• The destination volume takes the identity of the source volume.
• After the volume is moved, the LUN at the destination starts processing I/O operations.

Depending on the number of cutover attempts, the volume move tries to enter the cutover phase again. If cutover is not completed within the specified number of cutover attempts, then the volume move is paused and an appropriate error message is recorded in the log file. You can then manually resume the volume move.

Note: The host application might encounter I/O disruptions if storage system reboot, nondisruptive upgrade (NDU), shutdown, takeover, or giveback occurs during the volume move.

Thanks,

Nayab

[#6]

I realise it maybe too late to help, however rather than performing a volume move if your source aggregate is almost full and are worried about free space for any new writes, you can use lun move instead.

By default the -promote-late option is set to false, meaning that as soon as the destination LUN has been created it is advertised to the clients for new writes. However you need to be aware that snapshots cannot be created on the LUN until the lun move process has completed.

Thanks,

Grant.