Tuning Vmware Workstation 8 performance

In effort to squeeze a little bit more performance from my vSphere 5 whitebox, I tried to tune some settings of my VMware Workstation 8. Recently, I've found disk activity concerning .vmem files (From vmware.com: vmem is the virtual machine's paging file, which backs up the guest main memory on the host file system. This file exists only when the virtual machine is running, or if the virtual machine has crashed.). I don't think that I do need this files because I don't want suspend my virtual machines etc. I need pure performance, so I decided to tweak some Workstation settings. First of all find "config.ini" (In my Windows 7 it's located in "C:\ProgramData\VMware\VMware Workstation") and add/modify the following parameters:

mainMem.useNamedFile = "no"  - tells not to use .vmem files

prefvmx.minVmMemPct = "100"  - fit all virtual machine memory into reserved host RAM. Swapping won't be occurring so the host machine must have enough memory to accommodate  the sum of all memory reserved for every single virtual machine.


prefvmx.allVMMemoryLimit = "15000" - this parameter tells how much host memory can be used for the virtual machine memory allocation.

prefvmx.useRecommendedLockedMemSize = "yes" - well, to be honest I don't really need what this parameter do, but I've seen suggestion to enable it :)

vCenter error while trying to delete NAS storage

Today I've faced another interesting problem. I've added the NFS storage to the ESXi host, then I've added the same storage to the cluster. After a while I've noticed that one of the hosts had 2 storages attached with different names, but pointing to the same NFS target. When I've tried to delete the wrong one, I've got the foloowing error: "The object has already been deleted or has not been completely created". To make the things even more complicated, the virtual machines that were vMotion'ed to that ESXi host in a cluster, somehow changed their datastores to the wrong one (like background Storage vMotion). Thanks God that was testing environment :).

However the solution is very simple:
Just restart the management agents on the ESXi host. This will force the update at the vCenter Server.