Virtually Jason

I've had the chance to work on some NSX-T scripting lately, as we work to integrate some other solutions with the tool.  I don't have a ton of experience with API access, but I have been slowly learning... and one of the big hurdles that I had to overcome was just figuring out how to authenticate with the system!  So, that's where I'm going to start here. First, let's talk about the basics of how authentication works when accessing the API.  To use Basic authentication, you need to put together your credentials in the format of "username:password" and pass them to NSX-T.  Since this is being passed through a web request and special characters could mess everything up, so you need to Base64 encode that authentication string.  Once you've got it encoded, you need to put that into the Headers of your requests so that NSX-T will know who you are.  So, let's look at how to actually do that process! First, I'm going to prepare two variables.  One wil...

I've been writing some PowerShell scripts to automate NSX-T configuration lately, so I figured that I should put together a primer with notes about how to get started!  Firstly, if you're working with the API, you're going to want to be able to reference the official documentation .  There's a lot that can be done via the API, and that guide will tell you what calls to make to do most of it!  If you're like me and haven't spent a lot of time working with APIs before, that document will present a pretty steep learning curve... so I'm writing out my notes here, to make it easier for people to get started! At its most basic, using the API is just sending a web request to the NSX-T manager and then reading the response.  Since this is potentially sensitive information, you're going to have to authenticate with the server though, so you'll need to include a Header with that login information.  If you want to change anything, you're also going to need ...

I've been working on a vCloud Director environment recently and need to use the API for my current project.  Well, I'm not a big API guy, so this has been a good learning experience for me!  The first hurdle that I had to overcome was authentication, and since I didn't find that to be super well documented, I figure that I should put my notes up here.  So, here's how I get authenticated to vCloud Director's API via PowerShell (because, of course PowerShell!). First things first, you've got to figure out what credentials you want to use.  The most basic way to authenticate is with a local account (rather than an LDAP account), but you need to append a scope to that account name to get logged in.  If the account is part of an Organization, you can use that Organization's name, but if it's a system administrator, you'll need to use "@system" instead. Next, you'll need to Base64/UTF8 encode your credentials in order to pass them success...

I've been plugging away with vRNI and the NSX Distributed firewall a lot, but that hasn't generally leant itself well to writing blog posts... until recently!  We are working on an auditing process to help us decommission NSX firewall rules in favor of policies.  Typically, when retiring a firewall rule, you would just change its priority so that it's below the newer Allow rules but still above the Deny rules, then wait a while and see if it still gets any hits.  In this situation, we're looking to retire some manually created firewall rules in favor of our new set of policy-driven rules, and you can't put manual rules in the middle of your policy rules... so the typical firewall procedure won't work here! So, we've been working on a process to use vRNI to look at all traffic that's hitting a given firewall rule, then check on the policy-based rules and ensure that it will all be allowed by those rules.  The process itself is pretty simple, and looks ...

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,...