What is VMware vStorage API?
Lately I had to brief a few people on vStorage API, and everyone used to ask me the same question: what is the difference between vStorage API and VMware Consolidate Backup (VCB)? It was really hard to explain until I found this analogy, and despite it is not technically flawless, it really explains the difference very well for non-developer type folks.
As most of you already know, except of (quite rarely used) NFS storage, VMware leverages proprietary VMFS clustered file system to store VM files. This file system is proprietary, and it is impossible to simply browse this file system from Windows or Linux computer.
VMware provides a few different ways to perform file operations on VMFS:
1. VMware Infrastructure Client (VIC) Datastore Browser. Albeit painfully slow, it does its job for simple interactive file operations.
2. Direct access to VMFS from within ESX service console. Any Linux application or agent can see and interact with storages mounted under /vmfs/volumes. This is how Veeam FastSCP interacts with VMFS file system on ESX hosts.
3. VMware Consolidate Backup (VCB). It is a standalone application capable of retrieving specified file from VMFS over direct iSCSI/FC shared storage connection (SAN mode), over network (NBD mode), and a few more advanced modes.
4. VMware vStorage API for Data Protection. In contrary to VCB being self-sufficient standalone application, think about vStorage API as merely VMFS file system driver that allows to access data on VMFS volume directly from Windows or Linux applications. All the same data retrieval modes are available with vStorage API as with VCB, including direct storage access. vStorage API does not require VCB modules installed to allow for this.
Of course, it is oversimplification for the sake of easier understanding – in reality, there’s whole API that abstracts dealing with actual VMFS file system driver and allows only a set of specific operations (in other words, you cannot do whatever you want with the VMFS file system).
Based on this description, it should be easy to realize pros and cons of VCB versus vStorage API. I’ve summarized main bullets below.
VCB
Pros
- You can potentially script it, and use as simplistic backup application.
Cons
- Does not allow for building flexible backup apps out of box (full VM files must be retrieved to staging area on VCB proxy before processing – so no incremental image-level backup).
- You need to get support for VCB from VMware (not your backup application vendor), which is less convenient and can potential cause finger-pointing situation with some vendors.
- You will have additional application to monitor/babysit (hung vbcmounter.exe anyone?).
vStorage API
Pros
- Provides greater flexibility for VM data access to backup vendors (block-level access to VMDK files).
- Implements new vSphere functionality that is not available through VCB, like changed block tracking (today), and fault-tolerant VM backups (in future).
- Single-vendor support for your backup solution.
- No extra application to monitor/babysit.
Cons
- Unlike VCB, you cannot easily script it, and use as a simplistic backup application.
It is important to note, that vStorage API is not just for vSphere ESX(i) 4, as it works with VI3 ESX(i) 3.x just fine too. However, new ESX 4 features like changed block tracking are not available on ESX(i) 3.x – while they do make huge difference!
For instance, Veeam Backup and Replication 4.0 – which takes full advantage of all new vStorage API functionality – demonstrates this quite well. Based on the closed beta feedback from real production environments, our new release enables for ”literally next generation of backups”, with incremental image-level backup of a typical VM taking under 1 minute!
Or, let’s put this in another way: it means that you can shrink your current backup window in 10-20 times… quite impressive? I thought so to…
Most certainly, VMware did an awesome job with ESX 4. I personally consider vStorage API changed block tracking alone sufficient to justify upgrade to vSphere for any VI3 customer – not even considering other great new vSphere features.
Have you upgraded your hosts to vSphere ESX4 yet? 
A quick correction – you need to be explicit – the vStorage API has several sections:
1) vStorage API for Data Protection (this is what you’re talking about) – a set of APIs focused on local backup/recovery use cases. You cover this well.
2) vStorage APIs for Site Recovery Manager – a set of APIs focused on array vendor remote replication such that they can be orchestrated by Site Recovery Manager.
3) vStorage APIs for Multipathing (otherwise known as the Pluggable Storage Architecture). A set of APIs for 3rd parties to extend vSphere’s core multipathing architectures.
4) vStorage APIs for Array Integration (VAAI). Technically not in vSphere 4, but have been discussed in VMworld events in the past. Will be available in future vSphere-generation releases. This allow array vendors to “offload” various tasks from the ESX host’s vmkernel stack – things like writing blocks that make up VMs, copying/snapshotting blocks, doing thin-provisioning out of space handling, and also a much more advanced global locking mechanism than VMFS uses today. These each will make common actions 5x-10x faster (clone, deploy from template, create a FT VM), and improve VMFS scaling by an order of magnitude. More on that here, for folks that are interested (note that when I wrote this, vStorage API for Data Protection was called the VCB Backup Framework)
http://virtualgeek.typepad.com/virtual_geek/2008/09/so-what-does-vs.html
Cheers Chad, I did not put the full name in the title to make it short, but I did explicitly state the full name of the API I am talking about later. Your comment is very useful addition to the post though!