Free space of the Datastore was showed in the VC is wrong

[stephanie]

Hi All,

We found the following issue.

A datastore was created with a new LUN with 30GB size. A virtual disk in a VM that use 29GB disk size of the new datastore, but the free space of the datastore is intermittently showed 29GB viewed from the VC.

This happens on more than one datastore from time to time.

The storage system model is Dell EMC CX3-20 and the server is HP Blade Server BL460C.

The ESX server is running with Vmware 3.0.2 and the VC is 2.0.

Please help to comment/advise, thanks a lot.

[rossb2b]

Does it show the correct info if you do a rescan?

[stephanie]

The user does't need to rescan, when he views the info again, he can get the correct free size of the data store.

It happens only intermittently.

[rossb2b]

If you do a vdf from the service console is that info always correct?

[Troy_Clavell]

restarting the mgmt service on all the hosts within the cluster usually fixes the problem.

at the ESX console type

service mgmt-vmware restart

[opbz]

Hi exactly what version of VC do you have. You mention just VC 2.0

There is a VC 2.02 update 1 that might resolve your issue.

restarting the mgmt-vmware service will resolve this

[Byron_Zhao]

I think it is VC showing the incorrect free space. In my experience, it happens to all versions of my VirtualCenter. Before deploying a new VM to a datastore, I need to right click on the SAN LUN (after clicking on a ESX host, in the summary tab), and refresh it. It will show the correct free space. No need to do a rescan, which takes a longer time to do it.

[eric_heilig]

I am seeing the same behavior with VC 2.0.2 update1.

My theory is that each of the cluster nodes is reporting their last scan of the LUN to VirtualCenter and that those numbers are out of synch somehow. Is it possible that the VI client is trying to rationalize the conflicting data? Or perhaps that a single value is being overwritten by the last ESX node to scan the LUN?

Perhaps some digging into the database could sort this out.

Thanks!

Eric Heilig

[stephanie]

Thanks to all for your response. Has anyone seen the issue on VC 2.5? We are using VC 2.0.2.

[meckatzermichel]

Yes, the issue is occuring on vc2.5.0 build 64192.

I'd like to know if it is fixed in build 64201.Does anyone know?

Michael

[hugopeeters]

I have the same issue with VC 2.5 build 84767.

A refresh of the properties of the datastore solves the problem most of the times. Annoying part for me is; also my Powershell VI Toolkit scripts are reproting wrong numbers.

[passahobe]

Hello

Don't forget that a VM on a LUN can use the .vswp file on the same storage location of the VM.

If your vdisk occupies 29 GB on a 30 GB LUN may be that the issue has occurred because the .vswp file is reclaiming more space than 1GB (the LUN available). If you can, create a higher LUN (32 GB for instance) and move the VM to this LUN. You can use the SVmotion for that.

I hope this helps you.

[znuz]

I was having the same problem with the powershell script reporting the wrong numbers and I found the answer in this thread:

http://communities.vmware.com/thread/168008

I was able to perform a RefreshDatastore() just before retrieving the FreeGB and UsedGB properties of the datastore and it then returns the correct information.