Automation

vSphere 6.5 (released last week) introduces a **new REST API **providing a much more modern, simplified and developer-friendly API. The areas covered by the REST API are currently limited to vCenter Server Appliance (vCSA) management, Content Library and VM operations and lifecycle (check below for a more complete list). Also, to make our life easier, this new API is self-documented via an API Explorer embedded in the vCenter Server Appliance. ...

Someone asked me recently how to configure NSX Load Balancing to get a single virtual IP (VIP) with multiple ports. Indeed, applications often listen on multiple ports and to avoid creating multiple virtual servers for that, you can define VIPs that are based on a port range. Reminder: NSX load balancer distributes network traffic across multiple servers to achieve optimal resource use. How does it work? You map an Edge IP address to a set of internal servers for load balancing. ...

When NSX 6.2.3 was released earlier this year, a sentence in the release notes about failover caught my attention. **NSX Edge — On Demand Failover**: Enables users to initiate on-demand failover when needed. Well, since that moment, NSX 6.2.3 has been replaced by NSX 6.2.4 (sort of), but this statement is still true. About NSX Edge High Availability Before jumping straight into the subject, I would like to come back on the HA feature itself. ...

VMware vRealize Network Insight 3.0.0 (formerly known as Arkin) is now generally available. vRNI delivers intelligent operations for software-defined networking and security, with converged visibility across virtual and physical networks, planning and recommendations for micro-segmentation and operations management for NSX. This product is a new offering for VMware, and addresses the need for deeper, richer NSX operation and traffic analytics in the fast growing virtual networking market. Compared to Arkin, there are several new features being introduced with this release: ...

I was reading through the NSX API Guide recently and a section caught my attention: Configuring Edge Services in Async Mode. When configuring edge services asynchronously, accepted commands return an Accepted status (HTTP response status code 202) and a jobId (or taskId). The advantage of the async mode is that APIs are returned very fast and actions are done behind the scene. This asynchronous mode is working with any 4.0 service configuration URL for POST, PUT, and DELETE calls (edge deployment, services configuration, reboots and so on). ...