LUN MOVE Sanity Check

[nicholsongc]

I have two (2) LUNs in a single volume.  This prevents me from doing a Guest File Restore via SnapCenter.

If I were to move one of the LUNs to a new volume would this be at all disruptive if the LUN is currently presented to clustered ESXi hosts (6.5 U2) and contains several VMDKs which are attached as Basic Disks to Windows 2012 Servers?

Documentation doesn't specifically call out any risk of disruption and I've done similar operations via volume move without disruption.  But rather than assume anything I was hoping the community could provide some real-world practical advice from the LUN perspective.

Thank you in advance for said advice.

[AlexDawson · Accepted solution]

Hi there!

LUN move is a non-disruptive command - here is someone using it in a real world type scenario and it cutting over without issue - http://www.datacenterdude.com/netapp/best-kept-secret-in-netapp-data-ontap-8-3/

Hope this helps!

[AbhinavV]

The provided link does not work. 

[AlexDawson]

It was originally published 9 years ago and my link was from 5 years ago, so I trust in your forgiveness 🙂 An archived copy is available at https://web.archive.org/web/20190315114049/https://datacenterdude.com/netapp/best-kept-secret-in-netapp-data-ontap-8-3/ without images so unfortunately it does not answer the whole question, but the end answer is - it is non disruptive, and you should test it first just to be sure your infrastructure is configured correctly.

[AbhinavV]

@AlexDawson thanks for the response. I do understand that the post was old enough for the creator to abandon it 😉 but I was just looking for some evidence that its non-disruptive. I did have an RDM Datastore configuration for one of our large Oracle RAC clusters, I have moved the underlying LUNS to load balance the NetApp Cluster as the IO requirement from the individual RAC cluster was upwards of 100K. I followed Move a LUN Doc for this. however, I did take a complete App/DB Downtime and brought the VMs down before migrating the LUNS to avoid any issues that I may face with Oracle, distributed 8 Luns across 4 different nodes and created individual volumes per LUN. No issues reported post the LUN move activity everything came up gracefully. 😊