If you use thin VMDK in your lab or dev environments then you probably know that over time these VMs can inflate to very large size.  Say you deployed a windows server and gave the C:\ drive 80GB.  Initially that VM was maybe using ~30GB.  After some time you notice the VM is now 70GB but the OS still claims usage of ~30GB.  This is due to the way data is written and deleted from a disk.  The way to fix is to zero out the whitespace.

  1. Download sdelete from MS.

  2. Run the sdelete.exe utility against the C:\ using the -z parameter.

    sdelete.exe -z C:

  3. Power off VM and ssh to ESXi host.  Find the VMDK and run the following command.

    vmkfstools --punchzero diskname.vmdk

    Check size by typing:

    du -h diskname-flat.vmdk

  4. Finally power on your VM.


Starting with ESXi 5.1 Update3 TPS sharing is disabled by default.  This was done to close a potential security risk where one could gain unauthorized access to data.  VMware has stated in KB2080735 that this is only possible in a highly controlled scenario and the threat is minimal.  Nonetheless for highly secure environments this option should be left to a setting of "2".

For Non-Prod, DEV environments you may want to consider disabling this new feature.  Most Non-Prod environments have limited resources and thus sharing resources is highly valuable.  The setting is found under Configuration/Advanced Settings/Mem.ShareForceSalting using windows client and Host/Manage/Settings/Advanced System Settings/Mem.ShareForceSalting using the vSphere Web client.  Setting to 0 will disable the feature, allowing full TPS for all VMs.  A setting of 1 will allow TPS on specific VMs only, and a setting of 2 will not allow any TPS sharing.

For settings to take effect you must vMotion the VMs or gracefully shutdown/power-on the VMs.

Mem-ShareForceSalting Setting


If you have followed the Install Guide from NetApp (Storage_Replication_Adapter_30_for_Clustered_Data.pdf) and install appears successful but SRA will not Login/Register I may be able to help.

If you installed SRM on a drive other than C:\ you will encounter issue above.  We have a standard to install apps on separate drive from OS as this is consider general good admin practice.  Apparently the NetAPP SRA has hard coded the PATH where SRM is installed.  To fix the issue uninstall your SRA's and add a symlink to the location of SRM installation.

In my case the following command from an elevated prompt fix the issue:

CD "Program Files"
CD VMware
mklink /j "VMware vCenter Site Recovery Manager" "F:\Program Files\VMware\VMware vCenter Site Recovery Manager"

Reinstall SRA application and restart the SRM Service.  Login to vSphere and Rescan for SRA.  Your SRA adapter should show up healthy.


Useful PowerCLI one-liners.

# Get group of hosts by Name
$VMhosts = Get-VMHost | Where Name -Like '*esxpbc*'

# List specific vmkernel IP.  Can use IP or NAME to filter.
$VMhosts | Get-VMHostNetworkAdapter | where IP -Like '10.4.45*'

# List all Host vMotion network ip and vmkernel gateway.
Get-VMHost | Get-VMHostNetwork | Select Hostname, VMkernelGateway -ExpandProperty VirtualNic | Where {$_.VMotionEnabled} | Select Hostname, PortGroupName, IP, SubnetMask, VMkernelGateway, Devicename | FT

# List users with "Admin" permissions on vCenter.
Get-VIPermission | Where {$_.Role –eq “Admin”} | Select Role, Principal, Entity, UID | Export-CSV “C:\Temp\Rights.csv”

# List all user permissions on vCenter.
Get-VIPermission | Select Role, Principal, Entity, UID | Export-Csv "C:\Temp\perms.csv"


If you run HP G7, Gen8, or Gen9 servers and boot ESXi from SD card you may run into an issue/bug with certain HP iLO versions.  The issue causes the SD card to lose connectivity to the system.  This does not affect the host or VMs since VMware loads itself into memory, but will cause issues with management of the host.

I have dealt with this issue on and off for several months and here are some of the fixes you can try.  Ultimately, you want to patch your iLO to version without the issue but in a pinch these options will help you bring the host back into compliance.