how to

How to use PoSH or PowerCLI to SSH into Devices & retrieve information (Gathering SHA1 Fingerprints)

by

 

I was listening to GetScripting podcast #29 the other day. The guest was Pete Rossi (PoSH Pete), and in the discussion he discussed data centre automation. Part of the automation he has set up involves wrapping SSH with PowerShell, and by doing so he is able to automate various functions on devices that can be SSH’d onto. This got me thinking of potential use cases. Soon enough I already had a couple of use case scenarios that could do with automating using SSH and PowerCLI. Pete mentioned he mainly uses an SSH component by a company called “WeOnlyDo Software”, however Alan Renouf also mentioned having heard of “SharpSSH”. I decided I wanted to try both out and figure out how to use both, so with that I set out figuring out how to get them working with PowerShell and PowerCLI. In this post (Part 1) I will cover using the SharpSSH DLL. In Part 2 I will go into the (easier in my opinion) wodSSH component (also paid for) method.

 

SharpSSH (based on Tamir Gal’s .NET library)

 

I believe Tamir Gal originally created this library, however it seems to now be maintained by others.

 

First of all, for SharpSSH to work with PowerShell or PowerCLI, you’ll need to get the relevant DLL that will be loaded by your script. I found a version of SharpSSH being actively worked on and improved by Matt Wagner on Bitbucket. I downloaded this version (called SharpSSH.a7de40d119c7.dll) to get started. To load the functions that we’ll be using to SSH in to devices, I used the following PowerShell function. Just be sure to reference in the correct path of the SharpSSH DLL that you downloaded above in this function. Download the function below:

 

[download id=”13″]

 

Then as long as the functions are loaded in your PoSH session, you should be able to run the example below.

 

How to SSH into ESXi hosts and retrieve SHA1 Fingerprints using PowerCLI and SharpSSH

 

Example output after running the script detailed below against multiple ESX hosts

 

 

Now, first off I’ll say that this isn’t necessarily the best way of retrieving SSL Fingerprints from your ESXi hosts in terms of security – you’d want to do this from the DCUI of the ESXi hosts to confirm the identity of each host is as you expect. (See this blog post and comments over at Scott Lowe’s blog for more detail on the security considerations). With that being said, here is my implementation of SharpSSH, used to SSH into each ESXi host (from a Get-VMHost call) and retrieve the SHA1 Fingerprints. The script will create and output a table report, listing each ESX/ESXi host as well as their SHA1 Fingerprint signatures.

 

Background for the Script

 

I believe this is actually quite an easy bit of info to collect using PowerCLI and the ExtensionData.Config properties on newer hosts / vSphere 5, but in my environment I was working with, all my ESX 4.0 update 4 hosts did not contain this Fingerprint info in their ExtensionData sections when queried with PowerCLI. Therefore I automated the process using SSH as I could use the command “openssl x509 -sha1 -in /etc/vmware/ssl/rui.crt -noout -fingerprint” to generate the Fingerprint remotely on each host via SSH. So with that in mind, here is the script that fetches this info. Note it will prompt for root credentials on each host that is connected to – this could probably be easily changed in the Function (downloaded from above). So here is the final script which will list all ESXi hosts and their SHA1 Fingerprints:

 

$Report = @()
$VMHosts = Get-VMHost | Sort Name

foreach ($vmhost in $VMHosts) {
	New-SshSession root $vmhost
	if (Receive-SSH '#')
	{
		Write-Host "Logged in as root." -ForegroundColor Green
		$a = Invoke-SSH "openssl x509 -sha1 -in /etc/vmware/ssl/rui.crt -noout -fingerprint" 'SHA1'
		$temp = $a | select-string -pattern "SHA1 Fingerprint="
		$row = New-Object -TypeName PSObject -Property @{
			SHA1 = $temp
			HostName = $vmhost
		}
		$Report += $row
		$rootlogin = $true
		Write-Host "Output complete." -ForegroundColor Green
	}
	if ($rootlogin -eq $true)
	{
		Write-Host "Exiting SSH session."
		Send-SSH exit
	}
	Write-Host "Terminating Session."
	Remove-SshSession
}

$Report

 

Well, I hope this helps you out with a way to automate SSH access to devices to retrieve information or change settings. This could easily be adapted to send SSH commands to any other kind of device that accepts SSH as a method of login. Switches, Routers, linux servers, you name it! In my next blog post I will be showing you how to use the wodSSH library (We Only Do Software) to do SSH in PowerShell or PowerCLI – I have found this method to be a bit easier to use when compared with SharpSSH! So look out for my next post coming soon!

Generating Graphical Charts with VMware PowerCLI & PowerShell

by

Charts are awesome – they can help make sense of endless reams of text and data and they generally look pretty. So my question to myself was: “How do I get useful data I generate using PowerCLI into a nice, neat little chart?” I had a quick google and found a couple of different solutions. The one that stood out as being the easiest to start off with for me was to use the “Microsoft Chart Controls for Microsoft .NET Framework 3.5”

I read a few blog posts around detailing how to create these custom .NET charts in PowerShell, but this tends to be quite a tedious process – akin to creating a Windows Forms GUI in PowerShell manually – basically a complete pain. The blog posts I read definitely helped me understand how to create charts and soon I was able to generate some pretty cool charts based off data from PowerCLI (or PowerShell) data. I wanted to ultimately automate the creation of Charts for my PowerCLI and PowerShell scripts, so I decided to create myself a Function that could be used anywhere to generate a Bar or Pie Chart on the fly.

httpv://youtube.com/watch?v=EvQ2znWr0lk

Enter Create-Chart. This is the Function I have made that accepts a bunch of Parameters to create a custom Chart and outputs this to a .PNG file. The data needs to be fed in to the function via a Hash Table (this could be changed) so I also created a “helper” Function called Create-HashTable which also does the work of generating a hash table for use with the Create-Chart Function. You could of course also just feed the Create-Chart function with a manually created HashTable too – this is useful to know because my Create-HashTable function is fairly basic and is not too flexible. Here are a couple of examples of Charts I created using these Functions:

Pie Chart of VMs and their configured Memory Resource settings
The same data but now in a Bar chart
Host Chart created with a manually created Hash Table (Name and MemoryUsageMB Properties)

Download the two functions below to give them a try! Please do suggest any improvements – my parameter handling on the Create-Chart script needs work – they are not specified as mandatory, although all parameters are mandatory – I couldn’t get the Function to work correctly when I did make them mandatory. The Create-HashTable function could also be improved in that at the moment you can only specify Cmdlets for the “Cmdlet” parameter that do not have any double quotation marks inside the cmdlet or any $_ variables. This is because of the way I am using the Invoke-Expression cmdlet inside the function. A simple cmdlet parameter such as “Get-VM | Select Name, MemoryMB” would work just fine for example. Remember that the Create-Chart function needs to be fed with a Hash Table. This could be generated yourself, or by using the Create-HashTable function below. Here are the downloads:

Don’t forget the Microsoft Chart Controls – a requirement to run these functions
Download the functions here:

https://www.shogan.co.uk/wp-content/uploads/Create-Chart.zip

https://www.shogan.co.uk/wp-content/uploads/Create-HashTable.zip

Once you have the Functions loaded, here are some examples to show you how to use them:

Pie Chart of VMs and their MemoryMB setting:

Create-Chart -ChartType Pie -ChartTitle "Sean's Awesome VM Chart" -FileName seanchart3 -XAxisName "VMs" -YAxisName "MemoryMB" -ChartWidth 750 -ChartHeight 650 -DataHashTable (Create-HashTable -Cmdlet "Get-VM" -NameProperty Name -ValueProperty MemoryMB)

Bar Chart of ESXi Hosts and their Memory Usage (MB) values:

Create-Chart -ChartType Bar -ChartTitle "Sean's Awesome Host Chart" -FileName seanchart4 -XAxisName "VM Hosts" -YAxisName "Memory Usage (MB)" -ChartWidth 750 -ChartHeight 650 -DataHashTable (Create-HashTable -Cmdlet "Get-VMHost" -NameProperty Name -ValueProperty MemoryUsageMB)

Use your own Hash Table to input the data:

Create-Chart -ChartType Bar -ChartTitle "Custom Chart" -FileName seanchart5 -XAxisName "My Objects" -YAxisName "My Object Values" -ChartWidth 750 -ChartHeight 650 -DataHashTable $HashTable

So there you have it – a fairly easy way to Chart the data you can get from your PowerCLI or PowerShell cmdlets! I wrote these Functions as part of a larger report that I am working on for another soon to come blog post! As I mentioned above, there is plenty of room for improvement – so if you do make any improvements or changes, please be sure to post them in the comments section.

Create a custom Welcome Message / DCUI Splash screen for your ESXi Hosts with esxcli

by

 

Messing around with ESXCLI the other day I came across the commands to get / set the welcome message for your ESXi host. By default you are greeted with the following familiar splash screen for your ESXi hosts:

 

Standard DCUI Splash Screen / Welcome Message

 

Well, with esxcli, it turns out you can very easily change this to your own custom welcome message / splash screen. I personally don’t see any practical gains by doing this, but just thought I would show the command to set it. Using esxcli, enter the following (of course the bit between quotes is up to you):

 

esxcli system welcomemsg set -m="My Custom Welcome Screen. Press F2 to Customize System/View Logs or F12 to Shutdown/Restart."

 

 

To see what the current custom message is set to simply use the same command, but this time use “get” –

 

esxcli system welcomemsg get

 

Finally, to set it back to the default (No welcome message), simply set your welcome message to nothing –

 

esxcli system welcomemsg set -m=

 

Here is an example of a custom welcome message for an ESXi host in my lab I tested this with:

 

 

VMware Labs – iSCSI Shared Storage how-to using the HP P4000 LeftHand VSA [Part 2/2]

by

 

In the last post [Part 1/2], we prepared our VSA, created a management group and cluster in the CMC, and then initialized our disks. Next up, we’ll be creating a Volume which will be presented to our ESXi hosts as an iSCSI LUN. Before we do this though, we need to make sure our hosts can see this LUN. Therefore we’ll be making entries for each of our ESXi hosts using their iSCSI initiator names (IQNs).

 

Preparing your iSCSI Adapter

 

If your ESXi hosts don’t already have a dedicated iSCSI adapter you’ll need to use the VMware Software iSCSI adapter. By default this not enabled in ESXi 5.0. This is simple to fix – we just need to get it added. Select your first ESXi host in the Hosts & Clusters view of the vSphere Client, and click Configuration -> Storage Adapters -> Add -> Select “Add Software iSCSI Adapter”. Click OK to confirm.

 

 

Now we need to find the IQN of the iSCSI adapter. In the vSphere client, select the iSCSI adapter you are using and select Properties on it under Storage Adapters.  This will bring up the iSCSI Initiator Properties. Click the Configure button and copy the iSCSI Name (IQN) to your clipboard.

 

Getting the iSCSI adapter IQN using the vSphere Client

 

Quick tip: you can also fetch your iSCSI adapter information (including the IQN) using esxcli. Login to your host using the vMA appliance, the DCUI, or SSH for example and issue the following command, where “vmhba33” is the name of the adapter you want to fetch info on:

 

esxcli iscsi adapter get -A vmhba33

 

Getting the iSCSI adapter IQN using ESXCLI

 

Configuring a Server Cluster and the Server (Host) entries in the CMC

 

We’ll now create “Servers” in the HP CMC which are what we’ll be adding to our “SAN LUN” later on to allow our ESXi hosts access. In the CMC go to Servers and then click Tasks -> New Server Cluster. Give the Cluster a name and optional description, then click New Server. Enter the details of  each ESXi host (Click New Server for each host you have in your specific cluster). For each ESXi host, the Initiator Node Name is the iSCSI Name, or IQN we got from each ESXi host in the step above. The Controlling Server IP Address in each case should be the IP address of your vCenter Server. For this example we won’t be using CHAP authentication, so leave that at “CHAP not required”. Once all your ESXi hosts are added to the new cluster, click OK to finish.

 

Creating a new Server Cluster and adding each ESXi host and it's corresponding iSCSI Names/IQNs

 

Creating a new Volume and assigning access to our Hosts

 

Back in the CMC, with our disks that are now marked as Active we’ll now be able to create a shiny new Volume which is what we will be presenting to our ESXi hosts as an iSCSI LUN. Right-click “Volumes and Snapshots” and then select “Create New Volume”

 

 

Enter a Volume Name and Reported Size. You can also use the Advanced Tab to choose Full or Thin provisioning options, as well as Data Protection level (if you had more than one VSA running I believe).

 

 

Now we’ll need to assign servers to this Volume (We’ll be assigning our whole “Server Cluster” we created earlier to this Volume to ensure all our ESXi hosts get access to the volumen. Click Assign and Unassign Servers, then tick the box for your Server Cluster you created and ensure the Read/Write permission is selected. Then click OK

 

Assign the Server Cluster to the Volume for Read/Write access

 

Final setup and creating our Datastore with the vSphere Client

 

Go back to the vSphere client, go to one of your ESXi hosts, and bring up the Properties for your iSCSI adapter once again. We’ll now use “Add Send Target Server” under the Dynamic Discovery tab to add the IP address of the P4000 VSA. Click OK then Close once complete.

 

 

You should be prompted to Rescan the Host Bus Adapter at this stage. Click Yes and the Rescan will be begin. After the Scan is complete, you should see your new LUN is being presented as we’ll see a new device listed under your iSCSI Adapter (vmhba33 in my case for the Software iSCSI adapter).

 

New device found on the iSCSI Software adapter

 

Now that everything is prepared, it is a simple case of creating our VMFS datastore now from this LUN for our ESXi hosts to use for VM storage. Under Hosts & Clusters in the vSphere Client, go to Configuration, then Storage. Click Add Storage near the top right, and follow the wizard through. You should see the new LUN being presented from our VSA, so select that and enter the details of your new Datastore – Capacity, VMFS file system version and Datastore Name. Finish off the wizard and you are now finished. The new datastore is created, partitioned and ready to be accessed!

 

Add Storage Wizard

 

Complete - the new datastore is added

 

Well, that is all there is to it. To summarise, we have now achieved the following over the course of these two blog posts:

 

  • Installing and configuring the P4000 LeftHand VSA
  • Setting up the CMC
  • Creating a VSA Management Group
  • Creating a VSA Standard Cluster
  • Creating Servers entries in a new Server Cluster for each of our ESXi hosts to be presented the storage
  • Creating a LUN / Storage Volume
  • Configuring the ESXi hosts to find our VSA in the vSphere Client
  • Adding the Storage to our ESXi hosts and Creating our VMFS Datastore using the vSphere Client

 

To conclude, I hope this series has been helpful and that you are well on your way to setting up iSCSI shared storage for your VMware Cluster! As always, if you spot anything that needs adjusting, or have any comments, please feel free to add feedback in the comments section.

 

VMware Labs – iSCSI Shared Storage how-to using the HP P4000 LeftHand VSA [Part 1/2]

by

 

iSCSI Shared Storage for your Lab

 

I have had a few people asking how I set up my Shared iSCSI storage for my own VMware Lab environment I run at home – the same lab I used to study for my VCP 4 and VCP 5 exams. So, I thought I would write up a blog post detailing how to go about setting this up and trying it out for yourself.

 

You have NFS shared storeage up and running for your ESXi hosts in your lab, but what about iSCSI? There are many different options out there. Here are a few I can think of off the top of my head:

 

  • FreeNAS VM
  • OpenFiler VM
  • HP P4000 Lefthand VSA trial
  • Hardware based – for example Iomega StorCenter IX2 series or QNAP NAS device

 

The last two options (hardware based are less feasible for a lab environment as you ideally don’t want to pay for something you will be testing. That being said, I was quite keen on the HP P4000 LeftHand VSA, as it offers the same kind of interface that you would use with the actual hardware version as well as some really cool enterprise-like features, such as clustering. In fact, as I understand, many businesses actually use the P4000 VSA in production – it was in the game before VMware came out with their own Virtual shared storage solution. Both of these solutions actually provide highly available shared storage for your ESXi hosts. Anyway, enough of the small talk – lets get on to setting up some shared iSCSI storage for our ESXi hosts to use for running Virtual Machines.

 

Deciding where to run your P4000 VSA VM

 

First of all download the trial of the HP P4000 LeftHand VSA. Once you are signed up for the free trial, you should get two options – one version for “Laptops” and one for “ESX”. Grab the relevant version – I chose to run my VSA VMs directly in VMware Workstation 8 and allowed my ESXi VMs access to their storage. If you want to run your VSAs as VMs on your ESXi host VMs then grab the “ESX” version. Once you have it downloaded, extract the download into a convenient location. I wanted my VSA to run on faster disks in my home system, so I moved the extracted files to an SSD volume. Remember to take this into consideration for your lab too – VMs will be running on this, so plan your lab VM deployment and storage carefully. Once ready, simply right-click the VSA.vmx configuration file and select “Open with VMware Workstation”. (Or add to Inventory if you are using the ESX version and browsing the VSA with your Datastore Browser).

 

 

Configuration

 

Now that we have the VSA VM inventoried, we need to create some additional virtual disks for it to use (by default it just has a disk used for it’s OS). Right-click the VM and add some disks. There is one important thing you should note here – the disks should be added on SCSI devices 1:0 and onwards. I added 3 x Virtual Disks to my VSA. Note that a storage total of more than 500GB will require your VSA VM to have more than 768 RAM). I chose 3 x 80GB Virtual disks, meaning I would get a RAID5 160GB volume at the end of this exercise. I found out the hard way (troubleshooting a VSA that would not work) that your VSA needs around 1GB or more of RAM if you have more than 500GB of storage on it! Keep this figure under 500GB and you can get away with the default 384MB RAM which is ideal for a home lab. So here are the details I used for each Virtual Disk added (a total of 3 of these):

 

  • New Virtual Disk
  • SCSI (Recommended)
  • Mode -> (Independent) -> Persistent
  • Enter size of disk – for e.g. 80GB
  • Thin provisioned (Leave “Allocate all disk space now” unticked) – to save disk space on those SSDs especially!
  • Store Virtual Disk as a Single File
  • Specify Virtual Disk filename

 

Important: If you didn’t get an option to specify the Virtual Device Node, go back to “Advanced” on each disk and change to device node x, where x is Virtual Device Node SCSI 1:1 to 1:3. (a different node for each disk you added). If you do not specify these selections, then the VSA will not detect your disks or be able to use them.

 

Remeber to use these Virtual Device Nodes for each disk added.

 

Once your disks are added, ensure it is on the right VM network (I used bridged in Workstation for my lab), your network situation will of course vary. Then power up the VSA. Whilst it is powering up, we’ll need to get the HP P4000 Centralized Management Console installed on a “management” PC. In your VSA download you should have also received the installer for this. Simply run the installer and go through the wizard to get this installed.

 

P4000 Centralized Management Console Installer

 

Back to your VSA console, you should now be at the login prompt – type Start to login, then press Enter at the “Login” screen. We’ll now be presented with a menu:

 

 

Navigate to Network TCP/IP Settings and choose your eth0 adapter. Configure a hostname for your VSA – in my example I used “blogvsa.noobs.local”. Don’t forget to set your VSA up to have a static IP address and enter your network details. If you have a DNS server, now would be a good time to also add an A Name Record for your VSA’s hostname and assign it the IP address you configured it with. Accept the network changes for the VSA and wait for it to apply the new settings.

 

Hostname and Network configuration.

 

Now launch your HP P4000 Centralized Management Console from the machine you installed it on, and we’ll begin setting this VSA up. Once open, you should have a few options to the left, and hopefully, the CMC would have already found your new VSA on the network. If not, don’t stress – just use the menu option Find -> Find Systems -> Find. Once the VSA is discovered, you can then close the “Find” window and view the VSA under Available Systems.

 

Expand Available Systems and locate your newly powered up VSA.

 

Next, we’ll create a new Management Group and add the VSA to it. The group will exist on this VSA as it is our only storage system. Right click on the VSA and choose Add to New Management Group. Give the group a suitable name, then click Next. The next screen asks us to create an Administrative user. Enter the details for a new admin account and then click Next. Specify NTP server settings, or set the time manually then click Next. Set up your DNS Server and Domain Name on the next screen, then click Next. If you have an SMTP server to use for email alerts, enter those settings on the next screen, or continue. To keep things simple, on the “Create Cluster” page, select the default “Standard Cluster” option, continue, give it a name, then click Next. The next screen requires you to specify a Virtual IP for Fault Tolerance or load-balanced iSCSI access. Add an IP and the correct subnet mask then click Next. The next screen allows us to create a volume. We have not set up our disks and RAID yet, so check the option to “Skip Volume Creation” and we’ll come back to that afterwards. Finish the wizard and wait for it to create the Management Group and configure everything for you. Once complete, it should auto-login to the Management Group using the admin user you specified for you. Review the summary once complete and close the wizard.

 

Now, expand out your Storage Cluster under the new Management Group and find your VSA system. Select Storage and then click the Disk Setup tab. We’ll now initialize each disk that we added to the VSA earlier and add it to the RAID group for the VSA. Right-click each uninitialized disk and select “Add Disk to RAID“.

 

Add each uninitialized VSA disk to the RAID group.

 

This post is getting a little long now, so I’ll end off this post here with our VSA configured, the Management Group and Cluster set up, and our disks initialized. In the next post [part 2/2], we’ll create a new Volume with these disks and will be setting up our iSCSI initiators from our ESXi hosts as “Servers” in the CMC. After this, we will present the new Volume to our ESXi hosts as an iSCSI LUN and create our VMFS shared storage for vSphere to use. Stay tuned, as part 2 will be coming soon! (Hopefully tomorrow!) See below for the next section:

 

Edit – [part 2/2] is now up – finish off the article here.