vminfo.pl has ceased working

[hostasaurus]

I've got the perl CLI tools installed on a CentOS 5 x64 system and everything has been working fine.  We have a custom script that lets us reboot vm's from the command line.  It's primarily dependent on:

/usr/local/lib/vmware-vcli/apps/vm/vminfo.pl

to get the list of machines.  Starting a few days ago, that has begun returning:

Can't load class 'VirtualAHCIController' at /usr/lib/perl5/site_perl/5.8.8/VMware/VIMRuntime.pm line 52.

I've found reference to that class in /usr/lib/perl5/5.8.8/VMware/VIM25Stub.pm and I see no reason why it wouldn't be loaded, but am not positive what triggers its loading.  Anyone have ideas on what I should look at?

[nrohtagi]

This kind of error happens when, server side has the object but client doesn't have the supporting stubs.

rCLI uses VIM2Stub.pm (not VIM25Stub) which doesn't have definition for “VirtualAHCIControlle” object.

Hope this helps.

[hostasaurus]

Ah, thanks for that info.  Very odd that it just stopped working; we did an upgrade to 5.5 at least a month before the issue began.  It is possible that the vmware tools were upgraded around the time it stopped working; could that have messed with the rCLI files?  Kind of grasping at straws now.  I may try to build a new management system from scratch and reinstall to see what happens.

[scottsavarese · Accepted solution]

VirtualAHCIController is a SATA device according to vSphere 5.5 Documentation Center . I ran into the same issue that you did and found this thread. Since its only me managing the environment, I know all the changes that were made in the past few days and was able to audit all the VM's I created. I found that the one VM I created via the web portal (versus my SDK script) had a SATA controller on it. By pointing the CDROM drive to the IDE controller and saving the config and then removing the SATA controller from the VM's hardware my perl scripts now worked.

I then proceeded to download the latest Perl SDK tar ball from vSphere SDK for Perl Documentation and opened it up. I found that there is no AHCI controller in the Stubs directory at this point in time:

[root@thinfra01 vmware-vsphere-cli-distrib]# find . -name *AHCI*

[root@thinfra01 vmware-vsphere-cli-distrib]# find . -name Stubs

./lib/WSMan/share/WSMan/Stubs

So, the next step is to open up a ticket with VMware. Since I don't often use SATA devices on my VM's, I'm not going to bother (I don't have the cycles). But I urge folks that have had this issue to open tickets and get the SDK updated.

[hostasaurus]

Awesome, thanks Scott, that was the issue.  I had to run /usr/lib/vmware-vcli/apps/vm/vminfo.pl --verbose and then in the output file, search for AHCI.  I found one VM that had been created from scratch recently, instead of via our templates, and it got a SATA controller for no particular reason.  I removed that and things are back to normal.

I'll definitely open a ticket about the issue; it's incredibly stupid of them to not update the SDK when they make changes like that.  If it had taken a critical application down I'd have been really pissed.

[cfsullivan]

I am getting the exact same error. Here's how it applies:

A Perl script runs which upgrades VMware Tools as part of our Windows VM provisioning process. The VMs are created from templates. I created a new template for the first time in a while recently and hadn't noticed that it includes a SATA controller. Needless to say, the Perl script for upgrading the Tools fails with the error.

I figure if I set the DVD drive on the template to use an IDE controller and remove the SATA controller, we will get around the problem. I would rather not do that if I don't have to. This thread is almost 3 years old, so I'm wondering if the issue has been resolved. Is there a newer version of the Perl Cli Tools that is not affected, or maybe some other workaround that doesn't involve changing the guest.

In any case, I'm glad I have this option if needed, so thanks for the workaround.

Thanks.