Method 4

Depending on the size (and contents) of the data store, if you connect your new SAN to you VMWare infrastructure, you can storage vMotion in addition to moving the guest itself.

If you have large databases in the Availability Group, I'd recommend a modification of Tony Hinkle's answer under Method 1.

1. Remove secondary replica (call it "B") from the AG
2. Stop the "B" guest
3. Storage vMotion "B"'s data store to the new SAN
4. Bring "B" guest online
5. Rejoin "B" to Availability Group
6. Manually failover the Availability Group to "B"
7. Remove the secondary (former primary, call it "A") from Availability Group
8. Stop the "A" guest
9. Storage vMotion "A"'s data store to the new SAN
10. Bring "A" guest online.
11. Rejoin "A" to Availability Group
12. Test with a failover to "A"

Note that depending on how long this takes, you may have to apply any log backups (WITH NORECOVERY, remember) taken during the storage vMotion process on the primary (either time) as part of steps 5 and 11.

Method 4

Depending on the size (and contents) of the data store, if you connect your new SAN to your VMWare infrastructure, you can storage vMotion in addition to moving the guest itself.

If you have large databases in the Availability Group, I'd recommend a modification of Tony Hinkle's answer under Method 1.

1. Remove secondary replica (call it "B") from the AG
2. Stop the "B" guest
3. Storage vMotion "B"'s data store to the new SAN
4. Bring "B" guest online
5. Rejoin "B" to Availability Group
6. Manually failover the Availability Group to "B"
7. Remove the secondary (former primary, call it "A") from Availability Group
8. Stop the "A" guest
9. Storage vMotion "A"'s data store to the new SAN
10. Bring "A" guest online.
11. Rejoin "A" to Availability Group
12. Test with a failover to "A"

Note that depending on how long this takes, you may have to apply any log backups (WITH NORECOVERY, remember) taken during the storage vMotion process on the primary (either time) as part of steps 5 and 11.