Hi all,
We just upgraded from RHEL5 to RHEL6 and attempted to load the SDK v6. *SOME* of our standard perl scripts that gather inventory data from assorted vCenter servers are failing with the following error:
Can't load class 'HostSriovInfo' at /usr/local/share/perl5/VMware/VIMRuntime.pm line 52.
We are, however, able to run a connect.pl successfully to all vCenters with the same credentials. Any ideas out there that might help us troubleshoot this?
Thanks,
-Mike Gray
Unfortunately, the modules aren't versioned, every version uses the same name 'VIM25Stub.pm' in this case. The likely problem here is an older VIM25Stub.pm (from <5.5, since 5.5 introduced that object type).
Might want to double check to see how many VIM25Stub.pm files are on the system, and if they are the same (simple md5sum would work).
From my vSphere 6.0 VIPerl SDK install system:
$ sudo find / -name VIM25Stub.pm -type f -exec md5 {} \; 2>/dev/null
MD5 (/System/Library/Perl/5.18/VMware/VIM25Stub.pm) = 6740555623a9613b4f9a50b29b457eaf
You can just check if the package name is in the file (make sure you're getting the one that Perl is picking up in it's @INC).
$ egrep -r "HostSriovInfo" ./*
./VIM25Stub.pm:package HostSriovInfo;
./VIM25Stub.pm:VIMRuntime::make_get_set('HostSriovInfo', 'sriovEnabled', 'sriovCapable', 'sriovActive', 'numVirtualFunctionRequested', 'numVirtualFunction', 'maxVirtualFunctionSupported');
Any chance you're loading the older vSphere 5.0 API modules (VIM25Stub.pm)? If it's 5.5, should be there, if it's 5.0, might not be. Maybe check the perl path and see which module is loading by default?
I'm relying on a buddy who is very Perl-savvy and he showed me my script is definitely using 25Stub. Not sure how I would direct it to user the newer modules. I assumed since I've loaded the v6 SDK, it would always point to the newest version...
Unfortunately, the modules aren't versioned, every version uses the same name 'VIM25Stub.pm' in this case. The likely problem here is an older VIM25Stub.pm (from <5.5, since 5.5 introduced that object type).
Might want to double check to see how many VIM25Stub.pm files are on the system, and if they are the same (simple md5sum would work).
From my vSphere 6.0 VIPerl SDK install system:
$ sudo find / -name VIM25Stub.pm -type f -exec md5 {} \; 2>/dev/null
MD5 (/System/Library/Perl/5.18/VMware/VIM25Stub.pm) = 6740555623a9613b4f9a50b29b457eaf
You can just check if the package name is in the file (make sure you're getting the one that Perl is picking up in it's @INC).
$ egrep -r "HostSriovInfo" ./*
./VIM25Stub.pm:package HostSriovInfo;
./VIM25Stub.pm:VIMRuntime::make_get_set('HostSriovInfo', 'sriovEnabled', 'sriovCapable', 'sriovActive', 'numVirtualFunctionRequested', 'numVirtualFunction', 'maxVirtualFunctionSupported');
Fantastic! My coworker started walking through the various versions of the stub25 file and found one without the HostSriovInfo entry:
[root@myhost ~]# locate VIM25Stub.pm
/usr/lib/vmware-vcli/VMware/share/VMware/VIM25Stub.pm
/usr/local/share/perl5/VMware/VIM25Stub.pm
/usr/share/perl5/VMware/VIM25Stub.pm
[root@myhost ~]# cd /usr/lib/vmware-vcli/VMware/share/VMware/; egrep -r "HostSriovInfo" ./*
./VIM25Stub.pm:package HostSriovInfo;
./VIM25Stub.pm:VIMRuntime::make_get_set('HostSriovInfo','sriovEnabled', 'sriovCapable', 'sriovActive', 'numVirtualFunctionRequested','numVirtualFunction','maxVirtualFunctionSupported');
[root@myhost ]# cd /usr/local/share/perl5/VMware/; egrep -r "HostSriovInfo" ./*
[root@myhost ]# cd /usr/share/perl5/VMware/; egrep -r "HostSriovInfo" ./*
./VIM25Stub.pm:package HostSriovInfo;
./VIM25Stub.pm:VIMRuntime::make_get_set('HostSriovInfo','sriovEnabled', 'sriovCapable', 'sriovActive', 'numVirtualFunctionRequested','numVirtualFunction','maxVirtualFunctionSupported');
We probably should've just updated the Perl path, but we ended up copying the newer stub25 file into the older location. This WORKED! We then updated the perl path as well. I guess my final question is, why doesn't the VMware SDK Perl package add the new path to your system when it installs? Seems odd it installs a brand new set of files but doesn't update the default path to actually USE these new files...
Thanks again for the quick response!
No problem, seen the issue a few times myself
Issue noted Mike, and I'll follow through with Support and the SDK Team since you're a TAM Services Customer.