2015-01-16 08:14 AM
I currently have a volume which I want to move onto my D4246 as it utilises SATA, at the moment it sits on expensive SAS storage which I want to utilise for something else.
The data on that volume is just one virtual machine hosted in our VMware environment so my plan is to storage vmotion it to the new SATA volume but the VM is quite larger (approx 3tb)
my question is though
If I create a new volume, and move the VM, what happens with SnapMirror? I assume this will not work as its tied to the original volume.
Could I break the relationship and then just let it know about the new source location.
I really want to avoid it doing a baseline transfer as this will take weeks on our WAN connection.
Any advice on this would be most appreciated.
Solved! SEE THE SOLUTION
2015-01-19 01:15 AM
So the source snapmirror us a 3TB LUN sitting on a FAS8020 and this is snapmirrored across a WAN link to a FAS2240-4 which is the destination.
The VM in question basically just sits in a 4TB fibre LUN thin provisioned flex volume which is presented on the FAS8020.
I was wondering if the following plan would work for me to allow to reuse the existing destination volume so it doesnt need to perform a new baseline transfer:
Hopefully if this works, I would expect it to a delta snapmirror based on the last time it did a successful snapmirror.
Would this work.
If there is any more info I need to provide please let me know, I hope I have provided enough.
2015-01-19 10:24 AM
you basically described the task i have recently completed.
I moved out of production environment to the qa/dev environment volume containing a few virtual machines.
- I snapmirrored volume, once completed
- broke snapmirror
- disconnect old volume (storage from VM ware)
- added new storage to VMware and imported VMs.
it worked seamlessly, have not encounted any problem. It was on different filer model, and different type of drives if that important for you, however it should not really matter.
2015-01-19 05:28 PM
The problem here is the use of storage vMotion. As soon as you utilize storage vMotion, the NetApp sees this as changed blocks (new data), so you will need to re-baseline your snapmirror.
If you want to prevent having to re-baseline, you need to make sure all of the snapshots make it to the new volume. A storage vMotion will not bring the snapshots along to the new volume.
Here is the correct procedure:
SourceVol1 - Current Source Volume on SAS
SourceVol2 - New Source Volume on SATA
DestinationVol1 - Destination Volume
snapmirror update exiting relationship between SourceVol1 and DestinationVol1
snapmirror break relationship between SourceVol1 and DestinationVol1
snapmirror data from SourceVol1 to SourceVol2
snapmirror update from SourceVol1 to SourceVol2
Remove datastore from VMware that lives on SourceVol1
Add datastore to VMware that now lives on SourceVol2
snapmirror resync between SourceVol2 and DestinationVol1 (no baseline needed)
Once you know everything worked as expected, delete SourceVol1
Here is the more official version (should have looked this up before typing all of the above