Creating RAID devices and rebooting twice (once to start using the RAID device, and again to stop using it afterwards) seems excessive here. I do this sort of thing with a script very much like lvmsync:
except that it works on any block device, not just LVM.
If implementing your own script instead of lvmsync all you need to do is dd off the block device while the VM is running, shut the VM down and then dd only the changed chunks. This can be achieved by reading both the source device and the target device, hashing the chunks and comparing hashes to tell if you need to write the chunk again.
You don't care that the source device is changing under you as you're reading it, because all you're trying to do is get an initial rough copy of the data. The final sync with the VM shut off gets all the changes and makes it consistent.
I typically see single digit changed megabytes per gigabyte of active filesystem, so the final sync goes very quickly.
This also has the advantage that it works in any scenario you have a block device, so would work for OP's host connected to two SANs, but also when you have two hosts each with local storage. You can just do it over SSH.
Another thing you can do is to play with xnbd to put a proxy block device on the destination:
That may be helpful if the storage is local to each host and is truly massive, as a VM on the destination host can use the NBD block device and be unaware that it is proxying requests back to the original host for data it does not have.
Eventually the data will all be synced across to the target host and then the VM can be rebooted to switch back to the non-NBD local block device.
http://theshed.hezmatt.org/lvmsync/
except that it works on any block device, not just LVM.
If implementing your own script instead of lvmsync all you need to do is dd off the block device while the VM is running, shut the VM down and then dd only the changed chunks. This can be achieved by reading both the source device and the target device, hashing the chunks and comparing hashes to tell if you need to write the chunk again.
You don't care that the source device is changing under you as you're reading it, because all you're trying to do is get an initial rough copy of the data. The final sync with the VM shut off gets all the changes and makes it consistent.
I typically see single digit changed megabytes per gigabyte of active filesystem, so the final sync goes very quickly.
This also has the advantage that it works in any scenario you have a block device, so would work for OP's host connected to two SANs, but also when you have two hosts each with local storage. You can just do it over SSH.
Another thing you can do is to play with xnbd to put a proxy block device on the destination:
https://bitbucket.org/hirofuchi/xnbd/wiki/Home#!scenario-2-s...
That may be helpful if the storage is local to each host and is truly massive, as a VM on the destination host can use the NBD block device and be unaware that it is proxying requests back to the original host for data it does not have.
Eventually the data will all be synced across to the target host and then the VM can be rebooted to switch back to the non-NBD local block device.