Network issues with VMware Tools 10.2.0 and Windows Server 2008 R2 Guest VMs

When you’re (still) running Windows 2008 R2 and are using VMware Tools 10.2.0 you might run in an issue regarding to network loss. VMware has published KB54459.

Windows Server 2008 R2 guest VM ports are exhausted after upgrading to VMware Tools 10.2.0


  • Guest virtual machine ports are exhausted after a few days.
  • Networking is lost.
  • Network connections cannot be made.


VMware has fixed the issue with the release of VMware Tools 10.2.5.

Ports are exhausted on a guest VM after using VMware Tools 10.2.0

Guest VM ports are exhausted after using VMware Tools 10.2.0. This results in network connection failure.

This issue is resolved in this release.


But how do you know if you’re running this buggy combo? Well PowerCLI to rescue. The script below gathers all the VMs running Windows 2008 R2 and VMware Tools 10.2.0:

Import-Module VMware.VimAutomation.Core

Connect-VIServer -Server <vCenterName>

$AllVms_view = get-view -ViewType VirtualMachine -Property Name, Config, Guest

Disconnect-VIServer -Confirm:$false

$AllAffectedVMs = $Allvms_view |?{$_.Config.GuestId -eq 'windows7Server64Guest' -and $_.Config.Tools.ToolsVersion -eq '10304'}

$AllAffectedVMsInfo = @()
$AllAffectedVMs | % {

  $AllAffectedVMsInfo += [pscustomobject]@{
     Name = $_.Name
     ToolsVersion = $_.Config.Tools.ToolsVersion
     GuestOSId = $_.Config.GuestId
     GuestFullName = $_.Config.GuestFullName

$AllAffectedVMsInfo | ft -AutoSize

Copy the script and change the <vCenterName>. The script will gather all the VMs via Get-View with the Name, Config and Guest properties only. So it’s lightning fast. Once the script has all the information the filtering will take place.  The variable $AllAffectedVms contains all the VMs with Windows 2008R2 as GuestOS and with tools version 10304. Take a look at to correlate all the different version/build numbers.

The fix is easy. Just upgrade the VMware Tools on the affected VMs.

PowerCLI: VMware Tools one-liners

In this post I’ll show you three PowerCLI one-liners to perform some operations with VMware Tools.

The first one-liner will return all Powered on VM’s with Windows selected as guest OS and perform a VMware Tools upgrade without a reboot at the end.

Get-VM | Where {$_.PowerState -eq "PoweredOn" -and $_.Guest.OSFullName -match "Win*"} | % {Update-Tools -VM $_ -NoReboot}

Sometimes if you want to perform a vMotion or when you try set a host in maintenance mode, the VM won’t vMotion away from the host. Most of the time this is caused by a mounted ISO from a locale datastore. In my environment this is not possible because I use a shared storage datastore to storage all the ISO files. But there is one ISO that’s mounted from a locale datastore, this is the VMware Tools ISO.  Sometimes the ISO isn’t automatically dismounted from the VM. This one-liner creates a list of VM’s where the VMware Tools ISO is mounted:

(Get-VM | Get-View | Where {$_.Runtime.ToolsInstallerMounted}) | % {$_.Name}

The last one-liner will dismount the VMware Tools if necessary:

(Get-VM | Get-View | Where {$_.Runtime.ToolsInstallerMounted}) | % {Dismount-Tools -VM $_.Name}

I think there will be a lot more possibilities to script with PowerCLI and VMware Tools. So if you have a question or an idea, please leave a comment below.

Slow mouse performance on Windows 2008 R2 virtual machine

I wanted to migrate the lab to Windows Server 2008 R2 and found some problems with the video drivers provided with vSphere 4.0. After a quick search at I found the following KB article: KB1011709. This article mentioned the new WDDM driver:

Troubleshooting SVGA drivers installed with VMware Tools on Windows 7 and Windows 2008 R2 running on ESX 4.0

  • You receive a black screen on the virtual machine when using Windows 7 or Windows 2008 R2 as a guest operating system on ESX 4.0.
  • You experience slow mouse performance on Windows 2008 R2 virtual machine.

This issue can occur due to the XPDM (SVGA) driver provided with VMware Tools. This is a legacy Windows driver and is not supported on Windows 7 and Windows 2008 R2 guest operating systems.

To resolve this issue, update to ESX 4.0 Update 1. A new WDDM driver is installed with the updated VMware Tools and is compatible with Windows 7 and Windows 2008 R2.

Note: After a VMware Tools upgrade, the driver files are located in C:\Program Files\Common Files\VMware\Drivers\wddm_video.

Continue reading

Linux: Disk Timeout settings not increased by VMware Tools

Recently I had some issues with Linux VM’s which became read-only. In my earlier post about disk-timeout settings I wrote about the timeout value being increased during the VMware Tools installation. But how does the VMware Tools install change this value. I though the solution can be found within the script. So to find the script just run:

[root@linuxvm1 ~]# type is /usr/bin/

No run the less commmand:

less /usr/bin/

press / and type 180 now you see the info we are looking for:


The disk timeout value can only be changed with Linux kernel 2.6.13 or higher. Ok so what if you use a Linux distribution with a kernel older than 2.6.13? From KB51306:

VMware has identified a problem wherein file systems may become read-only after encountering busy I/O retry or SAN or iSCSI path failover errors.

The same behavior is expected even on a native Linux environment, where the time required for the file system to become read-only depends on the number of paths available to a particular target, the multi-path software installed on the operating system, and whether the failing I/O was to an EXT3 Journal. However, the problem is aggravated in an ESX Server environment because ESX Server manages multiple paths to the storage target and provides a single path to the guest operating system, which effectively reduces the number of retries done by the guest operating system.

These guest operating systems are affected:

  • RHEL5 (RedHat)
  • RHEL4 U6
  • RHEL4 U4
  • RHEL4 U3
  • SLES10
  • SLES9 SP3 
    Note: This issue may affect other Linux distributions based on early 2.6 kernels as well, such as Ubuntu 7.04.

This situation can lead to serious issues and can only be solved with a reboot of the VM. But there is a workaround. From KB1009465:

Increasing the timeout value

The timeout value for a Linux block device can be set using sysfs.
Note: This is usually increased automatically when deploying VMware-Tools, but if it is not installed, you will need increase it manually.

Check the current values using the following command:

for a in /sys/class/scsi_generic/*/device/timeout; do echo -n "$a "; cat "$a" ; done;

Increase the timeout value for an individual disk using the following command. For example to change the values for device sdc, run:

echo 180 > /sys/block/sdc/device/timeout

Run the following command to change the timeout values for all devices to 180:

for i in /sys/class/scsi_generic/*/device/timeout; do echo 180 > "$i"; done

you can add the following command:

for i in /sys/class/scsi_generic/*/device/timeout; do echo 180 > "$i"; done

to the /etc/rc.d/rc.local file to make sure the disk timeout is changed during startup.

VMTN communities

vSphere: The Virtual Machine is installing VMware Tools and Cannot Initiate a Migration Operation


After upgrading a large group Virtual Machines  to the latest build of VMware Tools. I got an error when I started a vMotion task on a some VMs.


The warning is pretty clear but I couldn’t cancel the VMware Tools wizard from the vSphere client. After a short search on Google I found a post from Bob Plankers

The solution is quite simple. Logon to the ESX host where the VM is running on and run the following command:

/usr/bin/vmware-cmd -l

Now you get a list of all the registered VMs on that host. Copy the full path of the vmx from the VM you want to migrate with vMotion. Now run the vmware-cmd pathtovmx getid command:

/usr/bin/vmware-cmd /vmfs/volumes/datastore-name/vm-folder/vmx-file.vmx getid

The latest step is to run the following command. Just replace the idnumber with number you get with the previous command:

/usr/bin/vmware-vim-cmd vmsvc/tools.cancelinstall idnumber

Now you are able to migrate the VM with vMotion again.


VMware Tools: Uninstall failed. Please correct the failure


Today a ran into an issue with the VMware Tools installer on Linux:


The solution was simple this time. Just remove the locations file from from /etc/vmware-tools. You can do this by running the following command:

rm –f /etc/vmware-tools/locations

Now you are able to run the VMware Tool installer again. If you are installing the VMware Tools on it default locations, you can add the –default parameter to the ./ command to install the VMware Tools on it’s default location.

Source: KB1013159