This is a wrap-up post of recent series on vSphere guest operating system management APIs. If you missed them, here are a few links to related posts: [Note: these are not related to the vSphere Guest API.]
- How to Upload File to Guest Operating System on VMware
- How to Download File from Guest Operating System on VMware
- Set Environment Variables in Guest Operating System on VMware
- Read Environment Variables in Guest Operating System on VMware
- Run, Kill, and List Programs in Guest Operating System on VMware
- Announcing Guest Operating System Management API for vSphere
After reading these posts, you may wonder (at least, I did): Why should we use these guest operating system related APIs? Can’t we simply use well-known alternatives like HTTP to download/upload files, SSH/WMI to run programs, etc.? To some extents, you are right but not exactly.
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
For one thing, all these remote manageability to a guest operating system requires network connection to the guest OS. With vSphere APIs, it doesn’t. All you must have is networking connection to the ESXi on which the guest operating system is running. I think this is the biggest uniqueness of this APIs.
This does not mean you don’t need remote manageability. In fact, you do. The question is really when you should use which.
To answer the question, you have to first consider the accessibility of the management network to the ESXi. In general, this is a separate network dedicated for management, nothing else as a best practice. This limitation actually excludes lots of use cases already. It basically suggests that you use vSphere API only in management applications which can access management network.
The second consideration is the performance. In general, I felt, without apple to apple comparison, that the vSphere API is slow especially when moving files from and to a guest operating system. I think it’s in part due to the fact that ESXi is a middleman in between.
To sum up, the guest management APIs via vSphere is not meant to be used as a general approach for communicating with a guest operating system. Only these management applications with ESXi access should use these APIs. For other general purpose communications like download files, use whatever existing protocols/APIs out there as would you work with an operating system running directly on a physical machine.