Due to a recent lab rebuild, I needed to manually remove the NSX VIBs that were installed on my ESXi host, and thought I would document the process so I can remember it in the future. Removing the NSX VIBs from a host manually does not remove the configuration stored on the NSX Manager, so care needs to be taken when doing this. Depending on the version of NSX-v installed, the number of NSX VIBs installed will vary. ...
Whilst working on a little side project of mine, I wanted to be able to submit a REST API call against a NSX Manager. At first I was just going to use shell_exec to execute one of my python scripts, but after a bit of investigation, I found that I could use the PHP Client URL Library (cURL) . It took me a little bit of time to get it working just the way I wanted, but now that I have the basics, it should be simple to be able to do most things through a webpage. ...
Following on from my last post about the NSXRAMLCLIENT, I decided to setup an Ubuntu machine dedicated to being able to run the NSXRAMLCLIENT in my home lab. Using my own instructions that I had written previously to get it up and running on my OSX 10.10.5 machine, I came across a peculiar issue when trying to initiate a connection to the nsx manager. Here is the code I was running which works on my OSX machine without issues: ...
Up until now, my programmatic interactions with the NSX API have all been hacked together based on the NSX API Guide, due to the lack of a specific NSX API scripting interface. For typical vSphere scripting, there has been PowerCli and also pyvmomi and I am sure a few more I don’t know about, but nothing created specifically for NSX. This meant that for individuals like myself, who wanted to write scripts to interact with the NSX-v API through python, we would have to create all the API calls from scratch which is time consuming and then learn how to parse the responses and content. ...
When working with the Service Composer in NSX-v, by default, when a firewall rule is created in a Security Policy, the firewall rule, when applied, uses the default Applied To value of Distributed Firewall. This means that even though the firewall rule is part of a security policy which is then applied to a specific security group, the rule would be pushed down to every vNIC within the clusters that have been prepared for NSX DFW capabilities and have the firewall enabled. ...
One of the new features in NSX vSphere 6.2 is the introduction of new IP discovery mechanisms. The official release notes mentions this as follows: New IP address discovery mechanisms for VMs: Authoritative enforcement of security policies based on VM names or other vCenter-based attributes requires that NSX know the IP address of the VM. In NSX 6.1 and earlier, IP address discovery for each VM relied on the presence of VMware Tools (vmtools) on that VM or the manual authorization of the IP address for that VM. NSX 6.2 introduces the option to discover the VM’s IP address using DHCP snooping or ARP snooping. These new discovery mechanisms enable NSX to enforce IP address-based security rules on VMs that do not have VMware Tools installed. ...
When working with a customer recently to install NSX-v into a lab environment, we were faced with hosts which would fail when we went through the Host Preparation steps to install the NSX VIBs. As it turns out, it wasn’t the usual problems of incorrect DNS or a firewall causing issues but rather vSphere Update Manager (VUM) which was causing the issue. So from what I can deduce, it seems that when you Click the install button to prepare a cluster, EAM is used to install a VIB onto the ESXi hosts within that cluster, an agency is created within EAM for that specific cluster and within the cluster specific agency the following config option is set by default. ...
Operating and troubleshooting a NSX-v environment can sometimes be a daunting task, especially if the customer had the environment setup by an external party (ie. VMware PSO or a VMware Partner). And so over the past few weeks, VMware have released 2 pieces of collateral which I am finding answer a lot of questions that I am normally asked by customers. The first is the NSX-v Operations Guide, v6.1 (https://communities.vmware.com/docs/DOC-30079) that is posted on the VMware Communities site. At a high level, this document touches on the following topics: ...
Recently when doing some performance testing with a customer, we wanted to have the ability to bulk create a number of DFW rules. By leveraging some python scripting and the NSX-v API, I came up with a flexible and re-useable script which can be used to create a new section and populate it with up to 997 DFW rules. The reason for creating a new section is so that when it comes time to delete the test rules, its as simple as just deleting the section, which will delete all rules within the section. ...
For those who have used the NSX vSphere REST API, you will know that with every API call you are required to send the following in the headers: Content-Type application/xml Basic <base64 encoded credentials> So if you have an OSX machine, you can leverage openssl (which is installed by default) to generate the base64 encoded credentials. This means you do not have to find a website and paste credentials into the site to generate the encoded credentials. ...