vSphere: An error occurred, please try again in another vSphere session



From KB1014213:

When trying to update host data, you may experience these symptoms:
The vCenter Service Status shows the error:

An error occurred, please try again in another vSphere session.
The Hardware Status tab shows the error:

An error occurred, please try again in another vSphere session.

From: KB1013893

The VirtualCenter Server Service Status fails with the errors:

Cannot access the health service!

Login to the query service failed

Do not have permission for this command

The solutions mentioned in both the KB articles didn’t solve the issue for me. In my case name resolution was the problem. We use another domain for our vCenter server. The clients where not able to resolve the FQDN of the vCenter server. So I added the FQDN and ip address to the hosts file. After this little change and reconnecting the vSphere client, everything worked as it should be.


PowerCLI: Document the ESX Hostname of the vCenter VM


I was reading Duncan Epping his post: http://www.yellow-bricks.com/2009/10/09/best-practices-running-vcenter-virtual-vsphere/ about Running vCenter virtual. The most of the steps described, you only have to do once but step 5 needs to be documented once in a while

5. Write a procedure to boot the vCenter / AD / DNS / SQL manually in case of a complete power outage occurs.

Nobody likes to document this thing so we will let PowerCLI do this job for us.

First you need to now the VMs. In most cases this will be your Domain Controller, Database Server and of course the vCenter VM.

$vms =  Get-VM "DC01", "DB01", "VC01" | Sort Name
$vms | Select Name, @{N="Cluster";E={Get-Cluster -VM $_}}, `
@{N="VMHost";E={Get-VMHost -VM $_}} 

The one-liner above will return the VM name, Cluster Name and ESX Host name:


Now you are able to document where your VMs are. But you still need to put this information somewhere. So I created a simple script which will export the information displayed above to a CSV file. The script will also remove files older than 7 days.

You can change the variable if you want.

$now = Get-Date
$days = "7"
$targetFolder = "C:\vCenter"

if (Test-Path $targetFolder)
    Write-Host $targetFolder "Already exists"
    New-Item $targetFolder -type directory
    Write-Host $targetFolder "Created"

$lastWrite = $now.AddDays(-$days)
$files = get-childitem $targetFolder -include *.csv -recurse `
    | Where {$_.LastWriteTime -le "$lastWrite"} 

if (($files | Measure-Object).count -gt 0){
foreach ($file in $files)
{write-host "Deleting File $File" -foregroundcolor "Red"; `
    Remove-Item $file | out-null}

$filename = "C:\vCenter\" + (Get-Date -format  'yyyy-MM-dd hh-mm-ss') + '.csv'
$vms =  Get-VM "DC01", "DB01", "VC01" | Sort Name 
$vms | Select Name, @{N="Cluster";E={Get-Cluster -VM $_}}, `
@{N="VMHost";E={Get-VMHost -VM $_}} | `
Export-Csv -NoTypeInformation $filename

The script will generate a CSV file:


The CSV file will look like this:





You can schedule this script on a VM that runs on another cluster or maybe better, schedule the script on a physical box. If you want to know how to schedule a Powershell/CLI script, go check out this post from Alan Renouf: http://www.virtu-al.net/2009/07/10/running-a-powercli-scheduled-task/

Now you are able to track the most important VMs in your environment.

vCenter 4.0 and SQL 2008 as a Database server


Last week I had to install a vCenter 4.0 server with a database on a SQL 2008 x64 server. Before you can connect to the SQL 2008 x64 you have to install the new SQL server 2008 Native client. You can find it here:

Download and install the package:


In my earlier post about how to create an ODBC connection to use with vCenter 4 on a x64 version of Windows 2008. You already read about the “special” way of starting the ODBC data Source Administrator. Start it via: Start –Run – %systemdrive%\Windows\SysWoW64\Odbcad32.exe. The next step is to select the new Native Client version 10.0

The rest of the stuff is still the same 😉

vSphere: False alarms on high VM Memory usage in vCenter 4.0


Since the upgrade to vCenter 4.0 and ESX 4.0 we got a lot of false alarms on VM memory usage. If you take a look in the advanced performance tab, at VM level. You’ll see that the VM is using all the assigned memory. When you take a look on the host OS, you’ll see that there is less memory usage then vCenter reports to you. I asked on Twitter if anyone else had seen this behavior before. @DuncanYB responded with a post, which he did earlier this year.  

So with the information from @DuncanYB I started a search at http://kb.vmware.com/ and found the following KB article: http://kb.vmware.com/kb/1014019. This article describes one of the symptoms that apply on our environment:

Summaries and Symptoms

Issues fixed in this patch (and their relevant symptoms, if applicable) include:

  • Fixes an issue where a guest operating system’s memory usage might be overestimated on Intel systems that support EPT technology or AMD systems that support RVI technology. This issue might cause the memory alarms in vCenter to go off spuriously even if the guest is not actively accessing a lot of memory.
  • Fixes an issue where DVFilter API’s fail for particular message types during message reordering.
  • Fixes an issue where DVfilter socket reads might fail if zero bytes are returned due to a connection close.
  • Fixes an issue with a DVFilter API where ESX might fail if a guest operating system is moved from one vswitch port to another. This fix allows dropping frames which are accidentally or maliciously posted to a different portset.
  • Fixes an issue where incorrect SysAlert() messages might be displayed on certain systems if the number of cache colors is not calculated correctly.
  • Fixes an issue with monitor or vmkernel crashing when running certain guest operating systems with a 32-bit monitor running in binary translation mode.
Deployment Considerations

BEFORE INSTALLING THIS PATCH: If you have set Mem.AllocGuestLargePage to 0 to workaround the high memory usage issue detailed in the Summaries and Symptoms section, undo the workaround by setting Mem.AllocGuestLargePage to 1.

I installed the patch on a Cluster whit this problem. After the installation of the patch mentioned in the KB article above, vCenter keeps sending false alarms. After a short search on the vmtn communities I found the following post of Paul1

I go to the Top-Level in Vcenter, klick "Alarms" and than "Definitions". Edit one of the definitions (don’t change anything) and then save it. After this the old alarms was gone in my environment

After “changing” the VM Memory Alarm definition, vCenter stops sending out false alarms.

My vCenter Orchestrator Installation Notes


In this post I will share my vCenter Orchestrator Installation Notes.  For the people who doesn’t know what vCenter Orchestrator is, click on the next url: http://www.vmware.com

Before you can install the vCenter Orchestrator service, you have to configure a database first. For this job a created a script. You can use the following lines to create a database on SQL 2005 server:


EXEC sp_grantdbaccess [VCOUSER]
EXEC sp_addrolemember ‘db_owner’, [VCOUSER]
EXEC sp_addsrvrolemember [VCOUSER] ’sysadmin’

Joep has posted his installation notes here: http://www.virtuallifestyle.nl so I was curious about the product and wanted to see if I could install it. So with Joep his post as a reference I tried to install the product. I tried to find the vCenter Orchestartor Configuration service. But I could not find it.

After installation, open the Microsoft Services tool to enable the ‘VMware vCenter Orchestrator Configuration’ service. I recommend it to start every time the OS starts up, i.e. ‘Automatic’. Start it manually as well to start working with Orchestrator immediately

So I mounted the vCenter 4 cd-rom and installed the vCenter Orchestrator via:



When the installation is finished, open Services.msc and check if the vCenter VMware vCenter Orchestrator Configuration is started. If this is not the case, set the service to start automatic and start the service.  When the vCenter Orchestrator Configuration service is started, Start the vCenter Orchestrator Web Configuration service.

Now it’s time to configure the vCenter Orchestrator. Open a browser and go to http://vco-server:8282. Login with the default credentials: username vmware and password vmware.orchestrator_3

Change the default password. Go to General and press on the tab Change Password:


Click on Network to configure network settings. Select the IP Address of your vCenter server.


Click on Database to configure your database. Configure the Database connection settings and press install database. Click on Apply changes.


The rest of the setup can you read in Joep his post: http://www.virtuallifestyle.nl

VMware: Remove Snapshot stuck at 95%


This morning a woke up and grabbed my BlackBerry to see if there was any news (mail / twitter). The first e-mail I read was one from our monitoring system that one of the VM’s did not respond anymore. So I started a remote session and logged on to vCenter. There I saw a running task which was running since last night :-S.


These are the steps I took to solve this issue:

  1. Connect to the ESX Host via SSH.
  2. Run this command Service mgmt-vmware restart to restart the service
  3. If the VM is still okay then you don’ t have to restart the ESX Host, otherwise restart the ESX Host.
  4. Open the snapshot manager of the VM and create a new snapshot
  5. Now delete all snapshots
  6. Poweron the VM


I want to thank @Depping, @diederikm, @laurensdekoning and @sanderdaems for pointing me in the right direction.