At least we're getting it all on to block storage anyway like you say! The OS / Binary disks will be on VMDK files on a data store that is a pool shared with quite a few other VMs of various applications. The DB and Log volumes themselves (x6) are individual VMDK files (one for each DB) on individual data stores, which at the backend are all together on RAID 10. (except logs that have their own RAID 10). So they won't get affected by any other VMs.
The current plan is to validate the storage with JetStress, then:
1 > Switch off the passive dag member. Move it using a file move or VM converter (we don't have the old hosts in the new VM cluster so can't vmotion).
2 > Online it using the current in-guest iSCSI storage for the DB/Logs, make sure everything is OK on the new cluster. At this point the OS/binary disks will be on the new storage but DBs on old.
3 > If everything is OK, we will stop Exchange services, attach new storage
4 > Copy DB and Log volume contents to new disks.
5 > Offline old in-guest iSCSI
6 > Change drive letters of new disks to match old.
7 > Online Exchange and let everything replicate / catch up.
8 > Switch this node to be active for all databases.
After a few weeks, do the same for the other DAG node. The reason we were wanting to do it this way is to make sure everything works fine on the move with the other node still remaining unchanged in case of any issues / performance etc. There is a move-db option somewhere in Exchange but as I see it you have to remove the database copies, move the DB locations, create the DB copies and that seems like a much longer and riskier operation, plus means everything gets moved at once instead of gradually.
Does that all sound OK to you? We're also going from ESXi 4.1 to 5.1 so there would be some VM 'hardware' version upgrades too I guess.
Thanks again!