Virtually Jason

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

One of my customers is organizing a cloud migration and asked for help with the onboarding process.  My team and I started doing research and we come across VMware's Hybrid Cloud Extension (HCX) technology.  It's incredible, how did I not know about this before!? The long and short of it is that it bridges customer networks into cloud datacenters so that VMs can be vMotioned to and from the cloud.  That's a very powerful position to put the customer in, as they can now migrate workload dynamically onto the cloud without taking a service outage.  How's it work? HCX requires several appliances, both in the cloud and client datacenters.  Those appliances serve 2 major functions: they bridge production networks and they proxy ESXi hosts. As far as network bridging is concerned, the HCX appliances function very much like an NSX Edge that is doing its own L2 bridging.  From a network perspective, HCX basically looks like an upstream switch, behind which are a series of