• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

virtuallyGhetto

  • About
  • Privacy
  • VMware Cloud
  • Home Lab
  • Nested Virtualization
  • Automation
    • VMware Kickstart
    • VMware API/SDK/CLI
    • VMware vMA/VIMA
    • VMware OVF / OVFTOOL
  • Apple Mac
  • VCSA
  • VSAN

perl

New vSAN Management 6.6 API / SDKs / CLIs

04/18/2017 by William Lam 2 Comments

With all the new awesome capabilities that have been introduced in vSAN 6.6, there is just as much Automation goodness that will be available for our customers to consume to help them easily mange and operate at scale.

vSAN Management 6.6 API

Below are all the new Managed Objects that have been introduced in the new vSAN Management 6.6 API. This does not even cover all the new methods or object types. For the complete list of vSAN 6.6 APIs, be sure to check out the vSAN Management 6.6 API Reference Guide here.

  • VsanVcsaDeployerSystem – Virtual Center Service Appliance deployment APIs onto vSAN datastore, operating at both vCenter Server and ESXi Host sides
  • VsanVdsSystem – vSAN system optimized VDS related operations, especially migrations from VSS to VDS
  • VsanUpdateManager – VIB installation engine operating at vSAN cluster level (optimized for vSAN clusters)
  • VsanCapabilitySystem – APIs to query vSAN capability, available on both vCenter and ESXi
  • VsanMassCollector – vSAN system management query API's to access data and managed object properties, operating at a vSAN Cluster level in vCenter Server only
  • VsanPhoneHomeSystem – vSAN online health related query API, operating at a vSAN Cluster level in vCenter Server only

[Read more...] about New vSAN Management 6.6 API / SDKs / CLIs

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, PowerCLI, VSAN, vSphere 6.5 Tagged With: java, perl, PowerCLI, python, ruby, sdk, VSAN 6.6, vSphere 6.5

Monitoring vCenter SSO User Account Expiration

01/29/2013 by William Lam 2 Comments

Did you know that user accounts created in the vCenter SSO Server automatically expire by default after 365 days? If you do not update your password prior to the expiration date, in about a years time you could potentially be locked out of your vCenter SSO Server which also applies to the [email protected] account.

You can change the default password expiration policy by logging into the vSphere Web Client with an SSO Administrator account. Under the configuration section of "Sign-On and Discovery", there is a Password Policies tab that allows you can modify password policies. By default, this is set to 365 days. I would also recommend that after you have installed and setup your vCenter SSO Server, you add at least one user or group from your directory service such as Active Directory and assign it to the SSO Administrator group. This will ensure that you can still log in to the SSO configuration in the event the local SSO user accounts are locked out.

Even though you can change the password expiration policy, there is still no automated notification or alerting built-in for user accounts that are going to expire. The best you can do is to create a calendar event to remind you update your passwords prior to the expiration date. I am sure that many of you are anxious to add another color event to your already busy schedule 🙂

While investigating alternative options a few weeks back, the only method that I have found to retrieve the status for each SSO user is to directly connect to the vCenter SSO Database. There are two specific tables of interest, one which provides the current password policy and the other providing the last password changed date for each SSO user:

  • ims_authn_password_policy
  • ims_principal_data

Disclaimer: This "may" not be officially supported by VMware.

Instead of having you manually dig around in the SSO Database, I have created a Perl script called getSSOUserExpiration.pl which can connect to either a MSSQL or vPostgress backend SSO database. The script which will automatically list out the current password policy as well as user accounts that will be expiring in N days, where N is input provided by the user. You also have the ability to configure the script to automatically email you the results which is nice for a daily or weekly report and can be setup using a cronjob or a scheduled task. There are several configuration variables that will need to be adjusted based on your environment and these are all located within the script itself. For more details on how to setup and use the script, please take a look at the Setup and Configuration section below.

Note: To reduce any negative impact to the vCenter SSO Database, you should add or ask your DBA's to create a limited read-only account and limit access to the following tables above. You may even be able to have your DBA's create a scheduled routine for the specific queries and have that emailed to you internally.

Here is a screenshot of connecting to a vPostgres backend Database:

Here is a screenshot of connecting to a MSSQL backend database:

Here is a screenshot of what the email report looks like:

Note: The email body should contain the specific vCenter SSO Database, but I am not sure why it is not showing up in Gmail, but it does work for other email clients.

Setup and Configuration

vPostgres

To connect to a vPostgres DB, you will need to install the following two perl packages: perl-DBI and perl-DBD-Pg. In this example, I am using the vMA appliance and the zypper package installer. For more details on how to add a SLES repo, please take a look at the following article. I also assume if you are connecting to a vPostgres DB, then you are using the VCSA (vCenter Server Appliance) and by default it does not accept remote connections. We will need to also make two configuration changes to the VCSA for our script to be able to connect to the database.

Step 1 - Run the following two commands to install both perl packages:

sudo zypper in perl-DBI
sudo zypper in perl-DBD-Pg

Step 2 - SSH into your VCSA and in the following configuration file /storage/db/vpostgres/pg_hba.conf you will need to add the network in which you will be connecting from:

host    all             all             172.30.0.0/24           trust

Step 3 - SSH into your VCSA and in the following configuration file /storage/db/vpostgres/postgresql.conf you will need to add the IP Address(s) that you want vPostgres to listen for remote connection. If you use "*", it will allow all addressees:

listen_addresses = '*'

Step 4 - For the changes to go into effect, you will need to restart the vPostgres DB by running the following command:

service vmware-vpostgres restart

Step 5 - Modify the getSSOUserExpiration.pl script and provide the credentials to your vCenter SSO DB. If you need help in identifying the vCenter SSO DB credentials, please refer to this article for the details.

MSSQL

To connect to an MSSQL DB, there are a few additional steps and packages that will be required. We will be using FreeTDS which provides libraries to connect to an MSSQL DB for UNIX/Linux platforms. There was a bit of trial and error in getting the MSSQL solution working and I would like to thank Reuben Stump for his assistance. The following article was used as a reference for the setup below.

Step 1 - Run the following two commands to install the required packages:

sudo zypper in perl-DBI
sudo zypper in gcc

Step 2 - Download and extract the contents of the FreeTDS package:

wget ftp://ftp.astron.com/pub/freetds/stable/freetds-stable.tgz
tar -zxvf freetds-stable.tgz
cd freetds-0.91

Step 3 - Compile and install FreeTDS under /usr/local/freetds:

export SYBASE=/usr/local/freetds/
./configure --prefix=/usr/local/freetds
make
sudo make install

Step 4 - Add your vCenter SSO Server details into the FreeTDS configuration file located in /usr/local/freetds/etc/freetds.conf

[sso]
host = 172.30.0.239
port = 1433
tds version = 7.0

In the example above, I named my database entry "sso" but you can use any name and this will be referenced when editing the script in step 5.

Step 5 - Modify the getSSOUserExpiration.pl script and provide the credentials to your vCenter SSO DB.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, Security, vSphere, vSphere 5.5, vSphere 6.0 Tagged With: expiration, perl, sso, ssodb, vpostgres, vSphere 5.1

Extracting Information from VIN (vSphere Infrastructure Navigator) Part 2

11/08/2012 by William Lam 2 Comments

In my previous article Extracting Information from VIN (vSphere Infrastructure Navigator) Part 1, we took a look at the data VIN was collecting through an interface called Jolokia. Utilizing a tool called j4psh, we were able to easily view and explore the data in VIN remotely. In this article, we will take a look at how easily you can extract the data we explored in the previous article using a very simple script.

While going through the Jolokia website and walking through the tutorial, I found there were several programmatic clients that could be used to connect to the Jolokia service which includes Java, Javascript and Perl. Since I am most familiar with Perl, I wrote a very simple Perl script called getVINData.pl leveraging the information from my previous article.

Disclaimer: This is not officially supported by VMware, use at your own risk.

Before using the script, you will need to run through the two per-requisites outlined in the previous blog article: VIN appliance setup and installation of Jmx4Perl. Once you have completed these two steps, you are now ready to execute the script (make sure the script has the executable permission set). The script is pretty straight forward it accepts two input parameter: VIN hostname/IP Address and the name of the virtual machine you wish to query.

In the example below, I am connecting to my VIN host which has an IP Address of 172.30.0.150 and I am querying a virtual machine with the name Analytics VM (one of the vC Ops VMs).

From the screenshot above we can see the following:

  • The vCenter Server that VIN is currently registered to
  • VM Summary information
  • Applications/Services currently running on the VM
  • VM Dependencies

If we take a look at the vSphere Web Client and the VIN data for this particular VM, we should see the same set information:

Though the script already contains quite a bit of information, it is just a sample of what can be done. With further exploration you can easily extend the script to extract other pieces of information and possibly even use other scripting/programming languages to connect to this interface. As I mentioned before, VIN is a very powerful tool for your vSphere infrastructure and now you can gain additional benefits by leveraging it's valuable data externally!

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Uncategorized Tagged With: infrastructure navigator, jmx, jmx4perl, jolokia, notsupported, perl, vIN

Script – Configure VM Disk Shares (vmDiskSharesMgmt.pl)

07/07/2010 by William Lam 3 Comments

I recently received an email about automating the configuration of VM disk shares. I thought it was an interesting request since I do not know how many people actually make use of this feature. By default, the shares on a virtual disk is set to "normal" or 1000 shares. You can change the value between low (500), normal (1000), high (2000) or a custom value. The following script helps a user to perform a bulk update across multiple VMs and supports multiple virtual disks.

Download: vmDiskSharesMgmt.pl

The script requires that you connect to your vCenter server and provide the following input parameters:

--diskshares_file = Is the name of the diskshares input file that contains the names of the VMs, the hard disks and their corresponding shares value which can be (low, normal, high or custom)

Here is an example of the diskshares input file:

[[email protected] ~]$ cat diskshares.txt
# [VMNAME];[HDX,SHARES_VALUE]=[HDY,SHARES_VALUE]=[HDZ,SHARES_VALUES]
#
# SHARES_VALUE = low, normal, high, XXXX (custom)
#
# e.g.
# myvm;hd1,low=hd2,high=hd3=2001
#
Synapse;hd1,high
Imager;hd1,low=hd2,1500=hd3,2500=hd4,high
William-XP;hd1,3000

In the above example, we have the following VMs and configurations to be set:

Synapse
Hard Disk1 = high (2000)

Imager
Hard Disk1 = low (500)
Hard Disk2 = 1500
Hard Disk3 = 2500
Hard Disk4 = high (2000)

William-XP
Hard Disk1 = 3000

Here is an example execution:

Here we verify one of the VMs "Imager" and it's configured disk shares:

Hopefully you will find this script to be useful

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation Tagged With: perl, sdk, shares

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:

[[email protected] ~]$ 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:

[[email protected] ~]$ 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:

[[email protected] ~]$ ./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

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Uncategorized Tagged With: esx4, esxi4, perl, sha1

Script – Updated vSphere Health Check 4.0.8

06/05/2010 by William Lam Leave a Comment

Check the latest update to popular vSphere Health Check Script which has now gone to v4.0.8!

One new change that you'll notice is the two additional menu options at the top of the report when you running the report against a vCenter server.

VPX Settings - All configured vCenter settings

VMware/3rd Party Applications - Display any registered VMware/3rd party applications running within a VM

For a list of other changes, please take a look at the vSphere Health Check Script change log.

Give the new script a try and let me know if have any problems or would like to see other features included in a future release.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Uncategorized Tagged With: health check script, perl, vSphere

  • Go to page 1
  • Go to page 2
  • Go to Next Page »

Primary Sidebar

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Services Business Unit (CSBU) at VMware. He focuses on Automation, Integration and Operation for the VMware Cloud Software Defined Datacenters (SDDC)

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Sponsors

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