Size of the attached LUNS to the ESX host are reported incorrectly

This article outlines information on troubleshooting issues where the size of attached LUN's to an VMware Infrastructure/ESX host are being reported incorrectly on different VMware Infrastructure/ESX Servers after a discovery and/or refresh.

The data inconsistency may appear when multiple VMware Infrastructure/ESX servers in a farm are connected to the same data store.

In an environment where there is an VMware Infrastructure/ESX farm connected to multiple LUN's on a datastore, an issue can occur where different VMware Infrastructure/ESX Servers are reporting a different size for the same LUN in the datastore. Performing a refresh or un-discovering the Server does not resolve the issue.

For Example:

A User has discovered 3 servers of a 15 server VMware Infrastructure Server farm. These servers each have a path to 41 separate LUN's on an EMC backend storage.

Looking at one of the LUN's (DC1-LUN-011) - the actual LUN size is 299 GB and the actual free space is 156 GB:

However, upon reviewing the free space of the same LUN from two different VMware Infrastructure Servers within the farm, the free space is reported as follows:

In many cases users may not be able to undiscover the VMware Infrastructure/ESX Server in the farm as there may be Incremental synchronization jobs set to the same Target Server. To resolve the issue the following steps are required:

1. Restart the host agent
2. Log onto the service console and restart the host agent using the /etc/init.d/mgmt-vmware restart command.  This command will restart any host agents running on the VMware Infrastructure/ESX server.  All services provided by these agents will be temporarily stopped and any calls to the VMware Infrastructure Webservice will fail, and any VMware Infrastructure Center sessions will be ended.
   
   PowerConvert only uses the VMware Infrastructure Webservices to issue commands to the VMware Infrastrcutre/ESX server (i.e. discovery, create VM, etc).  If an incremental job is running, this does not involve the VMware Infrastructure/ESX server host agents, since the PlateSpin controller is running inside the target VM on the VMware Infrastructure/ESX server.   Please note that after the initial phase of the conversion and once the file copy has started, PowerConvert does not use the VMware Infrastructure Webservice, and it is safe to restart the service.  Also, this will not have any effect on existing Incremental synchronization jobs (i.e. Incremental synchronization job exists, but is not running). 

Notes

• Test restores are not affected after the machine is restored and waiting for the user to shut down.
• Synchronization jobs may fail depending on the timing of the service restart.  This is highly unlikely however, and the job can be restarted.
• Since running VM’s are not stopped, its operations will not be affected by the restart of the VMware Infrastructure Webservice