Home > Software Development, vSphere API	> vSphere APIs for Guest Operating System Management: What’s Special and When to Use It?
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.
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.
Hi Steve, thanks for the great work on the APIs!
It seems the APIs allow a great deal of new modify access to the guest OS from vCenter – how does VMware intend to address this?
I’d suggest ideally there would be a decentralized (secure) sudoers list of allowed guest operations to mitigate a vcenter compromise.
I now see your comment! Thanks for reminding me on Twitter and trying it again!
To gain access to an OS, you will need credential as would you log in the OS directly. I think you raised a good point to use sodo for better auditing.
I like the VI Java API.
I would like to use this “vSphere APIs for Guest Operating System managment” too.
Do you have plans to share its source code ?
but it have a issue.
it always throw GuestPermissionDenied exception.
are u have any idea?
Hi lihlcnkr, interesting issue. what if you re-login? just wonder if you can work this around.
after hot adding nic device, guest OS API is not working again.
and after hot adding nic device, I try to use vSphere upgrade GuestOS VM tool , but it fail.
So, it looks when hot adding nic device, GuestOS VM tool is not working well.
I Tested it win 2003 and win 2008 server R2, It’s same result.
Let’s try to understand what you found out. After hot adding NIC to a VM running Windows 2003 and Windows 2008 SR2, the guest OS API stops working correctly with GuestPermissionDenied exception even after you re-logining, restarting guest OS, reset VM. Am I right?
Also, how about after removing the hot added NIC? I know it’s probably not acceptable in your case, but I am curious what would happen. What version of VMware Tools did you use? Had you upgrade the VMware Toosl before you hot adding NIC?
Yes, It’s just you say.
and after removing the hot added NIC, it also happen.
before hot adding NIC device, I upgraded the VMware Toosl.
Thanks Lihlcnkr, as you pointed out earlier, it’s mostly an issue with VMware Tools which carries real executions. You may want to contact VMware support on this issue. I believe part of VMware Tools is open sourced somewhere (search it), you also take a look there. But I wouldn’t recommend that unless you are really familiar with low level programming. Even so it’s still a lot of work.
I contacted VMware support team, but they said for technical support, it need technical support license, it very expensive@@. and without support team, it can’t report bug directly.
Tech support license needed to file a bug with VMware? It doesn’t make senese to me. Maybe for a solution but not for filing a bug. Can you ask around on Twitter and cc me there? Thanks!
I posted on twitter and vmware community.
And I tested it again using vSphere powerCLI, and result is same.
and I Installed open source vmware tool(open-vm-tools) on linux, and tested it.
but looks open-vm-tools not working well with guest OS API.