I suppose easy is relative.

One of the comments to the post I made about touch free ESXi installs asked about testing without having to reboot and wait for the install process to load, and fail, to determine what went wrong. I did this testing by switching to a different console and using the Python interactive shell to load the same modules VMware uses, call their methods, and simply look at the values returned. By reading their code I was able to determine what the dialogs (the prompts presented to the admin during the install process) return, and the simply return that without the dialog occurring.

From the install screen you can switch to a different console (Alt+F1, if I recall correctly), and then access a command line (you may need to use the “unsupported” trick to get the command line).

The install process is actually quite interesting. VMware is booting, via ISOLINUX, into a full ESXi environment (instead of the standard ESXi yellow and black, they display the install dialogs), asking you which disk you want to use, then formatting that disk with VMFS and copying a virutal machine to the new VMFS volume. They then configure the boot partition to start the ESX kernel and start the ESXi management virtual machine. It’s rather interesting (well, to me) what they are able to accomplish because of the power and flexibility having such a small hypervisor affords them. Not to mention the sheer genius of using their own hypervisor to perform the install of itself…simplicity!

Continue Reading »

I’ve ran across this particular issue myself, and submitted a bug to the PowerCLI team, but shortly after Andrew posted his ESXi 4.0 autoinstall Tim asked about this very issue.  There is a documentation error in Example #5 from the Apply-VMHostProfile cmdlet help.  Which contains the following code example.

$profile = Get-VMHostProfile -Name testProfile            

$additionalConfiguration = Apply-VMHostProfile -ApplyOnly -Profile $profile -Entity 10.23.114.166
$additionalConfiguration['network.hostPortGroup["key-vim-profile-host-HostPortgroupProfile-VMkernel"].ipConfig.IpAddressPolicy.address'] = '10.0.0.128'
$additionalConfiguration['network.hostPortGroup["key-vim-profile-host-HostPortgroupProfile-VMkernel"].ipConfig.IpAddressPolicy.subnetmask'] = '255.255.255.0'            

Apply-VMHostProfile -ApplyOnly -Profile $profile -Entity 10.23.114.166 -Variable $additionalConfiguration

Sadly if you tried to execute the above you would get the following error.

PS > $additionalConfiguration['network.hostPortGroup["key-vim-profile-host-HostPortgroupProfile-VMkernel"].ipConfig.Ip
AddressPolicy.address'] =  "10.52.8.11"
Array assignment to [network.hostPortGrou ..] failed: Cannot convert   value "network.hostPortGroup["key-vim-profile-
host-HostPortgroupProfile-VMkernel"].ipConfig.IpAddressPolicy.address" to   type "System.Int32". Error: "Input string
was not in a correct format.".
At line:1 char:26
+ $additionalConfiguration[ <<<<  '"network.hostPortGroup["key-vim-profile-host-HostPortgroupProfile-VMkernel"].ipCo
nfig.IpAddressPolicy.address'] ='10.52.8.11'
   + CategoryInfo          : InvalidOperation: (10.52.8.11:String) [],   RuntimeException
   + FullyQualifiedErrorId : ArrayAssignmentFailed 

 

At first this may appear a little cryptic, but it get’s a lot clearer once we inspect the object types in use.

PS > $additionalConfiguration.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Object  

PS > $additionalConfiguration[0]

Name                           Value
----                           -----
network.hostPortGroup["key-...

PS > $additionalConfiguration[0].GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     DictionaryEntry                          System.ValueType

The example from the help docs was apparently expecting a Hashtable to be returned from apply-VMhostProfile.  Instead we found an array of DictionaryEntry objects... hence the error.

There are two possible work around's we can employ until the PowerCLI team ships a fix.  The first one is complicated, but dynamic.

$VMHostProfile = Get-VMHostProfile -Name testProfile            

$additionalConfiguration = Apply-VMHostProfile -ApplyOnly -Profile $VMHostProfile -Entity 10.23.114.166
($additionalConfiguration | Where-Object {$_.Name -eq 'network.hostPortGroup["key-vim-profile-host-HostPortgroupProfile-VMkernel"].ipConfig.IpAddressPolicy.address'}).Value = '10.0.0.128'
($additionalConfiguration | Where-Object {$_.Name -eq 'network.hostPortGroup["key-vim-profile-host-HostPortgroupProfile-VMkernel"].ipConfig.IpAddressPolicy.subnetmask'}).Value = '255.255.255.0'            

Apply-VMHostProfile -ApplyOnly -Profile $VMHostProfile -Entity 10.23.114.166 -Variable $additionalConfiguration

I actually don't like this approach even though it's a modified version of the included example.  I prefer just a simple static Hashtable.

$VMHostProfile = Get-VMHostProfile -Name testProfile            

$additionalConfiguration = @{
    'network.hostPortGroup["key-vim-profile-host-HostPortgroupProfile-VMkernel"].ipConfig.IpAddressPolicy.address'    = '10.0.0.128'
    'network.hostPortGroup["key-vim-profile-host-HostPortgroupProfile-VMkernel"].ipConfig.IpAddressPolicy.subnetmask' = '255.255.255.0'
}
Apply-VMHostProfile -ApplyOnly -Profile $VMHostProfile -Entity 10.23.114.166 -Variable $additionalConfiguration

All in all, the HostProfile cmdlets are surprisingly complete, and I think the majority of the "issues" I've ran across are a result of the SDK itself.  The Host Profiles sections of the API just don't have the same fit and finish I've come to expect in a VMware API.

I'm sure carter and team will have this fixed in the next release, untill then...

~Glenn