Using the NSX API to Check the Status of a Firewall Rule Publish Action
Well, that title sure is a mouthful! But, it's also what this post is all about, so let's get to it! One of my customers was experiencing an issue where it was taking longer than expected for an NSX firewall rule publish to propagate to all of their ESXi hosts. While troubleshooting the core issue, they needed a way to get better visibility into the process so that they'd know when their publishes had succeeded. That data was not available in the GUI, but after asking a few friends at VMware, we learned that we could get to it through the API by a simple command: GET /api/4.0/firewall/globalroot-0/status. Those are the facts that we collected, so here's what we did with them!
First, I knew that one of my customers had done some work with the NSX API, so I asked him for some advice. He pointed me at one of Mark Wahl's articles and gave me an excellent framework to build on.
I used that NSX API framework to send the GET command that we'd collected, which gave me back a bunch of XML that I had to parse through. Fortunately, XML is really easy to work with in PowerShell, so I just cast it as an XML object and went to work. After poking around in the XML for a bit, I found that I only really cared about a few bits of data, which were buried deep in nested arrays: hostName, Status, and generationNumber. So, I used Select to extract those fields from the XML file and had a nice report that showed which generation numbers each ESXi host was on and their current status.
Of course, what I really needed to know was which (if any) ESXi hosts were still publishing and were using older versions than expected. So, the script gets the current generation number from the NSX manager, then checks the generation number of each ESXi host. If any are not using that number, it reports them (and their current numbers) along with some yellow warning text. If everything is using that generation, then it spits out some green text and the whole table (so that a curious admin can look it over). I used write-host vs. just returning the contents of an array so that you can capture the script's output in a variable and just get the inventory, and the green or yellow text will go to the host console and not mess up your pristine data =)
First, I knew that one of my customers had done some work with the NSX API, so I asked him for some advice. He pointed me at one of Mark Wahl's articles and gave me an excellent framework to build on.
I used that NSX API framework to send the GET command that we'd collected, which gave me back a bunch of XML that I had to parse through. Fortunately, XML is really easy to work with in PowerShell, so I just cast it as an XML object and went to work. After poking around in the XML for a bit, I found that I only really cared about a few bits of data, which were buried deep in nested arrays: hostName, Status, and generationNumber. So, I used Select to extract those fields from the XML file and had a nice report that showed which generation numbers each ESXi host was on and their current status.
Of course, what I really needed to know was which (if any) ESXi hosts were still publishing and were using older versions than expected. So, the script gets the current generation number from the NSX manager, then checks the generation number of each ESXi host. If any are not using that number, it reports them (and their current numbers) along with some yellow warning text. If everything is using that generation, then it spits out some green text and the whole table (so that a curious admin can look it over). I used write-host vs. just returning the contents of an array so that you can capture the script's output in a variable and just get the inventory, and the green or yellow text will go to the host console and not mess up your pristine data =)
Comments
Post a Comment
Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,