NSX-T VIBs (vSphere Installation Bundle)



In this post, I will discuss NSX vSphere Installation Bundles (VIBs). When installing NSX, one must perform the action of "preparing" the ESXi host. To prepare the host, it means install the requisite NSX VIBs on the ESXi host. If you're coming from a purely networking background, you might be wondering, "What is a VIB"? VIBs are basically drivers, or bundles of software, that give ESXi enhanced or distinct software abilities. Even in cases where NSX is not installed, ESXi hosts will have VIBs installed to perform its day-to-day server virtualization functions.  

Non-NSX VIBs
List VIBs Command: esxcli software vib list


To give the ESXi host NSX capabilities such as Network Function Virtualization, NSX specific VIBs must be installed on the host. During host preparation, the VIBs are pushed from the NSX-T Manager to the host. Lets take a look at those vibs and I'll give a description of what each of them do. You'll notice in the image below that the NSX VIBs for my host are for NSX-T 3.2 and are to be paired with ESXi 7.0. 


NSX specific VIBS
List NSX VIBs Command: esxcli software vib list | grep -E 'nsx|vsip'



NSX-T 3.2 VIBs for ESXi version 7.0

As a result of adding an ESXi host to the NSX-T Data Center fabric, the following VIBs get installed on the host.

nsx-adf  - (Automated Diagnostics Framework) Collects and analyzes performance data to produce both local (at host) and central (across datacenter) diagnoses of performance issues.

nsx-aggservice - Provides host-side libraries for NSX-T Data Center aggregation service. NSX-T Data Center aggregation service is a service that runs in the management-plane nodes and fetches runtime state from NSX-T Data Center components.

nsx-cfgagent - Provides communication between the central control plane and hypervisors. Receives logical networking state from the central control plane and programs this state in the data plane.

nsx-cli-libs - Provides the NSX-T Data Center CLI on hypervisor hosts.

nsx-common-libs - Provide some utilities classes such as AES, SHA-1, UUID, bitmap, and others.

nsx-context-mux - Provides NSX Guest Introspection relay functionality. Allows VMware Tools guest agents to relay guest context to inhouse and registered third-party partner appliances.

nsx-esx-datapath - Provides NSX-T Data Center data plane packet processing functionality.

nsx-exporter - Provides host agents that report runtime state to the aggregation service running in the management plane.

nsx-host - Provides metadata for the VIB bundle that is installed on the host.

nsx-metrics-libs - Provides metric utility classes for collecting daemon metrics.

nsx-mpa - Provides communication between NSX Manager and hypervisor hosts.

nsx-nestdb - NestDB is a database that stores NSX configurations related to the host (desired/runtime state, etc).

nsx-opsagent - Communicates operations agent executions (transport node realization, Link Layer Discovery Protocol - LLDP,traceflow, packet capture, etc.) with the management plane.

nsx-netcpa - Provides communication required by the different components.

nsx-platform-client - Provides a common CLI execution agent, for centralized CLI and audit log collecting.

nsx-profiling-libs - Provides the functionality of profiling based on gpeftool which used for daemon process profiling.

nsx-proxy - Provides the only northbound contact point agent, which talks to the central control plane and management plane.

nsx-python-gevent - Contains Python Gevent.

nsx-python-greenlet - Contains Python Greenlet library (third party libraries).

nsx-python-logging - Contains the Python logs.

nsx-python-protobuf - Provides Python bindings for protocol buffers.

nsx-rpc-libs - This library provides nsx-rpc functionality.

nsx-sfhc - Service fabric host component (SFHC). Provides a host agent for managing the lifecycle of the hypervisor as a fabric host in the management plane's inventory. This provides a channel for operations such as NSX-T Data Center upgrade and uninstall and monitoring of NSX-T Data Center modules on hypervisors.

nsx-shared-libs - Contains the shared NSX libraries.

nsx-upm-libs - Provides unified profile management functionality for flattening client-side configuration and avoiding duplicate data transmission.

nsx-vdpi - Provides Deep Packet Inspection capabilities for NSX-T Data Center Distributed Firewall.

vsipfwlib - Provides distributed firewall functionality.

nsxcli - Provides the NSX-T Data Center CLI on hypervisor hosts.

(Source: NSX-T Install Guide 3.2 - https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/nsxt_32_install.pdf)


On occasion, you might run into a problem with host preparation. In those cases, check the host's log file esxupdate.log. Consider running a tail on the log file while the install is taking place so you can see exactly where the problem is.

tail -f /var/log/esxupdate.log

YouTube Demonstration




Outside of NSX installation, there are a few occasions where vib installation happens. NSX upgrades from version to version will remove vibs from the old version and install vibs for the new NSX version. Additionally, when you upgrade between some ESXi versions, such as from ESXi 6.7 to ESXi 7.0, the NSX vibs will need to be upgraded. You'll want to follow the NSX documentation closely in this matter because NSX vibs don't automatically update themselves unless you follow VMware documentation. For more on that, consult VMware documentation:

https://docs.vmware.com/en/VMware-vSphere/7.0/vsphere-esxi-703-upgrade-guide.pdf
Page 28


Thanks for taking the time to read my blog post about NSX-T vibs. Hopefully this post helped you understand a little bit more about NSX-T vibs than before you started reading this post! 






 





 

Comments

Post a Comment

Popular posts from this blog

VXLAN versus GENEVE (NSX-V vs. NSX-T)

Image
  August 14th, 2021 With the ramp-up of NSX-T overlay networks and transition away from NSX-V overlay networks, it's a good time to look at one of the fundamental differences between them. NSX-V uses VXLAN as its encapsulation protocol while NSX-T uses the more recent GENEVE encapsulation protocol. Each require the physical networking devices have their MTU adjusted to 1600 bytes or greater. We'll take a detailed look at why that is. First, the basics: VXLAN is: short for Virtual eXtensible Local Area Network Is defined in rfc 7348 - https://datatracker.ietf.org/doc/html/rfc7348 Uses UDP port 4789 8 byte header GENEVE is: short for Generic Network Virtualization Encapsulation Is defined in rfc 8926 -  https://datatracker.ietf.org/doc/html/rfc8926 Uses UDP port 6081 16 byte header From the prospective of the physical network, an overlay network is essentially an application. NSX-T is an application using well known UDP port 6081. Switching perspectives to the overlay's...
Read more

"Twice NAT" with NSX-T T0 Gateway

Image
  Network address translation, or more commonly NAT, is most often used to do source NAT or destination NAT. In rare instances, SNAT or DNAT isn't enough to get ip packets to their destination. Enter twice nat. While twice NAT isn't a function I've needed often, it was a function drilled into me while studying for various Cisco exams. I used to watch Christian Matei explain it over at INE and it really helped me to understand what twice NAT is and how to configure it on Cisco devices. Previous to my time working with NSX-T, I'd only utilized twice NAT once. A few years back, a customer wanted to build and IPsec tunnel from the organization HQ to a branch office. The private ip space used by HQ and the branch used overlapping ip space. We used twice NAT to NAT the source and destination ip address in a single NAT rule ( similar to this guy ) before shoving it all into an IPsec tunnel. Previous to working with NSX, circumstances requiring twice NAT were uncommon.  While w...
Read more

Packet Capture Network Traffic Inside ESXi Hypervisor

Image
The three components of computer infrastructure are considered compute, storage, and networking. When applications don't work properly, its often the case that networking is the first component to receive blame for failed application performance. In the case of virtualized workloads (i.e. applications running on virtual machines), we are fortunate to have a powerful troubleshooting tool which allows us to packet capture network traffic in an ESXi hypervisor. For this blog, I'm going to use an Hands On Lab (HOL) from the VMware website to demonstrate the process of doing a quick live packet capture. The output of the packet capture will be sent to the shell of the hypervisor. There are ways to sent the network traffic to a file so it can be extracted and analyzed by a packet analyzer tool, but that will be for another post. First, lets start with heading over to the HOL website:  https://labs.hol.vmware.com/ For this lab, I'm going to type NSX in the search bar to find...
Read more