vSphere: vCenter shows VMName (Invalid)

After some issues with a NFS share I noticed that a couple of VM’s changed to Invalid. The VM was still fully operational but vCenter didn’t recognized the VM’s anymore.


I found the following knowledge base article: http://kb.vmware.com/kb/1015778 which describes the following symptoms:

•Virtual machines display as invalid in vCenter Server
•The command service mgmt-vmware restart fails to stop the management agent
•The command vmware-cmd -l returns the error:

PANIC: SyncWaitQ: The system limit on the total number of open files has been reached

•The command ps -auxwww shows a large amount of SSHD processes running

In my case the solution was to restart the management agent on the host where the VM’s where running on.

PowerCLI: Set CPU Identification Mask


Today I received a question in my mailbox about setting the CPU Identification Mask on Multiple VM’s. The guy who asked the question wanted to set the following values:


So I started to search on the VMware Communities and I found the following function.

# Mask SSE 4.1 Extensions to the guest.
function Mask-Extensions($vm) {
    $view = get-view $vm.id

    $vmConfigSpec = new-object VMware.Vim.VirtualMachineConfigSpec
    $featureMask = new-object VMware.Vim.VirtualMachineCpuIdInfoSpec
    $featureMask.info = new-object VMware.Vim.HostCpuIdInfo

    $featureMask.info.ecx = "---- ---- ---- 0--- ---- ---- ---- ----"
    $featureMask.info.level = 1

    $vmConfigSpec.CpuFeatureMask = $featureMask


I changed it a little bit, so it matches the required settings (see picture above):

function Mask-Extensions($vm) {

    $view = get-view $vm.id
    write-host "Setting Mask for: "$vm.Name

    $vmConfigSpec = new-object VMware.Vim.VirtualMachineConfigSpec
    $featureMask = new-object VMware.Vim.VirtualMachineCpuIdInfoSpec
    $featureMask.info = new-object VMware.Vim.HostCpuIdInfo
    $featureMask.info.eax = "-----------------------------000"
    $featureMask.info.level = 0

    $vmConfigSpec.CpuFeatureMask = $featureMask


If you want to run this function against one VM, You can run the following command:

Mask-Extensions (get-vm "My VM")

You can also use this function in the pipeline:

get-vm | % {Mask-Extensions ($_)}


Source: http://communities.vmware.com/message/960123#960123

PowerCLI: Set Custom Fields


Last week I posted a script to add Notes to a VM. After posting this script there was a little discussion on Twitter with @vmdoug, @gabvirtualworld if the Notes field is the right field to add this kind of information. So @vmdoug introduced me to the world of Custom Fields.

So I changed my CSV file and added the Field entry. This Field entry will be de name of your custom field. In my case I called it Description.

DC01,Description,Domain Controller
VC01,Description,vCenter Server

The following one-liner will fix this for you:

"D:\*.csv" | % { Get-VM $_.VMName |
Set-CustomField -Name $_.Field -Value $_.Note -Confirm:$false }

After running the script you will see the Description field with a new entry:


This one-liner will run very slow on a Large environment. So if you have large environment you should definitely check out LucD post on Alan Renouf’s Blog:  http://www.virtu-al.net

PowerCLI: Add Notes To Multiple VM’s


My colleague asked me to add some notes to the VM’s so he knows what this VM is doing. So this is a nice job for PowerCLI 🙂 . In this post you will see how powerful PowerCLI /Powershell is.  With only one line of code (one-liner),  you are able to achieve this job.

First you have to create a CSV file with the following entry’s:

VM1,Domain Controller
VM2,Database Server

The second step is to run this one-liner. The one-liner will add the Notes:

Import-Csv "D:\*.csv" | % { Set-VM $_.VMName -Description $_.Note -Confirm:$false}

When the one-liner is ready, you will find the Notes in the vSphere Client:


Note: This script will overwrite the existing Notes, so use it at your own risk!

PowerCLI: Set VM Startup Policy


Update: I added a little script block which enables the Startup Policy on the ESX Host.

If you want to change the VM Startup Order under Configuration – Virtual Machine Startup/Shutdown by hand will costs you a lot of time. So I wanted to see if I was able to script these settings with PowerCLI.

You can check the Startup Order via:  Get-VMHost |Get-VMStartPolicy |Sort StartOrder

And this is how you can see if the Startup Policy is enabled: Get-VMHostStartPolicy              -VMHost ( Get-VMHost )


First, I created a CSV file:







In this CSV file, I have entered my VM’s and the startup order value. I have tested it with multiple servers and it’s possible to enter two VM’s with the same StartupOrder value if the VM’s are placed on different ESX Hosts.

The following script imports the CSV file and loops through all the items and configures the VM Startup Policy:

$vCenter = Read-Host "Enter the vCenter server name"

Connect-VIServer $vCenter

$hosts = Get-VMHostStartPolicy -VMHost (Get-VMHost)
$vms = "c:\scripts\ps\vmsStartup.csv"
$csv = Import-CSV $vms

foreach($item in $csv){
    $vm = $item.VMName
    $order = $item.StartupOrder

    $vmStartup = Get-VMStartPolicy -VM $vm
    Set-VMStartPolicy -StartPolicy $vmStartup `
        -StartAction PowerOn -StartOrder $order 


foreach($esx in $hosts){
    Set-VMHostStartPolicy -VMHostStartPolicy $esx -Enabled:$true

Disconnect-VIServer -Confirm:$false


I created a short movie about the script in action:

VI-Toolkit: Enable PXE boot for all VM’s in a particular folder

The following script enables PXE boot for al the VM’s in a particular folder. After running this script, the VM’s are set to boot only from PXE, so all other options are disabled. The original part of the script is created by LucD and posted on de VMTN forums. See the source for more information.


$VC = Connect-VIServer (Read-Host "Enter vCenter server") 

$folder = (Read-Host "Enter folder name") 

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.extraConfig += New-Object VMware.Vim.OptionValue
$spec.extraConfig[0].key = "bios.bootDeviceClasses"
$spec.extraConfig[0].value = "allow:net"

    $vms = Get-Folder -Name $folder | Get-VM
        foreach ($vm in $vms){
            (get-view ($vm).ID).ReconfigVM_Task($spec)}

Disconnect-VIServer -Confirm:$False

The script in action:image

If you want to return to the default settings, you can run the next script:


$VC = Connect-VIServer (Read-Host "Enter vCenter server") 

$folder = (Read-Host "Enter folder name") 

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.extraConfig += New-Object VMware.Vim.OptionValue
$spec.extraConfig[0].key = "bios.bootDeviceClasses"
$spec.extraConfig[0].value = "allow:hd,cd,fd"

    $vms = Get-Folder -Name $folder | Get-VM
        foreach ($vm in $vms){
            (get-view ($vm).ID).ReconfigVM_Task($spec)}

Disconnect-VIServer -Confirm:$False

Source: LucD @ http://communities.vmware.com/thread/196651

VMware: VMname_2 na het opnieuw registreren van een VM

Het kan zijn dat je een VM, om wat voor reden dan ook, uit de vCenter inventory hebt verwijderd. Dit kun je doen via de Remove from Inventory optie.


Als je na deze actie, gelijk weer een VM registreerd met dezelfde naam, dan zie je het volgende verschijnen in je Datastore.


Om deze actie voor te blijven, kun je het beste na de Remove from Inventory actie, eerst de vCenter service restarten.

Dit kun je als volgt doen: Op de vCenter server open je de commandpromt en voer je het volgende commando uit om de vCenter service te stoppen:

net stop “VMware VirtualCenter Server”

Vervolgens start je de service weer:

net start “VMware VirtualCenter Server”

Als je nu weer een VM registreert, met dezelfde naam, dan zal deze actie geen nieuwe vmname_2 folder aanmaken.

VMware: The attemped operation cannot be performed


Tijdens de migratie naar ESX 3.5u3 (ik draaide nog ESX 3.02 met een uptime van 553 dagen :-)) Wilde ik de VM’s verplaatsen via een VMotion. Dit ging goed op een VM na. Deze VMotion task stopte na 10% met een time-out foutmelding. Ik moest door met de migratie en had dus niet te tijd om dit grondig te onderzoeken. Ik heb de VM netjes afgesloten en daarna via een Cold Migration verplaatst. Dit ging allemaal goed totdat ik de VM weer wilde optstarten. De volgende foutmelding kwam naar voren:


Na wat zoeken op google kwam ik de volgende topic tegen:

In dit topic kwamen de volgende oplossingen naar voren:

Potentially, your VC client on esx server is having issue. I would restart both vmware-vpxa and mgmt-vmware service. If status of the VM would not still sync with VC then, I would think VM itself has an issue.

If this is the case, kill VMPID by performing following;

#this would return all running VMs vmid#
cat /proc/vmware/vm/*/names/

#lookup actual group id
less -S /proc/vmware/vm/(your vmid)/cpu/status

#kill vm with group id you got from above
/usr/lib/vmware/bin/vmkload_app -k 9 (yourgroupID)

1. Disconnected my esx server from virtualcenter
2. Closed VI Client
3. Restarted VirtualCenter (windows service)
4. Open VI Client and re-added my host.

Geen van de oplossingen was de oplossing voor mijn geval. Ik heb de VM uit de inventory van ESX gehaald. Vervolgens heb ik het VMX bestand verwijderd. Daarna heb ik de vCenter service opnieuw gestart en de VM opnieuw aangemaakt met de bestaande VMDK. De VM werkte daarna weer zoals het hoort.

VMware: ESX 3.5 Update 3 VM’s spontaneously reboot

Verschillende blogs melden deze bug al eerder. Bij deze plaats ik ook nog even een post.

Ivo schrijft het volgende op zijn blog: http://www.ivobeerens.nl

We disabled in HA the option “Virtual Machine Monitoring” and set DRS to manual.  The problem with Virtual Machine monitoring is:

The Virtual Machine heartbeats are being dropped which is triggered by VMotion and the VM gets reset by the HA feature as it thinks it has gone offline. Since the feature is now off it should be safe to turn on DRS again.

There are more people who have this problem, read the following post on the VMware forum, 3.5U3 – any guinea pigs yet?.

I made a support request @ VMware. The told me today that 20 November patch 10 for VMware 3.5 Update 3 will be released. Patch 10 fixes SOME random reboot problems in Update 3. I hope it resolves this nasty issue.


Bron: http://www.ivobeerens.nl/?p=180