Enterprise Admins.org

I was recently working in a lab environment trying to register the vCenter Operations 5.6 virtual appliance into a vCenter Virtual Appliance environment. As a standard practice I like to issue CA signed certificates to everything — even in a lab environment — so I’ll know what to expect in production.

Even after replacing the SSL certificate (here are some instructions on that process: http://www.bussink.ch/?p=458) you’ll still get an SSL warning because the plugin is registered by IP address instead of DNS name. There is another great article here: http://www.vstable.com/2012/04/02/vcenter-operations-5-x-vcenter-plugin-uses-ip-instead-of-dns-hostname/ that includes a two step process to resolve the warnings.

Step 1 is easy and very straight forward…you use vi or some other text editor to update a file on the UI virtual appliance. The second step is a little more challenging because I’m working with the vCenter Virtual Appliance and the embedded database, making the required database changes a bit tougher. Since the article described where to find this value in the Managed Object Browser, I figured I could find and update it from PowerCLI.

$exMgr = Get-View ExtensionManager
$vcops = $exMgr.ExtensionList | ?{$_.key -eq 'com.vmware.vcops'}
$vcops.Server[0].Url = "https://vcops-ui/vcops-vsphere/viClientConfig.xml"
$exMgr.UpdateExtension($vcops)

This code is fairly straightforward.
Line 1: Use Get-View to connect to the ExtensionManager where vSphere plugins are registered.
Line 2: Find the vCOps plugin and make a copy of all the properties to a variable called $vcops.
Line 3: Update only the Server URL to use a name instead of an IP address
Line 4: Use the ExtensionManager connection from line 1 to write the updated $vcops extension back to vCenter

A refresh of the MOB shows that this updated value is immediately available — even without a restart of the vCenter Service.

I recently received several existing ESX hosts to support. As part of the transition I received the root password used by all of the hosts. I wanted to verify that the password I had was correct, so I threw together a quick script. You may notice below that the password had a dollar sign in it, which as you may know is a special character in powershell so it needed to be escaped with a back tick.

$esxHosts = "esxi01.test.local","esxi02.test.local"
$esxHosts += "esxi03.test.local","esx04.test.local"
$esxHosts += "esx05.test.local","esxi06.test.local"

$esxHosts |%{
  $hostName = $_
  $connection = Connect-Viserver $_ -user root -password "pa`$`$w0rd" -ea:0
  New-Object PSObject -Property @{
    Name=$hostName
    IsConnected=$connection.IsConnected
    VMCount = (Get-VM).Count
  }#end psobject
  Disconnect-viserver * -confirm:$false
}#end host loop

A few months ago I noticed a link to this awesome article titled: NAA id’s and breaking them apart, which dissects the NAA identifiers that you see in the vSphere client when looking at storage devices. Recently I was working with my storage admin — I was seeing a 2.81MB device on all of the hosts in a cluster that he had not specifically presented. Unfortunately I had no good way to tell him exactly which device I was seeing. I then remembered and found this article and was able to convert the NAA ID to the VMAX device ID using the key described in the article. While converting this device ID by hand, I thought…wouldn’t it be nice if I could just paste in the NAA ID and automatically convert it to the device ID? I threw together a quick powershell function that does just that:

Function Convert-NaaIdToVmaxDeviceId ($naa) {
  # http://vmwise.com/2012/06/01/naa-ids-and-breaking-them-apart/
  if ($naa.length -ne 36) { "NAA value must be 36 characters"; break }
  $deviceString = $naa.ToCharArray()
  $device = [char][Convert]::ToInt32("$($deviceString[26])$($deviceString[27])", 16)
  $device += [char][Convert]::ToInt32("$($deviceString[28])$($deviceString[29])", 16)
  $device += [char][Convert]::ToInt32("$($deviceString[30])$($deviceString[31])", 16)
  $device += [char][Convert]::ToInt32("$($deviceString[32])$($deviceString[33])", 16)
  $device += [char][Convert]::ToInt32("$($deviceString[34])$($deviceString[35])", 16)
  return $device
}

The function expects just one parameter and can be used like this:

Convert-NaaIdToVmaxDeviceId "naa.60000970000000000000533031363641"

About a month ago I experienced a production outage that related to improper removal of storage from a cluster. In this scenario, VMFS file systems were deleted from FC devices and then the FC devices were removed from the hosts. I’ve seen this done hundreds of times without issue, but as a best practice the devices should be detached from the host before they are removed. Here are some articles that discuss proper removal:

• http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-501-storage-guide.pdf (page 126)
• http://kb.vmware.com/kb/2004605

Manually detaching devices from a bunch of hosts doesn’t sound like a fun to me, so I created a quick script to help:

#These are the temporary LUNs
$removeThese = @()
Get-Datastore *Temp |%{
$removeThese += $_.ExtensionData.info.Vmfs.Extent[0].diskName
}

#Manually delete file systems, then run the following:

Get-VMHost esxi0* | %{
  $vmHost = $_
  $vmHost.name
  $removeThese | %{
    $esxcli = Get-EsxCli -VMHost $vmHost
    $esxcli.storage.core.device.set("$_",$null,$null,"off")
  }#end device loop
}#end host loop

Note: This code only works with ESXi 5.0 or later. I recently tested on an ESXi 4.1 host and this code does not work. (In 4.1 Get-EsxCli doesn’t have a storage.core namespace)