Things That Make You Go Hmmmm – Veeam Backup Not Using Preferred Free ESXi APIs?

Nice post Rich. I really enjoyed Alex's article, I thought it was fair and balanced. I appreciate the virtualization community's input.

Once again, I am very impressed with Veeam's technology. They deliver value to their customers, especially those that are researching their options. I know when I was making a decision in my lab between ESXi and Hyper-V, Veeam's Backup product made my decision to choose VMware, and I ultimately upgraded to the paid version of ESXi.

Robert.

I help clients migrate from the free versions regularly. IMO customer conversions to the licensed versions of VMware hosts do not seem to be an issue. It may delay the conversion for a longer period if more advanced VM management was allowed, but the “gasoline fire” that is virtual infrastructure inevitably means more guest, more hosts, more storage, more networking ….

There's a similar problem with Lab Manager in terms of public/private SOAP api's. I think in that case they've simply chosen to put a much lower priority on updating the public API's. I've been automating some stuff in Lab Manager for the past couple weeks and for the most part the public SOAP api's are mostly useless for anything more than simply turning on an existing vm. The vast majority of the what's available is in the private API, which VMware provides little documentation and absolutely no support for.

The reasoning I've gotten on this issue is that they won't guarantee that the private API won't change with updates and that they are moving more from the private to the public API set. However, the Lab Manager sales guys are quick to tell you that you can do anything with the SOAP API that you can do with the standard interface, which is a very large stretch.

What'll be curious to see is if Veeam backup only stops working with ESXi free, or if the very similar FastSCP stops as well.. If they actually change to using only the public API, or add some code to block free ESXi…. OR
Does “dropping support for ESXi” necessarily mean that future versions stop working with ESXi?

It could just means their official position will be not to provide support services when running on free ESXi… i.e. technically the product will work with free ESXi, but it's an unofficial not-recommended use, and unsupported in the sense they won't offer support services like technical assistance in those scenarios, if you ask they'll say that the free ESXi is unsupported, unless your support agreement pre-dated 3.1, but no technical measure to stop you from doing it anyways.. (is conceivable)
-

Considering Veeam very publicly announced support for the free version of ESXi back in February for Veeam Backup and FastSCP, VMware has had lots of time to object.

I would say it's pretty interesting that VMware waited to ask them to stop supporting free edition in Veeam backup… until _after_ the release of VSphere 4.0, including VSphere Essentials Plus, with VMware Data Recovery (Less than 2 weeks after vSphere's release).

The fact Veeam is using VMware private APIs is not too surprising at all… It's basically
impossible to implement much using the public APIs. And Veeam's product is not the only one to use private APIs.

As far as I know it's the only one that had free ESXi support to suddenly drop it.
Only some very basic functions can be automated with the public API. There is no general purpose API for interfacing with all host functions, e.g. You want to implement a replacement for the management console, or your own web-based management with full virtual console?

If you're using the public APIs, forget about it, there's no way to get access to the VM console. And, if the free edition of ESXi is in use, the functions of the public APIs are hopelessly restricted, in a way that makes your alternative “VMware Console program” useless.

This is pretty disappointing, since the VMware VI Client seems in many ways bloated and sluggish; a lean mean, multi-platform alternative could be a very beneficial thing to have…

E.g. if the private APIs were public, I could see developing a VI client for Linux or MacOS, so I could manage from my workstation, despite VMware themselves not building one.

My suspicion is VMware has intentionally crippled the public APIs for at least two reasons: they want the free version of ESXi to be crippled, they probably don't want a third party to be able to sell some type of “addon” that will add missing features.

And, even for users of the paid version of VMware, I suspect don't want a third party to be able to write a complete replacement for vCenter, or to implement features like VMotion without a vCenter deployment.

If new management functions can be created for their hypervisor, VMware _wants_ to be the only company able to make and sell the new features.
E.g. Home field advantage

It's conceivable a third party could do it by reverse-engineering the APIs, but I guess they better not rely on being a VMware partner if they make that key to their business model…

And they better be prepared for VMware to take random measures to try to break their product, like changing APIs, or adding new “authentication features” designed to “secure” certain API calls, assuming they don't already..

Evil,

Great point. The only difference is Veeam is initiating a snap shot
and then deleting it during back up, but that seems trivial.

jibeddari,

I guess you could, but if you started selling your solution to VMware ESXi customers not just VMware but AutoIT and AutoHotkey would probably start paying attention. I think AutoIT is no longer open source and I am not sure about AutoHotkey.