« Robert Cockerill from Thames River Capital: A man with broad responsibilities and 3PAR storage | Main | From viral spam to virulent sham »

July 21, 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.


..."SAN is attempting to be more NAS-like"...

Really, you are as bad as any other "media" (see Fox News, CNN, et. al...) person for taking everything out of context and twisting it to suit your purpose. It's just irritating. Why is it that none of the storage bloggers can make a single post about their own products? Instead all you want to do is shout as loud as you can about how awful everyone else's equipment is and hope that all that negativity will cause people to purchase yours.

If you read his comment it makes sense...what VMware is attempting to do, according to Vaughn at least, with the VAAI APIs is enable functionality on "SAN", i.e. VMFS, that has been available on NAS, i.e. NFS, datastores for some time.

Yes, there are other features, that you pointed out with as much snark as can be conveyed across the internet. No, Vaughn's statement probably doesn't match 100% feature-to-feature, however, NetApp's interpretation of the VAAI's functionality appears to be different than yours. So what?

I suppose you hate all versions of the Bible except King James Version, since the others have different words and might convey different meaning to different people.

Why don't you tell us how awesome 3PAR's VAAI integration is going to be instead of how crappy NetApp's is? EMC, who "owns" VMware, doesn't have their VAAI integration planned until Q42010*...why aren't you ripping on them?

Maybe it's jealousy? Whatever it is, it's irritating that you seem to have a vendetta against NetApp, and can't seem to say anything that adds value about your own company's offering.

*link: http://virtualgeek.typepad.com/virtual_geek/2010/07/vsphere-41---what-do-the-vstorage-apis-for-array-integration-mean-to-you.html

marc farley

Hi bob_dole@mailinator.com,

Most of the time when somebody comments like this and hides behind a ridiculous alias (Bob Dole) I don't publish their comment. Perhaps you have an opinion about transparency in social media that you would like to offer.

Maybe you didn't read my previous posts on VAAI?



What VMware with VAAI is doing is addressing the needs of customers. You can spin this however you like, Bob Dole, but I'm pretty sure VMware doesn't care much about NAS vs SAN.

As for Snark, you don't know what the word means apparently. Re-read what I wrote about the various VAAI features. Its a pretty even-handed discussion, unless you are predisposed to seething.

Interesting point about the King James. Definitely not my favorite because I don't think it's language is easily absorbed by the world we live in today. But there are many possible cosmological and philosophical interpretations of the world we live in.

On a microcosm, there are many possible interpretations of the tom-foolery in our industry where we are all working to maintain a piece of economic well-being. Apparently, Bob Dole, you don't think the internet should be used to compare and contract those interpretations. Get real.

Competing vendors have the most to lose and gain from Internet wild west marketing and therefore they are going to continue to police each other's spin and misleading statements as best they can. It is the system of checks and balances in internet marketing.

FWIW, that's why transparency is so important, Bob Dole, because its one of the things that the community can and does insist on. If you are going to disagree with something in public, who you are and who you work for should be out in the clear so readers can interpret it.

And after all this indignation over my supposed mistreatment of Netapp, you wonder why I wasn't picking on EMC. Now THAT is funny - not only for it's intent, but because you really must NOT be familiar with my writing.

If you want to respond, don't respond as Bob Dole again, it won't be published.


NetApp may be late to the game on the latest API stuff but even as a loyal 3PAR user I have to admit that 3PAR was pretty late to the game with VMware integration in general ! Hoping the next revision of the 3PAR VMware plugin gets even better integration(at the very least offer the ability to cache read-only credentials permanently in the plugin for non-recovery manager functions), as is it's ok but has a ways to go to catch up to NetApp(from the screen shots I've seen, haven't used it, though got a new V3160 in house fronting our T400 for some NAS duties, no plans to use VMware with it though). Course my last day at my current employer is next Wednesday..woohoo!

Elizabeth Dole

Bob please come back to bed. I told you not to try an manipulate the NTAP stock. What the hell is VAAI, just take some more Viagra and lets snuggle.

Vaughn Stewart


It seems like there's a breakdown in communication. Maybe the fault is mine. Let's level set...

The vStorage capabilities in vSphere 4.1 are:

1. Storage I/O Control (SIOC)
2. Enhanced Performance Reporting
3. vStorage APIs (of which there are 3)

SIOC is supported today

Enhanced Performance Reporting is supported today

The vStorage APIs will be supported in Data ONTAP 8.0.1, which is scheduled to release in October. This timeframe is approximately 90 days from the release of vSphere 4.1and is around the same timeframe EMC plans to add VAAI support to the Symmetrix.

Stating we didn't show up to the party seems a bit harsh from where I sit, but I understand.

Regarding my comments around NFS and the initial release of the 3 vStorage APIs (VAAI) only supporting VMFS...

My statements are extremely accurate. Please consider that VMware on NetApp NFS deployments have had the following capabilities for four years.

1. Immediate zero-cost VM clones without transferring VM data over the storage network from within vCenter. Some of this enablement is in the Full Copy API for VMFS.

2. No need for Eager-Zeroed Thick VMDKs. Eager-Zeroed Thick VMDKs are NOT the norm, yet they ARE required with VMFS when running VMware's Fault Tolerance. Eager-Zeroed Thick VMDKs are NOT required when running FT on NetApp NFS. Thus the Block Zeroing API is addressing an edge use case and one not present with NFS.

3. Deploy massive (hundreds of VMs per) datastores free of SCSI locking issues. VMFS is getting some relief with this issue with the Hardware Assisted Locking API.

I truly believe that this post is slanted a bit due to a misunderstanding of the difference between SAN (FC, FCoE, iSCSI) and NAS (NFS) with VMware. This doesn't make the post bad, just slightly incorrect.

Is that a fair statement?

For those seeking more info please check out my blog on VAAI:


marc farley

Vaughn, Are you trying to clarify things or obfuscate them? I can't tell what your intent is with a comment like this.

For instance, you wrote in your comment that Netapp had these VAAI capabilities for four years and then you say there is no need for EagerZeroThick in your systems, which is the basis for block zeroing. That doesn't make any sense.

On that topic, the reason behind EZT is to get faster performance by eliminating the pre-writing of zeroes before writing data. It's a performance thing. Yes, it is required for VMware's FT because FT writes need to be as low latency as possible.

Your argument about hardware assisted locking makes the same basic point that mine did - that NFS didn't need it. Why would you want to argue with that? I guess you misunderstood what I wrote. Read it again - you'll see what I mean.

Finally, there is SIOC, you were asked about this on your blog last week and you wrote: "As for SIOC... it's all on the roadmap..." To me roadmap is something that means future and I apologize if somehow I misunderstood what you wrote. (If you want to recall your comment, just search for the quoted string in Google, the reference comes right up.)

Vaughn Stewart


I truly believe that where we disagree is due to differences in level of understand the nuances of VMware deployments with SAN and NAS. I don't mean to offend by making such a suggestion, so allow me to explain in an effort to see if we can't get on the same page.

Let's consider the Block Zeroing API.
- Are they a common a VMDK format? - No
- Do they outperform a thin or thick VMDks? - Yes, but only when a VM is writing net-new data to an area not previously formatted. This may be common with a VM file server but is not common with a VM serving Oracle or SQL databases (as the db creation process allocates blocks, which in turn get formatted). VMware & NetApp have jointly completed performance benchmarks that validate my statements. See NetApp technical report 3808 as an example.
- Conclusion: Block Zeroing API is a very nice enhancement; however, it has a small use case.

Let's consider the Hardware Assisted Locking API.
- SCSI locking is not an issue with NFS, thus the affinity of usage in very large deployments.
- H.A.L. Addresses these issues with VMFS and thus SAN deployments will better scale.
-Conclusion: Hardware Assisted Locking is a significant improvement in storage scaling for VMFS deployments.

Let's consider the Full Copy API.
- Now this one gets really interesting... the apis helps offload the data traffic from the storage network and ESXi hosts when a VM is cloned or migrated (both are copy operations).
- NFS deployments already have this capability when cloning
- NFS datastores can be automatically resized and also don't suffer scaling issues. As a result we see significantly less VM migrations (which is a huge value with environments which replicate for SRM. Migrate a VM leads to the re-replication of a VM).
- Full Copy adds a feature which exists in NAS to SAN deployments with cloning offload.
- Full Copy appears to make VM migrations more desirable than with NAS; however, as stated NAS typically avoids the need to migrate as often.
- Conclusion the Full Copy API allows VMFS to have more NFS like features. the value for VMFS customers is significant.

Let's consider SIOC
- Great benefit fot VMs, enough said.

Let's consider Enhanced Performance Reporting
- This feature is huge as it provides NFS customers with per VM I/O stats which previously were only available with VMFS deployments.

As you can see, storage relevant to VMware is not equal between SAN & NAS. SAN provides shared access through a host coordinated clustered file system. NAS provides shared access through a storage controller coordinated network file system. Both are similar and yet very different in terms of capabilities and features.

In summary we are thrilled with the vStorage program. I would assume it brings more value to a SAN only storage vendor than one which is multi-protocol.

There's much more to share. Maybe we can sync up in person and discuss over beers?

marc farley

OK, let's have storagebeers sometime, but it probably won't help matters. Were vendor bloggers and don't ever forget that!

The comments to this entry are closed.

Search StorageRap


Latest tweets


  • Loading...


Infosmack Podcasts

Virtumania Podcasts