PowerCLI: RE: Disallowing Multiple VM Console Sessions

Frank Denneman posted today about disallowing multiple VM console session in a high-secure virtual infrastructure design: http://frankdenneman.nl/2010/11/disallowing-multiple-vm-console-sessions

The first thing popped up in my mind was why not automate this setting with PowerCLI. So I created a function called Set-MaxMKSConnections:

Function Set-MaxMKSConnections{
    [parameter(Mandatory = $true)]
    $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

       $extra = New-Object VMware.Vim.optionvalue
    $vmConfigSpec.extraconfig += $extra

        $vm = Get-VM $vmName | Get-View

You can run this function by copying the code into the PowerCLI window. To run it on a single VM, you can use the following line:

Set-MaxMKSConnections -vmName Thinapp -Sessions 1

To run it on all your VM’s, you can use the following foreach loop:

$vms = Get-VM
foreach($vm in $vms){
    Set-MaxMKSConnections -vmName $vm -Sessions 1

The configuration is changed even on Virtual Machines that are powered on (you need to restart the VM to activate the new setting):


If you want to raise the maxConnections value back to 2 or another value, you can change the –Sessions parameter with the correct value and run the script again.


PowerCLI: Add multiple values to a VMX file


@bjornbats asked me if I knew a way to add multiple values to a VMX file via PowerCLI. I remembered a blog post from Carter at http://blogs.vmware.com/vipowershell/ about this subject. So I tested the code and changed it a little bit. Now you can create a CSV file with the Keys and Values you want to change and the script will add them to the VMX file.

The CSV file I used looks like this:


The script below will add the entry’s from the CSV file to every VMX file, even when the VM is still running. I don’t know if you need to reboot the VM to apply the changes. So if someone can test that for me, please leave a comment with the results.

$vCenter = Read-Host "Enter your vCenter servername"
Connect-VIServer $vCenter

$import = Import-Csv "C:\Scripts\PS\vmxsettings.csv"

$vms = Get-View -ViewType VirtualMachine | where {-not $_.config.template}

$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

    foreach($item in $import){

        $extra = New-Object VMware.Vim.optionvalue
        $vmConfigSpec.extraconfig += $extra

    foreach($vm in $vms){


Disconnect-VIServer –Confirm:$false

When you start the script, you will notice that vCenter is very busy reconfiguring the virtual machines:


You will notice The operation is not… warning in the recent tasks window. This is because the Get-View -ViewType VirtualMachine will also add the Templates.

And here you can see the added lines into your VMX file:


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.