Automation: VxRail API PowerShell Modules to VxRail REST API Mapping: A Cartographer's Delight

Have you ever used the VxRail API PowerShell Modules Cmdlets and wondered what the corresponding VxRail REST API Endpoint path is? Have you ever used the VxRail REST API and wondered what the corresponding VxRail API PowerShell Modules Cmdlet is? The wait is over!

As an instructor who teaches VxRail related automation topics I am always researching APIs. Historically, I usually end up searching the VxRail onboard API documentation for the endpoint that matches the task I am trying to automate. A given Endpoint may be used by VxRail API PowerShell Modules, Ansible Modules for Dell EMC VxRail, or via the tool of your choice.  Once I’ve identified a suitable endpoint, I check a variety of details such as:

1. The Endpoint Path
2. The HTTP Method
3. Request/Response Body Schema if needed
4. Status Codes/Status Description
5. Is it a Synchronous or an Asynchronous request?
6. Is Authorization needed?

Below is an example of the VxRail onboard API documentation as presented by Stoplight (the interactive API) in VxRail version 7.0.350 and higher. The VxRail onboard API documentation for your VxRail can be accessed at https:// /rest/vxm/api-doc.html . In my example, the goal is to collect VxRail Chassis details. Notice the Endpoint Path of “/v4/chassis” highlighted below:

Now that I know the basics, I can use the tool of my choice to execute the request whether it be the VxRail onboard API documentation or something else such as cURL, Postman, or my favorite tool/language.

Years ago, before the VxRail API PowerShell Modules evolved to the point where they are today, I would write my own PowerShell Modules with exported Advanced Functions (i.e.: Cmdlets) to automate RESTful API tasks. Over time the VxRail API PowerShell Modules grew to the point where they are today with nearly every VxRail REST API Endpoint having a comparable VxRail API PowerShell Modules Cmdlet. However, the mapping between the Cmdlet and the underlying Endpoint Path is not always obvious. VxRail API PowerShell Modules Cmdlets use the Invoke-RestMethod Web Cmdlet in the background.

So where might I find the Cmdlet for the “/v4/chassis” Endpoint Path and vice versa? For someone who bounces between a variety of VxRail automation tools, this can be a bit of a knowledge gap. Well, gaps need filling…

As a learning tool for students, and for ease of course development for myself, I made a PowerShell Advanced Function to do the dirty work for me. Basically, the function lists all Cmdlets exported by the VxRail API PowerShell Modules, their corresponding REST API Endpoint Paths, and supported API versions. The function crawls through all the *psm1 files associated with the VxRail API PowerShell Modules and then parses them to extract Cmdlet Names, Endpoint Paths, and API versions. It wasn’t pretty, but it worked. Notice the highlighted “Get-Chassis” Cmdlet which supports v1, v2, v3, and v4 of the API. Now I can easily toggle between different tools to perform comparable tasks and students can easily see the relationship between the Cmdlets and the RESTful API. Below is a partial listing to give you an idea of what the output looks like:

For convenience, at the end of this post, a PDF of VxRail API PowerShell Modules Cmdlets and their respective mapping to VxRail 7.0.400 endpoint paths is attached. Items should be independently verified. This is a personal project and not supported by Dell. 

Want to know more about the VxRail RESTful API and VxRail API PowerShell Modules?

1. Tech Exchange - Automation with VxRail API: Free Offering, 1 Hour, On-Demand
2. Automation on VxRail: 4 Hours, Instructor Lead, you’ll likely have Doug and I as your instructors!

Can’t get enough of my insufferable posts? Subscribe to VxRail Discussions!

Think I’m doing a borderline acceptable job? Kudos maybe in order!

Feel like commiserating, gimme a Me too!

Reply to add a compelling comment!

#NeedlessVxRailVerbosity