Last week I posted a blog article which described the interoperability status between VMware's Site Recovery Manager 5.0 and Storage DRS. In this article, I described how Storage DRS could bring about additional administrative steps to keep the recovery plans up to date, and open a small window where Virtual Machines may not be protected. For that reason, VMware is not supporting these features/products being used together. We did not want to risk a situation where a failover to the DR site did not complete successfully.
In the same article I also mentioned that VMware would not be supporting Storage vMotion/Storage DRS with vSphere Replication. vSphere Replication (VR) is a new feature of SRM 5.0, and allows Virtual Machines be protected across different sites without the need for storage array replication. The support statement is still true – VMware will not be supporting Storage vMotion/Storage DRS with VR. However, the reason I gave for the lack of support was not accurate. Thanks to some feedback internally, I can give the correct reason here.
First, contrary to what I said in my initial blog post, since VR operates at the level of virtual disks, VR does not have a dependency on the datastore that a VM's disk is stored on. But there are other considerations when using these technologies together. Let's now look at the primary and replica VR sites, and how Storage vMotion/Storage DRS can impact each.
At the primary site, because of the way VR works, there are two separate cases of Storage VMotion/Storage DRS support to consider:
Moving some subset of the VM's disks
Moving the VM's home directory.
In the case where some subset of the VM's disks are migrated with Storage VMotion/SDRS, things should work. From VR's point of view, the Storage VMotion operation looks like a "fast suspend/resume" and VR handles that fine.
The problem at the primary site comes from the second case: when doing a Storage VMotion of a VM's home directory. In this case, the VR persistent state files (".psf") are not migrated, but are deleted. From the point-of-view of VR, this looks like a power-off, followed by a power-on of the VM without the ".psf" files. This triggers a VR "full sync" (the disk contents are read and checksummed on each side). Since the primary and replica are basically in sync, very little data should actually be transferred. While this is relatively expensive (the entire disk is read and checksummed, at both sites), there is no correctness problem. Note that this expense could be high enough (depending on the size of the disks) that VR may miss an RPO (Recovery Point Objective) window or two. This means that VMs could be more out of date when recovered than originally planned.
At the replica site, the interaction is less complicated. Storage DRS cannot see the replica disks. These are just "disks"; there is no "VM". The VR disks are not actually attached until test-bubble or fail-over time. Therefore Storage DRS cannot move these disks since it can only see VMs. This means there are no low-level interop problems, but there is a high-level one as we would all like Storage DRS to see the replica disks and be able to move them out of the way if a datastore is filling up at the replica site.
Overall the interoperability isn't great in this initial release. At the primary site there are no serious correctness problems, just the performance impact of a VR "full sync" that can be triggered by Storage VMotion. At the replica site there are no immediate problems, but the higher-level lack of visibility is an issue.
Once again, as I stated in the previous blog, VMware are tracking full interoperability of Storage vMotion & Storage DRS with Site Recovery Manager & vSphere Replicator as a high priority item.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: VMwareStorage
