vCenter Storage Monitoring Plug-in Disabled

October 18th, 2010 by jason Leave a reply »

Those who have upgraded to vSphere (hopefully most of you by now) may become accustomed to the new tab in vCenter labeled Storage Views. From time to time, you may notice that this tab mysteriously disappears from a view where it should normally be displayed.  If you’re a subscriber to my vCalendar, you’ll find a tip on July 18th which speaks to this:

Is your vSphere Storage Views tab or host Hardware Status tab not functioning or missing? Make sure the VMware VirtualCenter Management Webservices service is running on the vCenter Server.

The solution above is an easy enough resolution, but what if that doesn’t fix the problem?  I ran into another instance of the Storage Views tab disappearing and it was not due to a stopped VMware VirtualCenter Management Webservices service.  After a short investigation, I found a failed or disabled vCenter Storage Monitoring (Storage Monitoring and Reporting) plug-in:

SnagIt Capture

For those who cannot read the screen shot detail above, and for the purposes of Google search, I’ll paste the error code below:

The plug-in failed to load on server(s) <your vCenter Server> due to the following error: Could not load file or assembly ‘VpxClientCommon, Version=4.1.0.0, Culture=neutral, PublicKeyToken=7c8-0a434483c7c50’ or one of its dependencies. The system cannot find the file specified.

I performed some testing in the lab and here’s what I found.  Long story short, installation of the vSphere 4.1 Client on a system which already has the the vSphere 4.0 Update 1 Client installed causes the issue.  The 4.1 Client installs a file called SMS.dll (dated 5/13/2010) into the directory C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Plugins\SMS\ overwriting the previous version (dated 11/7/2009).  While the newer version of the SMS.dll file causes no issues and works fine when connecting to vCenter 4.1 Servers, it’s not backward compatible with vCenter 4.0 Update 1.  The result is what you see in the image above, the plugin is disabled and cannot be enabled.

Furthermore, if you investigate your vSphere Client log files at C:\Users\%username%\AppData\Local\VMware\vpx\ you’ll find another similar entry:

System.IO.FileNotFoundException: Could not load file or assembly ‘VpxClientCommon, Version=4.1.0.0, Culture=neutral, PublicKeyToken=7c80a434483c7c50’ or one of its dependencies. The system cannot find the file specified.

Copying the old version of the SMS.dll file into its proper location resolves the plug-in issue when connecting to a vSphere 4.0 Update 1 vCenter Server, this much I tested, however I’m sure it immediately breaks the plug-in when connecting to a vCenter 4.1 Server (I didn’t go so far as to testing this).

Essentially what this boils down to is a VMware vSphere Client bug which is going to bite people who have both vCenter Server 4.0 and 4.1 in their environment, and the respective clients are installed on the same endpoint machine.  I expect to hear about this more as people start their upgrades from vSphere 4.0 to vSphere 4.1.  Some may not even realize they have the issue, after all, I didn’t notice it until I was looking for the Storage Views tab and it wasn’t there.  After lab testing, I did some looking around on the net to see if anyone had discovered or documented this issue and the only hit I came across was a recently started VMware Communities thread, however, there was no posted solution.  The thread does contain a few hints which would have pointed me in the right direction much quicker had I read it ahead of time.  Nonetheless, time spent in the lab is time well spent as far as I’m concerned.  Unfortunately, there’s no fix here I can offer.  This one is on VMware to fix with a new release of the vSphere 4.1 Client.

Update 12/1/10:  VMware has released KB 1024493 to identify this problem and temporarily address the issue with a workaround:

Installing each Client version in different folders does not work. When you install the first Client you are asked where you want to install it. When you install the second Client, you are not asked for a location. Instead, the installer sees that you have already installed a Client and automatically tries and install the second client in the same directory.

To install vSphere Client 4.0 and 4.1 in separate directories:

  1. Install vSphere Client 4.0 in C:\Client4.0.
  2. Copy C:\Client4.0 to an external drive (such as a share or USB).
  3. Uninstall vSphere Client 4.0. Do not skip this step.
  4. Install vSphere Client 4.1 in C:\Client4.1.
  5. Copy the 4.0 Client folder from the external drive to the machine.
  6. Run vpxClient.exe from the 4.0 or 4.1 folder.

I’m expecting a more permanent fix in the future which addresses the .DLL incompatibility in the 4.1 vSphere Client.

Update 2/15/11:  Through some lab testing, it looks as if VMware has resolved this issue with the release of vSphere 4.1 Update 1 although KB 1024493 has not been updated yet to reflect this.  I uninstalled all vSphere Clients, then installed vSphere Client 4.0 Update 1, then installed vSphere Client 4.1 Update 1.  The result is the vCenter Storage Monitoring plug-in is no longer malfunctioning.  The Storage Views tab is also available.  Both of those items are a positive reflection of a resolution.  The Search function is failing in a different way but I’m not convinced it has anything to do with two installed vSphere Clients because it is also failing on a different machine which has only one vSphere Client installed.

Advertisement

No comments

  1. Michael says:

    Yes, I have already seen this. Very frustrating.
    Additional functions that don’t work in 4.0 client if you have both versions installed are:
    Search
    EVC settings screen of the cluster
    You cannot have both 4.0 and 4.1 SRM plug-ins installed

    VMware has published KB article referring the search function http://kb.vmware.com/kb/1024493 but I didn’t try it so far. Hopefully it solves the other issues too.