VMware Tools: Default disk timeout settings


image 

On a new Windows Server 2003 server without the VMware Tools installed, there are no TimeOut settings configured.

You can find this setting in the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\

The picture below, you’ll see the default settings from Microsoft:

image

After the installation of the VMware Tools, a new dword value called TimeoutValue is added with the hexadecimal value of 3c. This value represents a timeout of 60 seconds.

image

On a Linux VM the default timeout is 60 seconds (on a CentOS setup). You can find the timeout settings in:

/sys/block/<disk>/device/timeout

image

After the installation of the VMware Tools, the timeout value is changed to 180 seconds.

image

 

More info about this subject can be found here:

Advertisements

How To: Install VMware Tools on CentOS 5.3


image image

The first step after a fresh install of a CentOS 5.3 server is too install the packages gcc and kernel-devel. When these packages are installed, update them and reboot of the VM:

yum install gcc kernel-devel –y
yum update –y
reboot

Now we have to create a new folder so we can mount the VMware Tools cd-rom.

mkdir /media/cdrom –p

Start the VMware Tools Installer via the GUI:

image

Mount the cd-rom:

mount /dev/cdrom /media/cdrom

create a folder and copy the tar.gz file from the cd-rom to the folder:

mkdir /root/tarz –p
cp /media/cdrom/VMwareTools-4.0.0-xxxxxx.tar.gz /root/tarz/

Open the folder and extract the tar.gz file:

cd /root/tarz
tar zxvf VMwareTools-4.0.0-xxxxxx.tar.gz

Open the vmware-tools-distrib folder and start the installer:

cd vmware-tools-distrib
./vmware-install.pl

You can change the vnic to vmxnet via the following commands:

/etc/init.d/network stop
rmmod pcnet32
rmmod vmxnet
modprobe vmxnet
/etc/init.d/network start

The final step is to reboot the VM.

PowerCLI: Upgrading vHardware to vSphere Part 2: VM’s


image

Disclaimer: use this script at your own risk 😉

In part 1 you could find a script to upgrade your templates to hardware version 7. In this post you’ll find a script that will upgrade your VM’s to hardware version 7.

Note: This script will upgrade the VMware Tools if necessary and will shutdown the VM!!!!!

You can download the script here: upgrade-vhardware_vm and here: http://poshcode.org/1217

The script will perform the following actions:

  • Connect to vCenter
  • Get all the VM’s in the folder you need to specify
  • Create a CSV file with some info about the VM. I will post the content later.
  • Update the VMware Tools if necessary (The VM will restart after the installation)
  • Shutdown the VM
  • Upgrade the vHardware to version 7
  • Start the VM
  • Create an Excel sheet with an overview of the VM’s and their IP settings

During the process of the script, the VM will be unavailable for 5 minutes or less. So be sure that nobody uses the VM.

The beforeHWchange.csv will look like this:

image

The script in action:

image

The last step, the creation of an Excel sheet with an overview of the VM’s. Here you can see if the IP Address is changed or not.

image

To do list:

  • Create a proper VM report function (export to csv) so I can capture multiple network adapters.
  • Create a before Excel sheet with a nice overview of the environment.

PowerCLI: Change VMware Tools Options


image

In this post you will learn how to change the VMware Tools settings in the Options menu which you can find in the vSphere Client:

image

You can enable or disable these features via the following PowerCLI script:

$vCenter = Read-Host "Enter vCenter Server name"

Connect-VIServer $vCenter

$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
$vmConfigSpec.Tools.AfterPowerOn = $true
$vmConfigSpec.Tools.AfterResume = $true
$vmConfigSpec.Tools.BeforeGuestStandby = $true
$vmConfigSpec.Tools.BeforeGuestShutdown = $true
$vmConfigSpec.Tools.SyncTimeWithHost = $true
$vmConfigSpec.Tools.ToolsUpgradePolicy = "Manual" # "UpgradeAtPowerCycle"

Get-VM | % { (Get-View $_.ID).ReconfigVM($vmConfigSpec)}

Disconnect-VIServer -Confirm:$false

 

Just change the $true values to $false if you want to disable the feature. If you want to change the Tools Upgrade Policy to Upgrade at startup just remove "Manual" # and it should change the Policy.

This is what you see when the VM is still active:

image image

This script will change the configured settings on All the VM’s.  If you want to change the settings on a particular VM just change Get-VM into Get-VM vmname

VMware Tools Registry settings


image

@vmdavinci asked the following on Twitter:

image 

These are the registry settings you can change:

If you want to disable the notify if upgrade is available warning:

[HKEY_CURRENT_USER\Software\VMware, Inc.\VMware Tools]
@=dword:00000000

If you want to hide the Tools icon change the following registry key:

[HKEY_CURRENT_USER\Software\VMware, Inc.\VMware Tools]
"ShowTray"=dword:00000001

Or

[HKEY_LOCAL_MACHINE\Software\VMware, Inc.\VMware Tools]
"ShowTray"=dword:00000001

Restart VMware Tools on all Windows VM’s


 image

After reading the post on http://www.virtualvcp.com/content/view/82/1/ about the VMware Tools status “not running” and in particular the part about the preferred work around:

I find that restarting the VMware Tools Service in the guest OS always gets by the problem, but loggin into every single VM that reports the wrong status for it’s VMware Tools could be a bit of a drag. So I choose to do this remotely rather that logging on to each VM.

From any Windows workstation/server, open a command pompt and run:

sc \\{vm-name-or-ip-address} stop "VMTools"
sc \\{vm-name-or-ip-address} start "VMTools"

I thought that can be done via Powershell and the VI Toolkit. So I created the following script that will restart the VMware Tools service on every running Windows VM.

$vCenter = Read-Host "Enter the vCenter servername"

Connect-VIServer $vCenter

$Service = "VMtools"
$VMs = Get-VM | Where-Object {
        $_.PowerState -eq "PoweredON" `
        -and `
        $_.Guest.OSFullName -match "Windows"
    }
    
foreach($VM in $VMs)
{
    Write-Host "-------------------------------------------"
    Write-Host "Restarting the VMware Tools Service on" $VM
        $Svc = Get-WmiObject -Computer $VM win32_service `
        -filter "name='$Service'"
            $Result = $Svc.StopService()
            sleep 5
            $Result = $Svc.StartService()
    Write-Host "Done.. "
    Write-Host "-------------------------------------------"
}

Disconnect-VIServer -Confirm:$false

This script generates the following output:

image

Other useful blog posts or kb articles on this subject:

Source for the restart service part in my script: http://blog.geekpoet.net/2008/10/manipulating-remote-services-with.html

Veeam: Snapshot creation failed: Could not quiesce file system


 

A couple of days ago, I was testing with Veeam backup and a new created VM. The backup stops with the following error:

image

In the Veeam Backup release notes (veeam_backup_2.0.1_release_notes.pdf) and the known errors section, you’ll find the following text:

If you attempt to backup a VM with VMware Tools VSS support module installed with Veeam Backup job having VSS option enabled, the backup would fail with the following error: VCB error: Error: Other error encountered: Snapshot creation failed: Could not quiesce file system. An error occurred, cleaning up…. To resolve this, disable VMware Tools quiescence in the backup job properties, or uninstall VSS support module.

So I checked de VM and uninstalled the VSS option.

Go to Control Panel –> Add/Remove Programs –> VMware Tools. The VMware Tools Setup starts and in this screen press modify.

image

Disable the VSS Support feature in the VMware Tools.

image

Finish the setup wizard and reboot the VM.

 

After a reboot, the following error might popup:

image

The fix was a little bit funny. When I pressed the right mouse button on My Computer or any other directory, the Symantec Antivirus installer starts with a repair job.

image

After the repair job is done and the VM is back online after a reboot, the VM acts normal again :-S