Skip to content

That... Could Be A Problem... Posts

PoSh – Finally Testing PernixData!

My home lab has been in need of some upgrades lately. One of the easiest, and cheapest, was the addition of PernixData and their FVP Freedom edition release.

Couple of caveats I feel I should cover if you’ve never been exposed to PernixData’s FVP product:

  • FVP, the normal offering, cannot activate a Freedom license.
  • FVP Freedom edition cannot be installed and used in trial mode.
  • FVP Freedom edition can only use RAM as an acceleration resource and requires a minimum of 4GB free per host.
  • FVP Freedom edition can only be used for read only acceleration (ie. write through mode).
  • FVP Freedom edition cannot be used with more than one cluster.

With that said, I ended up going with the regular FVP edition in trial mode because I don’t have an additional 4GB of RAM available. The install was extremely easy using SQL Express. vSphere Web client plugin installed to my VCSA instance properly and creating the first FVP Cluster was equally as easy. However this isn’t about the install and config, so let’s jump to the Powershell module!

First, if you’re on the management server, import the module:
Import-Module PrnxCli

If you don’t happen to be on the management server, you’ll want to copy/paste the “Program Files\PernixData\FVP Management Server\Client\PSModule” directory over to the desired system and then point the import cmdlet at the “PrnxCli.dll” file. Pointing the import cmdlet at the “PrnxCli.psd1” file produces an error stating it can’t find the nested modules:
import-module prnxcli.dll

Second, connect to the PernixData Management server:
($creds variable is the result of the Get-Credential function used to store credentials)
connect-prnxserver

Since I already setup an FVP cluster, lets explore an existing FVP cluster by the name of “Home”. The “Get-PrnxFVPClusterDetail” cmdlet shows all of the objects within the Home FVP cluster:
get-PrnxFVPClusterDetail

Displaying the current acceleration policy for a specific object via “Get-PrnxAccelerationPolicy” for the “probcosplx” VM:
Get-PrnxAccelerationPolicy

Some other cmdlets that can be used to explore the environment include: “Get-PrnxNFS”, “Get-PrnxScsiLUN”, “Get-PrnxVM”, and “Get-PrnxVMFS”. However if you’re in a smaller environment, you can get a sum of all of those cmdlets by running the “Get-PrnxObject” cmdlet. It’s also worth noting that all of the cmdlet responses have quite a bit more information under the covers such as auth level, support status, stats, policies, etc. Run the cmdlet with a ” | select *” to see the rest of the information being returned.
Get-PrnxObject

The last thing that we haven’t looked at in the exploratory phase would be statistics! Those are pulled by way of the “Get-PrnxObjectStats” cmdlet:
Get-PrnxObjectStats

Now that we have the exploration piece done, let’s modify an object to change their Acceleration Policy. This is accomplished by way of the “Set-PrnxAccelerationPolicy” cmdlet:
Set-PrnxAccelerationPolicy

Overall, it’s a pretty comprehensive module where anything you can do in the GUI can be done via Powershell. However there are some things, as minor as they are, that I wouldn’t mind seeing added to the module in a future release:

  • Get-PrnxAccelerationPolicy – Show the name of the object information is received about, auto-population of the “Type” parameter, and a better way to decipher if an object is accelerated or not (currently an un-accelerated object shows up with an empty FlashCluster but still shows a policy of “Write Through”)
  • Adding some functionality around piping output into new cmdlets.

Lastly, I figure I should show off some of the stats as they really are quite impressive. Here’s what FVP did for me in just 3 days in my home lab:
Awesome Pernix Stats

PowerCLI 6.0 R2 – Announcing vROps Integration!

For those that have been requesting some vCOps and/or vROps integration into PowerCLI, as I have been, we finally have our solution! PowerCLI 6.0 R2 brings that to the table in the form of a new module: VMware.VimAutomation.vROps

The following functions are featured in the module:
Connect-OMServer
Disconnect-OMServer
Get-OMAlert
Get-OMAlertDefinition
Get-OMAlertSubType
Get-OMAlertType
Get-OMRecommendation
Get-OMResource
Get-OMStat
Get-OMStatKey
Set-OMAlert

Here’s a couple tips to get started using it:
To begin pulling stats you will need to authenticate to the vROps instance via Connect-OMServer:
Connect-OMServer

After getting connected, and being connected to an associated vCenter, check out the resources via Get-OMResource by piping it a VMHost, VM, or so forth:
get-omresource

As you can see, I pulled the resources for a VMHost. Some of the basic, higher level, information is in there such as Health status and value, whether or not vROps is receiving any data about it, and how far back data has been collecting for the resource.

The following is pulling the same information for the vROps VM in my lab environment:
get-omresource

If you want to go straight to the stats, I don’t blame you one bit. However just running the Get-OMStat command is going to fill your PoSh window with every single stat available for that resource at all the time points available. Overwhelming would be putting it lightly, so you’ll want to also familiarize yourself with Get-OMStatKey. This function allows you to see what all stats you can actually pull:
get-omstatkey

Couple things I feel the need to point out:

  • Include both the AdapterKind and ResourceKind objects when calling this function, it returns every possible stat key possible without it… All 17,646 of them.
  • Even when including the AdapterKind and ResourceKind, I would highly recommend filtering out what what you’re looking for. The HostSystem ResourceKind has 2225 stat keys alone.

Finally, lets select a stat key and pull some detailed stats by way of the Get-OMStat function. In this scenario, I’m pulling CPU Ready Summation values:
Get-OMStat

Some of the other functions included surround alerting.

The Get-OMAlert function pulls all of the vROps alerts:
get-omalert

Since there happens to be some alerts, let’s check out two abilities of the Set-OMAlert function. The first option being cancelling of an alert:
set-omalert -Cancel

If you notice in the example, the alert still exists but it’s status is changed to “Inactive”.

Next up, let’s check out the suspend function of the Set-OMAlert function:
Set-OMAlert -SuspendMinutes

Overall, the new module definitely gets my stamp of approval! Thanks to the Automation and PowerCLI team for listening to the users and getting this integrated!

Additional information is available at the following link: https://blogs.vmware.com/PowerCLI/2015/09/powercli-6-0-release-2-is-now-generally-available.html

PoSh – Gathering VMware NSX Info via API

I’ve been lucky enough to get a chance to do some work involving VMware’s NSX product lately. Having watched a bunch of VMworld sessions, live demos and messed around with it in the VMware Hands on Labs I was fairly comfortable in an existing environment. However I’ve gotten fairly used to using Powershell to do most of my work and there doesn’t appear to be much out there in the way of cmdlets or functions.

Chris Wahl has some really good resources regarding using Powershell to do API calls with NSX to both gather controller information (Creating NSX API Calls with PowerShell – Wahl Network) and create/remove virtual network tiers (Leveraging PowerShell to Deploy Virtual Network Tiers with VMware NSX – Wahl Network).

Thanks to Chris’ first post, I’ve taken what he created and built out a couple additional functions and even dumped them all into module form.

An overview of what’s currently included in the module:

Function Name Description
Get-NSXController Will inventory all of your controllers from NSX Manager
Get-NSXController
Get-NSXEdges Will inventory all of your Edge Nodes from NSX Manager
Get-NSXEdges
Get-NSXEdgeFeatures Will inventory all of your Edge Nodes’ Features from NSX Manager
Get-NSXEdgeFeatures
Get-NSXEdgeInterfaces Will inventory the selected Edge Node’s Interfaces from NSX Manager
Get-NSXEdgeInterfaces
Get-NSXEdgeNats Will inventory all of your Edge Node’s NATs from NSX Manager
Get-NSXEdgeNATs
Get-NSXEdgeRoutingOverview Will inventory all of your Edge Nodes’ Routing Overview details from NSX Manager
Get-NSXEdgeRoutingOverview
Get-NSXUplinks Will inventory all of your Edge Nodes’ Uplinks from NSX Manager
Get-NSXEdgeUplinks

A general walk-through of what’s occurring within each function is Powershell using the Invoke-WebRequest cmdlet against the NSX Manager’s REST API and formatting what’s returned into an easy to consume format that is a similar match to what’s returned back by way of the “Networking and Security” plugin.

Requirements:
Powershell 3.0 or better: Invoke-WebRequest first appeared in Powershell version 3.0, so anything less won’t work.
NSX Manager Admin credentials: All of the information is being pulled directly from the NSX Manager
Import the module by way of the .psd1 file: while not really a requirement, it certainly helps with the formatting of the output

Example of how the formatting is handled, first with the .psd1 file then with the .psm1 file:
Loading NSX PSD1 vs PSM1

Link to the GitHub repo location: https://github.com/kmruddy/Powershell/tree/master/Modules/NSXModule

An automated way of downloading the files into a dedicated directory and importing the module into the current session:

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

vSphere SSO – Removal of Additional Application Users

Have you ever logged into the vSphere Web Client and received a warning like this:
Could not connect to one or more vCenter Server systems

This “Could not connect to one or more vCenter Server systems” error means the web client cannot talk to vCenter server. In this case, the server having the error was decommissioned and no longer exists.

To resolve this issue, head into the “Administration” area of the web client. Follow that by going to the “Single Sign-On” area and select “Users and Groups”. From there, hit the “Application Users” tab and take a look at the users. In this case there were a total of three vCenters and their associated Inventory Services:
Application Users

While in the above screen, take note of the last 6 characters of each user.

Prior to removing any of those user account it’s time to verify those user accounts against the services still in existence. This information is hidden a bit, so some digging is required.

For the vCenterServer Service account, look for the “solutionUser” section of the following file: C:\ProgramData\VMware\VMware VirtualCenter\vpxd.cfg
DecomvCenter03

For the InventoryService account, again, look for the “solutionUser” section of the following file: C:\Program Files\VMware\Infrastructure\Inventory Service\lib\server\config\dataservice.properties
Inventory Service User Account

Once the user account information has been gathered, head back to the “Application Users” section and remove the accounts that were not able to be verified:
Remove vCenterServer Account
Remove InventoryService Account

Once removed, log out of the vSphere web client and log back in and the error message will no longer be displayed across the top of the screen.

PoSh – HP iLO – Configuring the iLO Hostname

If you’ve had any chance to use the HP Scripting Tools for Powershell at all you might have noticed some inconsistencies specific to the handling of server names. These issues are only made worse when combined with blade enclosures.

The biggest example to illustrate this is by using the get-hpiloservername cmdlet:
Get-HPiLOServerName Output

Now by going to the login screen of the iLO Management page we see:
HP iLO Management Page

Since this is a blade, let’s also see what the Onboard Administrator (OA) Device Bay Summary page says:
HP OA Output

According to the get-hpiloservername output the standard name should be updated to match that everywhere else. The setting in the GUI that we’re looking for is the “iLO Subsystem Name (Host Name)” which is located by way of the Network –> iLO Dedicated Network Port –> General tab area:
iLO Subsystem Name

Instead of reverse engineering the HP module, there’s a workaround available by way of the set-hpilonetworksetting, specifically the DNSName parameter. An example:
Set-HPiLONetworkSetting -Server '10.10.10.10' -DNSName 'newserver10' -Credentials (Get-Credential)

One big thing to note, this command does perform a reset against the iLO so if you’re connected to the iLO you will be kicked out and greeted by the following message:
iLO Reset

After the iLO finishes being reset, you can refresh the page and see the newly configured name:
HP iLO Management Page

Then returning to the OA Device Summary page:
HP OA Output

The next logical question is how to automate this process… That’s easy enough!

Let’s check out a section of IPs that are not yet configured with the get-hpilonetworksetting cmdlet:
iLO Hostname Output

Before we run the script, there are some assumptions this script makes:

  • You have the HP Scripting Tools for Powershell modules already installed.
  • You’re running Powershell version 4.0. That’s a requirement for the resolve-dnsname cmdlet to work.
  • DNS entries have already been made and are resolvable.
  • The login credentials are the same for all the iLO systems.

Making sure those bases are all covered it’s time to run the script:

Script output will appear similar to the following: (Note the differences in output)
Script Output

After giving it a minute or two for the iLO resets to be performed, we’ll check out the names again:
iLO Hostname Output

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

PowerCLI – View – Pool Health Check Report

I’ve been given the chance to work with View a little more here recently and focus in on some of the gaps that are missing, specifically around reporting and alerting. vC Ops and the View adapter are in use, however the alerts leave much to be desired. I’m glad to be able to say that the gaps are filled in with the new version, and new title, of vR Ops and the View adapter but this environment is not yet to that point.

Examples of the vR Ops alerts which are included by default:

vR Ops Default View Alerts

What gaps am I referring to? I’m aiming specifically at the View Pool state, provisioning state and the amount of available desktops compared to the headroom configuration.

To do this, I enlisted the help of the View PowerCLI cmdlets and the View Connection server ADAM database to create the script below that creates an output similar to this:
(Note: the asterics around the value that caused the report to be sent)

View Pool Report Output

Before getting to the script, lets cover some of the requirements of the script:

  • This script is to be run from a Connection server.
  • This script is currently formatted to have the report be consumed by way of email.
  • The email variables need to be filled in to match the environment it’s being run in.
  • The email is sent only if the following criteria are met:
    • A Pool’s state is false.
    • A Pool’s provisioning state is false.
    • A Pool’s available desktops are less than the headroom setting by the amount set in the desktopthreshold variable.
  • The default desktop threshold is meant to be a percentage and is set to a default of 90%, or 0.9. This is easily modified on line 22.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

PowerCLI – Automate the vROps OVA Deployment

For those that haven’t heard, vCenter Operations (known better as vC Ops) has been not only updated but renamed. It’s new name is vRealize Operations (or, probably, vR Ops) and it is officially version 6.0. Previously the system was deployed in a vApp containing a UI VM and an Analytics VM. The new systems incorporates a roles for the VMs such as Master, Master Replica, Data and Remote Collecter.

However, this blog post isn’t to focus on what’s been updated. It’s to take a look at making the deployment a little easier since most installs will have at least two nodes. If you would like some further information on the update, please check out VMware’s website: http://www.vmware.com/products/vrealize-operations

After running the script below, you’ll find an output similar to the following:

vROps-Deploy

Before getting to the script, lets cover some of the assumptions and requirements made in the script:

  • The OVA has already been downloaded and is placed somewhere available to the system running the script. (Example: local disk, SMB or DFS share, etc.)
  • The VM is being placed in a resource pool.
  • The local system is able to successfully run and resolve the VM name via Resolve-DnsName cmdlet which is available in PowerShell v4.
  • The subnet being used is a /24 or 255.255.255.0. This is easily modified on line 126.
  • The VLAN ID is based on the third octet of the system’s IP address. This information is set on line 128 and the portgroup is set on line 133.
  • The gateway ends with ‘.254’. This is easily modified on line 129.
  • DNS should be modified to match your environment which is based on line 130.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

PowerCLI – Gathering VMHost NIC Driver & Firmware Info

There’s nothing worse than having inconsistencies in a VMware cluster. This includes patch level, driver level and definitely firmware levels. In this particular case, the focus is on the physical network adapters. Unfortunately there’s no real easy to pull this directly from the vmhost and network related PowerCLI cmdlets, however you can still use PowerCLI to pull this information by way of the get-esxcli cmdlet.

After running the script below, you’ll find an output similar to the following:

Script Output

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

PowerCLI – Process of Adding Notes to VMs

Documentation is a good thing. No matter how big or small. One of the easiest methods of documentation is to use the built in annotation section for “Notes”.

Annotation Notes

What I’ve come up with is a fairly basic script to go through all the VM objects that do not contain notes and allow the user to insert notes on a line by line basis. Here’s an example:

Running the script

Here’s the script to accomplish it:

If a one-liner is more your speed, give this one a go… Note: you’ll have to specify your own cluster, if that’s a desired use.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.

View – Using Powershell to Check ADAM Replication Status

Recently ran into some issues where replication on the View ADAM database wasn’t going too well. Instead of checking the replication status by RDPing into each View Connection and running the repadmin command, I created a Powershell script to do it for me. This script also helped with verification due to being able to report all the Connection servers’ status within a single window.

Only item to note: you will have to prepopulate the script with the desired Connection servers

I also converted the above into a little more automated script that’s usable only from one of the Connection servers, thanks to how the View API ties into PowerCLI…

Items to note:

  • This has to be run through the View PowerCLI module, which only works on Connection servers.
  • It’s designed to be run as a one liner.
  • It will report back the replication status on all the Connection servers involved in that particular View environment.

Note: this was a script that worked in my environment. There is no warranty or support with this script, please use at your own risk.