First things first, thanks Ken for coming here and explaining these things. This discussion is becoming really interesting.
There is no published API at all, to partners or customers, it's using a fundamental call within the kernel itself, so it's hard to expose that gracefully to the outside world. Trust me, we get beat up on APIs about this all the time, but securing the kernel is important. So we have a few calls we can make to it internally (via CLI) to configure the replication and that's about it. Lots of people want API access and lots of people want expanded CLI. We're always looking at how to do that though! Some other vendors in the world are doing... inappropriate things to gain access to things like the vSCSI filters without an API, and the problem there is if we change anything at all on those internal calls the whole house of cards might come down. People don't like it when their replication stops working for DR.
So we're looking at potentially writing a published API for this, but since that hasn't been in scope from the start it's something we're going to have to retrofit.
Even without putting out the names many of us know who are you referring about, and is more than one solution. One of them is really "near" to VMware and claims to use the vSCSI filter driver, so you are saying that even in that case it's a totally unsupported solution, from a VMware view point? You can also say "no comment" or nothing, I can understand.
Here is the problem: there is no other "officially supported" way of doing replication other than VM snapshots (or bypassing it completely with storage level replication), so some other solutions choose some "hacks" and by doing this they are totally unsupported; this is not a great thing not only because one simple change in the kernel would break their software, but also since we are talking about data protection so even official support is important.
But, but, there is an exception with your own Replication, that uses an "internal use only" kernel call. I've found this blog post by you (http://blogs.vmware.com/vsphere/2011/10 ... -work.html
) and also this KB (http://kb.vmware.com/selfservice/micros ... Id=2005776
) and in both places VMware says it's using vSCSI filter driver, the same of the other solutions.
So, can we sum it as "the filter driver itself is totally supported, but only if it's called by a VMware product" ?
Really, exposing those calls to partners would make all this stuff really easier, completely supported, and at the end customers will have better products.
Your role sounds to me like one that could eventually take care of this