Archive for April, 2012

Changing ESX Server root passwords using PowerCli

April 24th, 2012 No comments

It’s that time again where we need to change the passwords on all of of ESX(i) hosts. Of course, when your number of hosts becomes any more than a handful, this can be a rather arduous process.

I had a scratch around some old scripts and found this one :


$serverlist = read-host "Please provide the path to your list of ESX hosts"

# Get old root credential
$oldrootPassword = Read-Host "Enter old root password" -AsSecureString
$oldrootCredential = new-object -typename System.Management.Automation.PSCredential -argumentlist "root",$oldrootPassword

# Get new root credential
$newrootPassword = Read-Host "Enter new root password" -AsSecureString
$newrootCredential = new-object -typename System.Management.Automation.PSCredential -argumentlist "root",$newrootPassword
$newrootPassword2 = Read-Host "Retype new root password" -AsSecureString
$newrootCredential2 = new-object -typename System.Management.Automation.PSCredential -argumentlist "root",$newrootPassword2

# Compare passwords
If ($newrootCredential.GetNetworkCredential().Password -ceq $newrootCredential2.GetNetworkCredential().Password) {

# Create new root account object
$rootaccount = New-Object VMware.Vim.HostPosixAccountSpec
$ = "root"
$rootaccount.password = $newrootCredential.GetNetworkCredential().Password
$rootaccount.shellAccess = "/bin/bash"

# Get list of Host servers from textfile to change root password on
Get-Content $serverlist | %{
Connect-VIServer $_ -User root -Password $oldrootCredential.GetNetworkCredential().Password -ErrorAction SilentlyContinue -ErrorVariable ConnectError | Out-Null
If ($ConnectError -ne $Null) {
Write-Host "ERROR: Failed to connect to ESX server:" $_
Else {
$si = Get-View ServiceInstance
$acctMgr = Get-View -Id $si.content.accountManager
Write-Host "Root password successfully changed on" $_
Disconnect-VIServer -Confirm:$False | Out-Null
Else {
Write-Host "ERROR: New root passwords do not match. Exiting..."

I can’t remember where I got it from, but I am pretty sure it came off the VMware communities.

Of course, if you really wanted to, you get simply gather the list of ESX hosts from your VC and trawl through those using the same code – the only difference would be that you could delete the following

$serverlist = read-host "Please provide the path to your list of ESX hosts"

and replace

# Get list of Host servers from textfile to change root password on
Get-Content $serverlist | %{

with something like

Get-VMHost | %{$}

Happy days – use at own risk of course!

Categories: VMWare Tags:

Configuring VMware High Availability fails

April 24th, 2012 No comments

We had an interesting situation yesterday where we tried to add an ESX4.1 host to a cluster that had its vmkernel and Service Console ports on different VLANs to the existing cluster.

Configuring VMware High Availability fails with the error: Cannot complete the configuration of the HA agent on the host

which says:

This issue occurs if all the hosts in the cluster do not share the same service console or management network configurations. Some hosts may have service consoles using a different name or may have more service consoles than other hosts.
For example, this error may also occur if the VMkernel gateway settings are not the same across all hosts in the cluster. To reconfigure the setting, right-click on the hosts with this error and select Reconfigure for HA.
Address the network configuration differences between the hosts if you are going to use the Shut Down or Power Off isolation responses because these options trigger a VMware HA isolation in the event of Service Console or Management Network failures.
If you are using the Leave VM Powered on isolation response, the option to ignore these messages is available in VMware VirtualCenter 2.5 Update 3.
To configure VirtualCenter to ignore these messages, set the advanced option das.bypassNetCompatCheck to true:
Note: When using the das.bypassNetCompatCheck option, the heartbeat mechanism during configuration used in VirtualCenter 2.5 only pairs symmetric IP addresses within subnets across nodes. For example, in a two node cluster, if host A has vswif0 “Service Console” 10.10.1.x and vswif1 “Service Console 2” 10.10.5.x and host B has vswif0 “Service Console” 10.10.2.x and vswif1 “Service Console 2” 10.10.5.x, the heartbeats only happen on vswif1. Starting in vCenter Server 4.0, they can be paired across subnets if pings are allowed across the subnets. However, VMware recommends having them within subnets.
  1. Right-click the cluster, then click Edit Settings.
  2. Deselect Turn on VMware HA.
  3. Wait for all the hosts in the cluster to unconfigure HA.
  4. Right-click the cluster, and choose Edit Settings.
  5. Select Turn on Vmware HA, then select VMware HA from the left pane.
  6. Select Advanced options.
  7. Add the option das.bypassNetCompatCheck with the value True.
  8. Click OK on the Advanced Options screen, then click OK again to accept the cluster setting changes.
  9. Wait for all the ESX hosts in the cluster to reconfigure for HA.

We made the changes in a test environment, and tested and voila! problem solved.

Now I would not really advocate running  production environment using this, as a router / switch outage could cause false alerts, or even HA to be invoked – but for test environments that are sometimes not as ‘pretty’ as you’d like, It is worth considering using this to still be able to use/test  HA.

Categories: VMWare Tags:

vExpert 2012!

April 21st, 2012 No comments

I am very honored and very pleased to be awarded the VMware vExpert Award for the first time! Especially when I look at this list and notice names like Alaric, Renouf etc!!  -I really though that my chances were slim, as I have been too busy over the second half of this year to keep my usual levels of community interaction and contribution up and running.

Thanks to VMware for continuing this award. Also congratulations to all new vExperts 2012.

The VMware vExpert Award is given to individuals who have significantly contributed to the community of VMware users over the past year. vExperts are book authors, bloggers, VMUG leaders, tool builders, and other IT professionals who share their knowledge and passion with others. These vExperts have gone above and beyond their day jobs to share their technical expertise and communicate the value of VMware and virtualization to their colleagues and community.

Check out the official announcement and have a look at the complete list on :

Categories: VMWare Tags: