WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Adventures with HP SAM and Win2008 R2 domains

06.07.2010 by William Lam // Leave a Comment

For the past two years or so we have been testing out VDI in our residence hall student labs at UCSB which consist of about twenty or so thin clients split between two locations. Now what made all of this feasible was:

1) Advancements in remote display protocols
and
2) our ghetto-link-clones script (http://communities.vmware.com/docs/DOC-9020)

We picked HP's RGS as our remote display protocol because it was the only protocol we found at the time that ensured a "rich desktop user experience". I still prefer it today over the software implementation of PCoIP but that is a topic best left for another day.

Naturally, the only broker that pooled RGS-enabled machines at the time was HP's Session Allocation Manager (today Leostream and others can broker it). Despite bad experiences with some HP software in the past, SAM actually worked out very well for us, both on the server side as well as the client side. I still have yet to see a broker package that allows you to customize the client like HP SAM (this feature is definitely stamped as RAD in my book).

SAM was not perfect though and had the occasional hiccup (e.g. machines being listed as unavailable, annoying but only occurred once in a while and was remedied with a resync operation) until the day came: management decided to upgrade the domain from Win2k3R-something to Win2k8R2. SAM completely stopped working; it was an interesting situation to say the least.

After some testing (with profanity and throwing of objects included), we of course determined that the fault was in SAM (3.0, the latest release at the time in early January did not work). HP's response? No official timeframe to release a fix. This equated to a week of scrambling around looking for competing and "compatible" products (ala Leostream) which just ended up complicating things. The solution? An aggravating night biking back and fourth between the two labs switching the entire VDI environment over to View. Whatever it takes right?

So long story short, if you have an existing HP SAM installation that is running on a pre-Win2k8R2 domain, make sure you update to the latest revision of SAM (3.01) that was just released a couple weeks ago before migrating your domain to Win2k8R2.

For a short description of our VDI environment, please refer to:
http://communities.vmware.com/docs/DOC-9201

Categories // Uncategorized Tags // Uncategorized

Script - hostops-lamw.pl

06.06.2010 by William Lam // 1 Comment

I recently noticed a question on the ESXi forum about trying to add a host to a vCenter server that had the "SSL host certificate verification" enabled while using the vSphere SDK for Perl Utility hostops.pl on vMA. The user encountered the following error when trying to add the host:

Error:
SOAP Fault:
-----------
Fault string: Authenticity of the host's SSL certificate is not verified.
Fault detail: SSLVerifyFault

The SSL host verification is a feature that came with the release of vSphere that provides a security measure to verify the validity of a host before adding it to your VMware infrastructure. This feature is disabled by default, but when it is enabled, a user will need to accept a dialog box to confirm the SHA1 thumbprint of the host in question.

This particular use case was not handled properly by hostops.pl which caused the error message to be thrown. With a small tweak to VMware's canned script, the new and improved hostops-lamw.pl now supports adding an ESX or ESXi host into vCenter with SSL host verification enabled. You'll still be expected to verify the SHA1 thumbprint, but now you can pass this as an additional parameter which will tell vCenter that you have verified the host and add to vCenter management.

Scott Lowe originally wrote an article on how to verify the SHA1 thumbprint for both an ESX and ESXi host.

On ESX you can run the following:

openssl x509 -sha1 -in /etc/vmware/ssl/rui.crt -noout
-fingerprint

On ESXi, the only real way to verify is by looking at the DCUI's "View Support Information":

However, if you truly trust the ESX or ESXi host that you're going to add to vCenter, there is an alternative way of retrieving the SHA1 thumbprint using the vCLI's vifs and the modified hostops-lamw.pl.

By default, you'll be able to point your web browser to https://[hostname]/host/ssl_cert to see actual SSL certificate on your host, assuming this functionality is not disabled. What you can do is download the ssl_cert to vMA or system with vCLI installed and query for the SHA1 hash and provide that as input to hostops-lamw.pl.

Download: hostops-lamw.pl

Step 1. Download hostops-lamw.pl to either vMA or system running vCLI copy it to the following path:

vMA or Linux host /usr/lib/vmware-cli/apps/host
Windows C:\Program Files\VMware\VMware vSphere CLI\Perl\apps\host

Step 2. Download the ssl_cert to vMA:

[vi-admin@scofield ~]$ vifs --server esxi4-1.primp-industries.com --username root --get "/host/ssl_cert" esxi4-1.primp-industries.com-ssl_cert
Enter password:

Downloaded file to esxi4-1.primp-industries.com-ssl_cert successfully.

Step 3. Get the SHA1 thumbprint from the ssl_cert you downloaded:

[vi-admin@scofield ~]$ openssl x509 -sha1 -in esxi4-1.primp-industries.com-ssl_cert -noout -fingerprint
SHA1 Fingerprint=79:BB:39:09:F6:E5:91:BD:B0:C3:F3:09:B4:38:50:FB:ED:9C:53:A5

Step 4. Use the modified hostops-lamw.pl and the new --sslthumbprint providing the SHA1 thumbprint (remember to double quote it) along with the other required input to add the host to vCenter:

[vi-admin@scofield ~]$ ./hostops-lamw.pl --server reflex.primp-industries.com --username primp --operation addhost --target_host esxi4-1.primp-industries.com --target_username root --target_password 'password' --sslthumbprint "79:BB:39:09:F6:E5:91:BD:B0:C3:F3:09:B4:38:50:FB:ED:9C:53:A5" --cluster virtual-cluster
Host 'esxi4-1.primp-industries.com' added successfully

Categories // Uncategorized Tags // ESX 4.0, perl, sha1

Script - ipmiConfig.pl

06.03.2010 by William Lam // 1 Comment

There was a question on the VMTN community asking about automating the configuration of IPMI/iLO Settings for Power Management via kickstart. Unfortunately, this cannot be configured directly on an ESX/ESXi host, it requires vCenter server. This configuration is a prerequisite to VMware's DPM (Distributed Power Management) which is only available with vCenter and DRS enabled cluster.

Although this configuration can't be added to kickstart, you can create a script that is executed as part of the "post configurations". Before starting, make sure that you have IPMI enabled over LAN which is generally found within your iDRAC/iLO or other out-of-band management console.

Here are two posts on popular hardware (Dell/HP) for configuring IPMI/iLO settings:

Dell configuration
HP configuration

In general, the actual configuration for the host is the same but will differ based on the server vendor and out-of-band management console.

Here is a vSphere SDK for Perl script that allows you to configure IPMI/iLO settings for an ESX or ESXi host:

Download: ipmiConfig.pl

You'll need to provide the following variables:

  • vihost = ESX or ESXi host
  • ipaddress = IP Address of your iDRAC/iLO/etc.
  • macaddress = MAC Address of your iDRAC/iLO/etc. interface
  • bmcusername = Username to login to your iDRAC/iLO/etc.
  • bmcpassword = You'll be prompted to provide the password

Here is an example run:

[vi-admin@scofield ~]$ ./ipmiSettings.pl --server reflex.primp-industries.com --username primp --vihost dev-esxi1.primp-industries.com --ipaddress 172.50.0.45 --macaddress 00:22:E8:71:C5:47 --bmcusername admin
Please enter your BMC Password:

Trying to configure IPMI/iLO Settings for Power Management on dev-esxi1.primp-industries.com ...

If you've entered everything correctly, the prompt should return right away. If it sits there for more than 20 seconds, then something went wrong and you may have entered something incorrectly. Due to the limitation of this API method, no tasks are returned back to properly handle these errors. You may want to manually configure this via the vSphere Client to double check your settings before re-using the script.


Here is an example of a bad run (entered wrong username + password):

[vi-admin@scofield ~]$ ./ipmiSettings.pl --server reflex.primp-industries.com --username primp --vihost dev-esxi1.primp-industries.com --ipaddress 172.50.0.45 --macaddress 00:22:E8:71:C5:47 --bmcusername root
Please enter your BMC Password:

Trying to configure IPMI/iLO Settings for Power Management on dev-esxi1.primp-industries.com ...

Error: Unable to configure IPMI/iLO Settings: SOAP request error - possibly a protocol issue: 500 SSL read timeout:

Categories // Uncategorized Tags // dpm, ESX 4.0, ipmi, perl, sdk

  • « Previous Page
  • 1
  • …
  • 65
  • 66
  • 67
  • 68
  • 69
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025