What is the effect of a volume rename in vsphere?

[TMADOCTHOMAS]

I need to rename a volume that is used as an NFS datastore.  I'm aware that on the NetApp side I need to have auto-update turned on to update the exports file (it is on), but I don't know what effect this will have on the datastore.  Will there be a disruption?  Will the Vmware admins need to unmount and remount the volume?  Also, they will then need to rename the identification of the datastore to match the new volume name.  Will this cause an issue?

To provide the full context, we are replacing a damaged 2220 with a new one.  I am renaming the source and destination volumes on our SnapMirror relationships so we can preserve the relationships in case we need to revert back to them.  On the new 2220 we will use the same volume names we had originally.  So, the Vmware admins will be connecting to a datastore using the original name once the new 2220 is up and running.

Any help on this is greatly appreciated!

[billshaffer · Accepted solution]

Yes, renaming the volume will require a disruption in VMWare.  They'll need to take the datastore offline (doing a storage vmotion if they can't take the downtime), then add the "new" datastore with the new volume name.  If you do it without the storage vmotions, there's a process where they can scan the datastore and detect existing vmdks, then import them, so no data will be lost, but you should talk to the VMWare guys about that.

I'm not clear what you're doing.  You have controller A with data mirrored to controller B, and you need to replace A with new hardware (A')?  Just a head swap?  How are you going to get the data to A'?

Bill

[TMADOCTHOMAS]

Thanks for the help Bill.  In this situation, it will be done after hours so we can have a few minutes of downtime without a problem.  So apparently they would need to scan the datastore and do the import you described.  Thanks again!

As for what we are doing, we are replacing an entire 2220 with another 2220, not just a head swap.  We're going to have the new 2220 in the same location as the snapmirror destination volume temporarily, and copy the data from the most recent backup to the new 2220 over a fast line.  Then we'll drive the new 2220 to the remote site.

[billshaffer]

Got it.  So instead of renaming the volumes, how about doing a cascading mirror from the current destination (B) to the new primary (A'), break the mirror between A and B, shut down A, and replace it with A'?  You've still got the data on B (and A for that matter) in case you need to fall back, and you only take the one outage.  That makes it a simple downtime for VMWare, assuming you reuse the same IP for A'.

Bill

[TMADOCTHOMAS]

Thanks Bill!  That would work great if it weren't for the fact that there are qtrees involved.  We are using volume-to-qtree replication, so we would have to replicate the backup qtrees to  volumes on the new filer which I don't believe can be done.

[billshaffer]

Ah well....