Category Archives: NSX

NSX Bytes – What’s new in NSX-T 2.1

In Feburary of this year VMware released NSX-T 2.0 and with it came a variety of updates that looked to continue to push of NSX-T beyond that of NSX-v while catching up in some areas where the NSX-v was ahead. The NSBU has big plans for NSX beyond vSphere and during the NSX vExpert session we saw how the future of networking is all in software…having just come back from AWS re:Invent I tend to agree with this statement as organisations look to extend networks beyond traditional on-premises or cloud locations.

NSX-T’s main drivers relate to new data centre and cloud architectures with more hetrogeneality driving a different set of requirements to that of vSphere that focuses around multi-domain environments leading to a multi-hypervisor NSX platform. NSX-T is highly extensible and will address more endpoint heterogeneity in future releases including containers, public clouds and other hypervisors. As you can see before the existing use cases for NSX-T are mainly focused around devops, micro-segmentation and multi-tenant infrastructure.

Layer 3 accessibility across all types of platforms.

What’s new in NSX-T 2.1:

Today at Pivotal SpringOne, VMware is launching version 2.1 of NSX-T and with it comes a networking stack underpinning Pivotal Container Services, direct integration with Pivotal Cloud Foundry and significant enhancements to load balancing capabilities for OpenStack Neutron and Kubernetes ingress. These load balancers can be virtual or bare metal. There is also native networking and security for containers and Pivotal operations manager integration.

NSX-T Native Load Balancer:
NSX-T has two levels of routers as shown above…then ones that connect to the physical world and the ones which are labeled T1 in the diagram above. Load balancing will be active on the T1 routers and have the following features:

  • Algorithms – Round Robin, Weighted Round Robin, Least Connections and Source IP Hash
  • Protocols – TCP, UDP, HTTP, HTTPS with passthrough, SSL Offload and End to end SSL
  • Health Checks – ICMP, TCP, UDP, HTTP, HTTPS
  • Persistance – Source IP, Cookie
  • Translation – SNAT, SNAT Automap and No SNAT

As well as the above it will have L7 manipulation as will as OpenStack and Kubernetes ingress. Like NSX-v these edges can be deployed in various sizes depending on the workload.

Pivotal Cloud Foundry and NSX-T:

For those that may not know, PCF is a cloud native platform for deploying and operating modern applications and in that NSX-T providers the networking to support those modern application. This is achieved via the Network Container Plugin. Cloud Foundry NSX-T topology include a separate network topology per orginization with every organization getting one T1 router. Logical switches are then attached per space. High performance north/south routing uses NSX routing infrastructure, including dynamic routing to the physical network.

For east/west traffic that happens container to container with every container having distributed firewall rules applied on it’s interface. There is also a number of visibility and troubleshooting counters attached to every container. NSX also controls the IP management by supplying subnets from IP blocks to namespaces and individual IPs and MACs to containers.

Log Insight Content Pack:

As part of this release there is also a new Log Insight NSX-T Content Pack that builds on the new visibility and troubleshooting enhancements mentioned above and allows Log Insight to monitor a lot of the container infrastructure with NSX.

Conclusion:

When it comes to the NSX-T 2.1 feature capabilities, the load balancing is a case of bringing NSX-T up to speed to where NSX-v is, however the thing to think about is that how those capabilities will or could be used beyond vSphere environments…that is the big picture to consider here around the future of NSX and it can be seen with the deeper integration into Pivotal Cloud Foundry.

Released: NSX-v 6.3.5 and New Features and Fixes

Last week VMware released NSX-v 6.3.5 (Build 7119875) that contains a few new features and addresses a number of bug fixes from previous releases. Going through the release notes there are a lot of known issues that should be known and there are more than a few that apply to service providers…specifically there are a lot around Logical and Edge Routing functions. The other interesting point to highlight about this release is that this is apparently the same build that runs on VMware on AWS instances as mentioned by Ray Budavari.

The new features in this build are:

  • For vCenter 6.5 and later, Guest Introspection VM’s, on deployment, will be named Guest Introspection (XX.XX.XX.XX), where XX.XX.XX.XX is the IPv4 address of the host on which the GI machine resides. This occurs during the initial deployment of GI.
  • Guest Introspection service VM will now ignore network events sent by guest VMs unless Identify Firewall or Endpoint Monitoring is enabled
  • You can also modify the threshold for CPU and memory usage system events with this API: PUT /api/2.0/endpointsecurity/usvmstats/usvmhealththresholds
  • Serviceability enhancements to L2 VPN including
    • Changing and/or enabling logging on the fly, without a process restart
    • Enhanced logging
    • Tunnel state and statistics
    • CLI enhancements
    • Events for tunnel status changes
  • Forwarded syslog messages now include additional details previously only visible on the vSphere Web Client
  • Host prep now has troubleshooting enhancements, including additional information for “not ready” errors

That last new feature above is seen below…you can see the EAM Status message just below the NSX Manager IP which is a nice touch given the issues that can happen if EAM is down.

If you click on the Not Ready Installation Status you now get a more detailed report of what could be wrong and suggestions of how to resolve.

Important Fixes :

  • VMs migrated from 6.0.x can cause host PSOD When upgrading a cluster from 6.0.x to 6.2.3-6.2.8 or 6.3.x, the VM state exported can be corrupted and cause the receiving host to PSOD
  • “Upgrade Available” link not shown if cluster has an alarm. Users are not be able to push the new service spec to EAM because the link is missing and the service will not be upgraded
  • NSX Manager crashes with high NSX Manager CPU NSX Manager has an OOM (out of memory) error and continuously restarts
  • NSX Controller memory increases with hardware VTEP configuration causing high CPU usage A controller process memory increase is seen with hardware VTEP configurations running for few days. The memory increase causes high CPU usage that lasts for some time (minutes) while the controller recovers the memory. During this time the data path is affected
  • Translated IPs are not getting added to vNIC filters which is causing Distributed Firewall to drop traffic When new VMs are deployed, the vNIC filters do not get updated with the right set of IPs causing Distributed Firewall to block the traffic.

Those with the correct entitlements can download NSX-v 6.3.5 here.

References:

https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.3/rn/releasenotes_nsx_vsphere_635.html

Awarded vExpert Cloud – A New vExpert Sub Program

Last week Corey Romero announced the inaugural members of the vExpert Cloud sub-program. This is the third vExpert sub-program following the vSAN and NSX programs announced last year. There are 135 initial vExpert Cloud members who have been awarded the title. As it so happens I am now a member of all three which reflects on the focus I’ve had and still have around VMware’s cloud, storage and networking products leading up to and after my move to Veeam last year.

Even with my move, that hasn’t stopped me working around these VMware vertices as Veeam works closely with VMware to offer supportability and integration with vCloud Director as well as being certified with vSAN for data protection. And more recently as it pertains specifically to the vExpert Cloud program, we are going to be supporting vCloud
Director in v10 of Backup & Replication for Cloud Connect Replication and also at VMworld 2017 we where announced as a launch partner for data protection for VMware Cloud on AWS.

For those wondering what does it take to be a part of the vExpert Cloud program:

We are looking for vExperts who are evangelizing VMware Cloud and delivering on the principles of the multi-cloud world being the new normal. Specificity we are looking for community activities which follow the same format as the vExpert program (blogs, books, videos, public speaking, VMUG Leadership, conference sessions speaking and so on).

And in terms of the focus of the vExpert Cloud program:

The program is focused on VMware Cloud influencer activities, VMware, AWS and other cloud environments and use of the products and services in way that delivers the VMware Cloud reality of consistency across multi-cloud environments.

Again, thank you to Corey and team for the award and I look forward to continuing to spread the community messaging around Cloud, NSX and vSAN.

Released: NSX-v 6.3.4 and Upgrade Notes and Fixes

Last week VMware released NSX-v 6.3.4 (Build 6845891) that contains no specific new features but addresses a couple of bug fixes from previous releases. Going through the release notes there are a lot of known issues that should be known and there are more than a few that apply to service providers…specifically there are a lot around NSX Edge functions. The other interesting point to highlight about this release is that for those on NSX-v 6.3.3 there is are a couple of scripts to run against the API before upgrading to ensure all controllers are upgradable.

As mentioned, before upgrading the release notes stage that for those on NSX-v 6.3.3 they follow this VMwareKB. In a nutshell there is a bug in 6.3.3 where the NSX Controllers are reported as disconnected in the Web Client as shown below.

To fix that situation you need to execute a couple of API calls that POSTs a script to the NSX Manager as documented in the VMwareKB. This needs to be done as the NSX Manager Admin user as I found this didn’t work with an NSX Domain User or an SSO Administrator Account with NSX Org admin level permissions.

Once the second script has been run you should see a similar output to what’s shown above and have all NSX Controllers ready in a connected state which allows you to prepare for the upgrade. Once done, you can go through the normal NSX upgrade steps which will get you to the latest build.

Important Fixes :

  • Fixed Issue 1970527: ARP fails to resolve for VMs when Logical Distributed Router ARP table crosses 5K limit
  • Fixed Issue 1961105: Hardware VTEP connection goes down upon controller rebootA BufferOverFlow exception is seen when certain hardware VTEP configurations are pushed from the NSX Manager to the NSX Controller. This overflow issue prevents the NSX Controller from getting a complete hardware gateway configuration. Fixed in 6.3.4.
  • Fixed Issue 1955855: Controller API could fail due to cleanup of API server reference filesUpon cleanup of required files, workflows such as traceflow and central CLI will fail. If external events disrupt the persistent TCP connections between NSX Manager and controller, NSX Manager will lose the ability to make API connections to controllers, and the UI will display the controllers as disconnected. There is no datapath impact.

Those with the correct entitlements can download NSX-v 6.3.4 here.

References:

https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.3/rn/releasenotes_nsx_vsphere_634.html

https://kb.vmware.com/kb/2151719

 

NSX Bytes: NSX-v 6.3.3 Released – Upgrade Notes and Enhancements

Last week VMware released NSX-v 6.3.3 (Build 6276725) and with it comes a new operating system for the NSX Controllers. Once upgraded the new controllers will be powered by Photon OS which is more and more making it’s way into VMware’s appliances. There are a few other new bits in this release but more importantly a number of Resolved Issues. For those running homelabs with one NSX Controller there are some important upgrade notes to be made aware of before kicking off…i’ll go into those below.

Compatibility:

Before moving to the upgrade there are some important notes around interoperability and supported ESXi versions as is explained in this VMwareKB. The minimum supported version of ESXi running with NSX-v 6.3.3 is as shown below:

  • NSX-v 6.3.3 installed in a vSphere 5.5 environment requires a minimum version of ESXi 5.5 GA
  • NSX-v 6.3.3 installed in a vSphere 6.0 environment requires a minimum version of ESXi 6.0 Update 2
  • NSX-v 6.3.3 installed in a vSphere 6.5 environment requires a minimum version of ESXi 6.5a
If NSX 6.3.3 is installed on an earlier version of 5.5/6.0 ESXi, the netcpa service will fail to start preventing communication between ESXi hosts and the NSX Controllers.
In terms of upgrading from previous versions of NSX-v you can see that the upgrade path does have some stoppers. Below is the interoperability matrix that included vCloud Director 8.20 which, at the moment is not supported with NSX-v 6.3.3…I expect that to change over the next couple of weeks.
Upgrading to NSX-v 6.3.3:

 

As mentioned there are things to look out for during and after the upgrade from previous builds of NSX-v. There are detailed upgrade notes in the release notes so as always, make sure to read those as well, but below is a brief walk through of the upgrade process I conducted in one of my NestedESXi labs.
Once the NSX Manager has been upgraded you should have the following in your Summary tab:
Once the NSX Manager has been upgraded you should restart the vCenter Web Client to ensure any lingering parts of the previous version are removed. Login to the Web Client and click through to Networking & Security -> Installation and then the Management Tab where you will see Upgrade Available.
IMPORTANT NOTE: The upgrade notes state that you need to have a minimum of three NSX Controllers which I’d say is linked to the fact that the underlying OS of the Controllers has been shifted to Photon OS. This is likely to impact anyone running NSX in a NestedESXi or homelab as generally, only one was deployed to preserve resources. Once you click on upgrade you will get a special upgrade warning before committing to the upgrade as shown below:
  • The NSX Controller cluster must contain three controller nodes to upgrade to NSX 6.3.3. If it has fewer than three controllers, you must add controllers before starting the upgrade
  • When you upgrade to NSX-v 6.3.3, instead of an in-place software upgrade, the existing controllers are deleted one at a time, and new Photon OS based controllers are deployed using the same IP addresses

There is also a slight increase to the size of the storage for the controllers from 20GB to 28GB. Once upgraded the NSX Controllers will be at version 6.3.6235594.

The last major step is to upgrade the Host components from the Host Preparation tab. On vSphere 6.0 and above once you have upgraded to NSX 6.3.x, all future NSX VIB changes do not trigger a reboot…only maintenance mode is required to complete the VIB change. In NSX 6.3.3 there is a change to the NSX VIB names on ESXi 6.0 and later where the esx-vxlan and esx-vsip VIBs have been merged and replaced with esx-nsxv as shown below.

VIB names on ESXi 5.5 remain the same.

References:

https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.3/rn/releasenotes_nsx_vsphere_633.html

https://kb.vmware.com/kb/2151267

 

vCloud Director SP 8.20 – NSX Advanced Networking Overview

Many, including myself thought that the day would never come where we would be talking about a new UI for vCloud Director…but a a month on from the 8.20 release of vCloud Director SP (which was the 8th major release of vCD) I’m happy to be writing about the new Advanced Networking features of 8.20 based on NSX-v. Full NSX compatibility and interoperability has been a long time coming, however the wait has been worthwhile as the vCloud Director team opted to fully integrate the network management into the vCD Cloud Cells over the initial approach that had a seperate appliance acting as a proxy between the NSX Manager and vCD Cells.

But before I dive into the new HTML5 goodness, I thought it would be good to recap the Advanced Networking Services of vCD and how we got to where we are today…

No More vShield…Sort Of:

As everyone should know by now, the vCloud Networking & Security was made end of life late last year and from the release of vCD SP 8.10 vShield Edges should have been upgraded to their NSX equivalents. These Edges will remain as basic Edges within vCloud Director and even though at the backend they would be on NSX-v versioning, no extra features or functionality beyond what was available in the existing vCD portal would be available to tenants.

  • DHCP
  • NAT
  • Firewall
  • Static Routing
  • IPSec VPN
  • Basic Load Balancer

The version of NSX-v deployed dictates the build number of the NSX Edge, however as can be seen below it’s still listed as a vShield Edge in vCenter.

As anyone who has worked closely would know, NSX-v has a lot of vShield DNA in it and in truth it’s more vShield than NSX when talking about the features that pertain to vCloud Director. However the power of NSX-v can be taken advantage of once an basic edge is upgraded to an Advanced Edge.

Advanced Edge Services:

Before the major UI additions that came with vCD SP 8.20 the previous 8.10 version did give us a taste of what was to come with the introduction of a new menu option when you right clicked on an Edge Gateway.

This option was greyed out unless you where running the initial beta of the Advanced Networking Services or ANS. The option can be executed by anyone with the rights to upgrade the edge gateway, but by default this can only be done by a System Administrator or the Org Admin. So it’s worthwhile double checking the roles you have allocated to your tenant’s to ensure that these upgrades can be controlled.

Once you click on the Convert to Advanced Gateway option you get a warning referring to a VMwareKB that warns you about an API change that may make previous calling methods obsolete. Something to take note of for anyone automating this process. On execution of this conversion there is no physical change to the Virtual Machine, however if you now click on the Edge Gateway Services option of the Edge Gateway you will be taken to the new HTML5 Web Interface for NSX Advanced Networking Services to access all the advanced features:

  • Firewall
  • DHCP
  • NAT
  • Routing (Dynamic)
  • Load Balancer (Advanced)
  • SSL VPN Plus
  • Certificates
  • Grouping Objects
  • Statistics
  • Edge Settings

All new Advanced Networking features are configured from the new HTML5 web interface which retains the base vCD URL but now adds:

/tenant/network-edges/{ID}?org=ORGNAME

Everything is self contained the tenant doesn’t have to authenticate again to get to the new user interface. However, if you just upgrade the Edge and go to configure the Advanced Network Services out of the box you will only see a couple of the items listed above.

In order to use the new features a System Administrator must use the vCloud API to grant the new rights that the organisation requires. This process has been explained very well by my good friend Giuliano Bertello here. This process uses the vCloud API to Grant Distributed Firewall and Advanced Networking Services Rights to roles in vCloud Director 8.20 using the new granular role based access control mechanisms that where introduced in 8.20. Once configured your tenant’s can now see all the services listed above to configure the Edge Gateway.

Organisational Distributed Firewall:

Something that is very much new in the 8.20 release is the ability to take advantage of mircosegmentation using the NSX-v Distributed Firewall service. The ability to configure organisation wide rules logically, without the need for a virtual Edge Gateway is a significant step forward for vCD tenants and I hope that this feature enhancement is exposed by service providers and it’s value sold to their tenants. To access the Distributed Firewall, in the Virtual Datacenters windows of the Administration tab, right click on the Virtual Datacenter name and select Manage Firewall.

Once again you will be taken to the new HTML5 user interface and once the correct permissions have been applied to the user you can enable the Distributed Firewall and start configuring your rules. The URL is slightly different to the Edge Gateway URL:

/tenant/dwf/{ID}?org=ORGNAME

But the look and feel is familiar.

Conclusion:

vCloud Director SP 8.20 has finally delivered on the what most members of the vCloud Air Network had wanted for some time…that is, full NSX interoperability and feature set access as well as a new user interface. Over the next few weeks, I am going to expand on all the features of the Advanced and Distributed Networking features of vCD and NSX and walk through how to configure elements through the UI and API as well as give a looks into what’s happening at the backend in terms of how NSX stores rules and policy items for vCD tenant use.

Compatibility with vSphere 6.5 and NSX-v 6.3.x:

vCloud Director SP 8.20 is compatible with vSphere 6.5 and NSX 6.3.0 and supports full interoperability with other versions as shown in the VMware Product Interoperability Matrix. As of vCD 8.20 GA, vCD 8.20 passed the functional interoperability test and limited scale testing for these versions:

  • vCD 8.20 with vSphere 6.0 and NSX 6.3.0
  • vCD 8.20 with vSphere 6.5 and NSX 6.3.0

References:

https://kb.vmware.com/kb/2149042
https://kb.vmware.com/kb/2147625

Released: vCloud Director SP 8.20 with HTML5 Goodness!

This week, VMware released vCloud Director SP version 8.20 (build 5070630) which marks the 8th Major Release for vCloud Director since 1.0 was released in 2010. Ever since 2010 the user interface give or take a few minor modifications and additions has been the same. It also required flash and java which has been a pain point for a long time and in someways unfairly contributed towards a negative perception around vCD on a whole.  It’s been a long time coming but vCloud Director finally has a new web UI built on HTML5 however this new UI is only exposed when accessing the new NSX integration which is by far and away the biggest addition in this release.

This NSX integration has been in the works for a while now and has gone through a couple of iterations within the vCloud product team. Initially announced as Advanced Networking Services which was a decoupled implementation of NSX integration we now have a fully integrated solution that’s part of the vCloud Director installer. And while the UI additions only extend to NSX for the moment it’s brilliant to see what the development team have done with the Clarity UI (tbc). I’m going to take a closer look at the new NSX features in another post, but for the moment here are the release highlights of vCD SP 8.20.

New Features:

  • Advanced Edge Gateway and Distributed Firewall Configuration – This release introduces the vCloud Director Tenant Portal with an initial set of controls that you can use to configure Edge Gateways and NSX Distributed Firewalls in your organization.
  • New vCloud Director API for NSX – There is a new a proxy API that enables vCloud API clients to make requests to the NSX API. The vCloud Director API for NSX is designed to address NSX objects within the scope of a vCloud Director tenant organization.
  • Role Administration at the Organization Level – From this release role objects exist in each organization. System administrators can use the vCloud Director Web Console or the vCloud API to create roles in any organization. Organization administrators can use the vCloud API to create roles that are local to their organization.
  • Automatic Discovery and Import of vCenter VMs – Organization VDCs automatically discover vCenter VMs that exist in any resource pool that backs the vDC. A system administrator can use the vCloud API to specify vCetner resource pools for the vDC to adopt. vCenter VMs that exist in an adopted resource pool become available as discovered vApps in the new vDC.
  • Virtual Machine Host Affinity – A system administrator can create groups of VMs in a resource pool, then use VM-Host affinity rules to specify whether members of a VM group should be deployed on members of a vSphere host DRS Group.
  • Multi-Cell Upgrade – The upgrade utility now supports upgrading all the cells in your server group with a single operation.

You can see above that this release has some major new features that are more focused on tenant usability and allow more granular and segmented controls of networks, user access and VM discovery. The Automatic VM discovery and Import is a significant feature that goes along with the 8.10 feature of live VM imports and helps administrators import VM work loads into vCD from vCenter.

“VMware vCloud Director 8.20 is a significant release that adds enhanced functionality.  Fully integrating VMware NSX into the platform allows edge gateways and distributed firewalls to be easily configured via the new HTML5 interface.  Additional enhancements such as seamless cell upgrades and vCenter mapping illustrate VMware is committed to the platform and to vCloud Air Network partners.”

A list of known issues can be found in the release notes and i’d like to highlight the note around Virtual Machine memory for the vCD Cells…I had my NestedESXi lab instances crash due to memory pressures due to the fact the VMs where configured with only 5GB of RAM. vCloud Director SP 8.20 needs at least 6GB so ensure your cells are modified before you upgrade.

Well done the the vCloud Director Product and Development team for this significant release and I’ll look to dig into some of the new feature in detail in upcoming posts. You can also read the offical vCloud Blog release post here. I’m looking forward to what’s coming in the next release now…hopefully more functionality placed into the HTML5 UI and maybe integration with VMwareonAWS 😉

References:

http://pubs.vmware.com/Release_Notes/en/vcd/8-20/rel_notes_vcloud_director_8-20.html

https://www.vmware.com/support/pubs/vcd_sp_pubs.html

https://blogs.vmware.com/vcloud/2017/02/vmware-announces-general-availability-vcloud-director-8-20.html

NSX Bytes: NSX-T 2.0 Released

A couple of months ago in my NSX-v 6.3 and NSX-T 1.1 release post I focused around NSX-v features as that has become the mainstream version that most people know and work with…however NSX, in it’s Nicira roots has always been about multi-hypervisor and has always had an MH version that worked with Openstack deployments. The NSBU has big plans for NSX beyond vSphere and during the NSX vExpert session we got to see a little about how NSX-T will look beyond version 1.1.

NSX-T’s main drivers relate to new data centre and cloud architectures with more hetrogeneality driving a different set of requirements to that of vSphere that focuses around multi-domain environments leading to a multi-hypervisor NSX platform. NSX-T is highly extensible and will address more endpoint heterogeneity in future releases including containers, public clouds and other hypervisors. As you can see before the existing use cases for NSX-T are mainly focused around devops, micro-segmentation and multi-tenant infrastructure.

What’s in NSX-T 2.0:
The short answer to this is a focus on expanding NSX to public clouds, containers and platform as a service workloads. We have already seen a tech preview at VMworld of NSX working with AWS instances and the partnership between VMware and AWS is even more of a driver for this cross cloud compute and networking landscape to allow NSX-T to shine.
Expanded Networking and Security into Public Cloud and Containers:
  • Centralised security policy management
  • NSX for Public Cloud (AWS)
  • NSX for Cross-Cloud Services (AWS)
  • NSX for Containers and PaaS (Kubernetes, Openshift)

Platform Capabilities:

  • Distributed L3 at scale decoupled from vCenter
  • Intel DPDK Edge Line Rate packet performance
  • L2/L3 redundant control and data plane
  • ESXi and KVM (RHEL/Ubuntu)
  • Independant NSX interface thats multi vCenter
  • Scale out control plane and scale out edge cluster
  • VM and Containers Hosts

Feature Capabilities:

  • Distributed Routing, eBGP, NAT, BFD, ECMP, route-maps, 4 byte ASN
  • REST/JSON OpenAPI Specification
  • VIO, Upstream Openstack support
  • Geneve Encapsulation, QoS, Software L2 Bridge
  • Distributed stateful firewall, tag based security grouping
  • DHCP Server and Relay
  • IPFIX, Port Mirroring, Port Connectivity, Trace Flow, Backup & Restore
  • Log Insight Content Management Pack

Where do NSX-v and NSX-T Play:

Conclusion:

When it comes to the NSX-T 2.0 feature capabilities, many of them are a case of bringing NSX-T up to speed to where NSX-v is, however the thing to think about is that how those capabilities will or could be used beyond vSphere environments…that is the big picture to consider here around the future of NSX!

For an overview of what’s was released in NSX-T 2.0, the release notes can be found here, or have a read of my launch post here.

References:

NSX Bytes: NSX-v 6.3 Host Preparation Fails with Agent VIB module not installed

NSX-v 6.3 was released last week with an impressive list of new enhancements and I wasted no time in looking to upgrades my NestedESXi lab instance from 6.2.5 to 6.3 however I ran into an issue that at first I thought was related to a previous VIB upgrade issue caused by VMware Update Manager not being available during NSX Host upgrades…in this case it presented with the same error message in the vCenter Events view:

VIB module for agent is not installed on host <hostname> (_VCNS_xxx_Cluster_VMware Network Fabri)

After ensuring that my Update Manager was in a good state I was left scratching my head…that was until some back and forth in the vExpert Slack #NSX channel relating to a new VMwareKB that was released the same day as NSX-v 6.3.

https://kb.vmware.com/kb/2053782

This issue occurs if vSphere Update Manager (VUM) is unavailable. EAM depends on VUM to approve the installation or uninstallation of VIBs to and from the ESXi host.

Even though my Upgrade Manager was available I was not able to upgrade through Host Preparation. It seem’s like vSphere 6.x instances might be impacted by this bug but the good news is there is a relatively easy workaround as mentioned in the VMwareKB that bypasses the VUM install mechanism. To enable the workaround you need to enter into the Managed Object Browser of the vCenter EAM by going to the following URL and entering in vCenter admin credentials.

https://vCenter_Server_IP/eam/mob/ 

Once logged in you are presented with a (or list of) agencies. In my case I had more than one, but I selected the first one in the list which was agency-11

The value that needs to be changed is the bypassVumEnabled boolean value as shown below.

To set that flag to True enter in the following URL:

https://vCenter_Server_IP/eam/mob/?moid=agency-x&method=Update

Making sure that the agency number matches your vCenter EAM instance. From there you need to change the existing configuration for that value by removing all the text in the value box and invoking the value listed below:

Once invoked you should be able to go back into the Web Client and click on Resolve under the Cluster name in the Host Preparation Tab of the NSX Installation window.

Once done I was in an all Green state and all hosts where upgraded to 6.3.0.5007049. Once all hosts have been upgraded it might be a useful idea to reverse the workaround and wait for an official fix from VMware.

References:

https://kb.vmware.com/kb/2053782

NSX Bytes: NSX for vSphere 6.3 and NSX-T 1.1 Release Information

VMware’s NSX has been in the wild for almost three years and while the initial adoption was slow, of recent times there has been a calculated push to make NSX more mainstream. The change in licensing that happened last year has not only been done to help drive adoption by traditional VMware customers running vSphere that previously couldn’t look at NSX due to price but also the Transformers project has looked to build on Nicira’s roots in the heterogeneous hypervisor market and offer network virutalization beyond vSphere and beyond Open source platforms and into the public cloud space. The vision for VMware with NSX is to manage security and connectivity for heterogeneous end points through:

  • Security
  • Automation
  • Application Continuity

NSX has seen significant growth for VMware over the past twelve to eighteen months driven mostly from customer demand focusing around micro-segmentation, IT automation and efficiency and also the need to have extended multiple data centre locations that can be pooled together. To highlight the potential that remains with NSX-v less that 5% of the total available vSphere install base has NSX-v installed…and while that could have something to do with the initial restrictions and cost of the software it still represents enormous opportunity for VMware and their partners.

Last week the NSX vExpert group was given a first look at what’s coming in the new releases…below is a summation of what to expect from both NSX-v 6.3 and NSX-T 1.1. Note that we where not given an indication on vSphere 6.5 support so, like the rest of you we are all waiting for the offical release notes.

[Update] vSphere 6.5 will be supported with NSX-v 6.3

Please note that VMware vSphere 6.5a is the minimum supported version with NSX for vSphere 6.3.0. For the most up-to-date information, see the VMware Product Interoperability Matrix. Also, see 2148841.

NSX for vSphere 6.3 Enhancements:

Security:

  • NSX Pre-Assessment Tool based on vRealize Network Insight
  • Micro-Segmentation Planning and application visibility
  • New Security Certifications around ICSA, FIPS, Common Criteria and STIG
  • Linux Guest VM Introspection
  • Increase performance in service chaining
  • Larger scalability of VDI up to 50K desktops
  • NSX IDFW for VDI
  • Active Directory Integration for VDI at scale

Automation:

  • Routing Enhancements
  • Centralized Dashboard for service and ops
  • Reduced Upgrade windows with rebootless upgrades
  • Integration with vRA 7.2 enhancing LB,NAT
  • vCloud Director 8.20 support with advanced routing, DFW, VPN
  • VIO Updates to include multi-vc deployments
  • vSphere Integrated Container Support
  • New Automation Frameworks for PowerNSX, PyNSXv, vRO

Application Continuity:

  • Multi-DC deployments with Cross VC NSX enhancements for security tags
  • Operations enhancements with improved availability
  • L2VPN performance enhancements for cross DC/Cloud Connectivity

Where does NSX-T Fit:

Given there was some confusion about NSX-v vs. NSX-t in terms of everything going to a common code base starting from the transformers release it was highlighted that VMware’s primary focus for 2017 hasn’t shifted away from NSX for vSphere and will still be heavily invested in to add new capabilities in and beyond 6.3 and that there will be a robust roadmap of new capabilities in future releases with support extended will into the future.

NSX-t’s main drivers related to new data centre and cloud architectures with more hetrogeneality driving a different set of requirements to that of vSphere that focuses around multi-domain environments leading to a multi-hypervisor NSX platform. NSX-t is highly extensible and will address more endpoint heterogeneity in future releases including containers, public clouds and other hypervisors. As you can see before the existing use cases for NSX-t are mainly focused around devops, micro-segmentation and multi-tenant infrastructure.

NSX-T 1.1 Brief Overview:

Again the focus is around private IaaS and multi-hypervisor support for development teams using dev clouds and employing more devops methodologies. There isn’t too much to write home about in the 1.1.0 release but there is some extended hypervisor support for KVM and ESXi, more single or multi-tenant support and some performance and resiliency optimizations.

Conclusion:

There is a lot to like about where VMware is taking NSX and both product streams offer strong network virtualization capabilities for customers to take advantage of. There is no doubt in my mind that the release of NSX-v 6.3 will continue to build on the great foundation laid by the previous NSX versions. When the release notes are made available I will do take a deeper look into all the new features and enhancements and tie them into what’s most useful for service providers.

« Older Entries