If it has to be a monitoring plugin I would recommend looking into the powershell sdk instead of the perl one as VMware is doing a horrible job with the perl one and writing your own plugin.
Why I did not recommend the Perl SDK is quite simple. It uses Perl libraries that are quite old, deprecated and uncommon which makes installation and maintenance a burden and there is no support from the vendor (You only get support with a dev subscription but I did not find a way to get one when I was still doing vmware at my old employer and when I was doing research for a customer). But if you already have it up and running, no problem to stick with it.
After some bad experience I would write my own soap requests. At first it looks more complicated and could be too much for a simple plugin, but later on the code will be less bloated than the SDK and you avoid problems like in the past where the SDK could only be installed in a patched version as perl modules were not installable on a “modern” operatingssystem.
But as I said if you already have the SDK up and running feel free to use it, especially if you develop the plugin for internal use only.
Powershell runs fine on RHEL 7, but I have never tested the SDK on something else then Windows and this is also quite a while ago. The compatibility matrix says it is linux-compatible, but again the overhead would be big I think.
Currently we roll our own rpms from the VMware-vSphere-Perl-SDK-*.x86_64.tar.gz file, using an approach a.la. this:
So far it has been working ok for us.
I wonder if there are already less bloated “alternative” VMware APIs out there, with people creating their own unofficial wrappers in the way you describe. Interesting thought.
And thanks for the PowerShell info, it might be interesting for us to look into that at one point also