NSX 6.4 Released

Yesterday 16/1-2018 the new release of NSX 6.4 was Released. Here is a link to the Release Notes
There are a bunch of new features that was released and listing the top ones to me are the following:

Operations and Troubleshooting:

• Upgrade Coordinator provides a single portal to simplify the planning and execution of an NSX upgrade. Upgrade Coordinator provides a complete system view of all NSX components with current and target versions, upgrade progress meters, one-click or custom upgrade plans and pre- and post-checks.
• A new improved HTML5 dashboard is available along with many new components. Dashboard is now your default homepage. You can also customize existing system-defined widgets, and can create your own custom widgets through API.
• New System Scale dashboard collects information about the current system scale and displays the configuration maximums for the supported scale parameters. Warnings and alerts can also be configured when limits are approached or exceeded.
• New Packet Capture tab is available to capture packets through UI. If there is a host which is not in a healthy state, you can get the packet dump for that host, and administrator can examine the packet information for further debugging.
• You can now enable Controller Disconnected Operation (CDO) mode from the Management tab on the secondary site to avoid temporary connectivity issues. CDO mode ensures that the data plane connectivity is unaffected in a multi-site environment, when the primary site lose connectivity.
• API improvements including JSON support. NSX now offers the choice or JSON or XML for data formats. XML remains the default for backwards compatibility.

Security Services:

• Identity Firewall: Identity Firewall (IDFW) now supports user sessions on remote desktop and application servers (RDSH) sharing a single IP address, new “fast-path” architecture improves processing speed of IDFW rules. Active Directory integration now allows selective synchronization for faster AD updates
• Distributed Firewall: Distributed Firewall (DFW) adds layer-7 application-based context for flow control and micro-segmentation planning. Application Rule Manager (ARM) now recommends security groups and policies for a cohesive and manageable micro-segmentation strategy.

NSX Edge Enhancements:

• Enhancement to Edge load balancer health check. Three new health check monitors have been added: DNS, LDAP, and SQL.
• Improvements to L3 VPN performance and resiliency.

A look at the Upgrade Coordinator

Update NSX Manager:

I went ahead and grabbed the NSX Upgrade Bundle tar file from My Vmware portal and logged in to the NSX Manager.

I Uploaded the file and let the NSX Manager upgrade itself to 6.4

NSX 6.4 Flash, HTML5 UI

When all was done I logged in to vSphere. I checked Both the Flash and the HTML5 UIs and You are able to run the Upgrade Coordinator from both. The HTML5 is still lacking all the features for NSX Manager. But just for fun I went with the HTML5 one.

Network and Security for NSX is now viewable in VSphere HTML5 UI and selecting it will go into the NSX Manager part.

Start Upgrade Coordinator:

Now we see the all new Upgrade Coordinator and we can select to start to Plan Upgrade:

Select Upgrade Plan:

We are met with two options:

• Plan Your Upgrade
  • You can customize and manage the upgrade by choosing components
• One Click Upgrade
  • System plans and manages the entire process for you

So the difference in options you have is related to what fits your needs the most. In case you have a small NSX deployment One Click Upgrade could be an option. But incase you have a large NSX environment with several hosts clusters and alot of different NSX Edges deployed and you need better granular control then the Plan Your Upgrade option path is the way to go.

Starting of by selecting One Click Upgrade we see that there aren’t that much options more than selecting and starting the upgrade job. And then letting the system takeover the planning and scheduling of the upgrade.

I like to have a more bit controll in my environment so I went back and choose Plan Your Upgrade option:

Plan Content:

We see that we now have the option to select the components that we would like to plan to upgrade. The only option that is not possible to deselect is the upgrade of the NSX Controllers. And that is a prerequisite for to upgrade anyway before we can upgrade any of the other components.

• Controllers
• Clusters
• NSX Edges
• Service VMs

We also have two checkboxes that defines Pause Upgrade Options: These might be good to enable incase there is a failure in the upgrade process and you need to stop and troubleshoot.

• Pause between components
• Pause on Error

Plan Host Clusters:

In the next screen we plan the clusters that we intend to upgrade the Host NSX vibs and components on. Here we have the option to:

• Add
• Edit (Edit a cluster and deselect hosts that we do not intend to upgrade the vibs for)
• Delete
• Include
• Exclude
• and prioritize the clusters in order with Up and Down

Since I only have one cluster I contined with my planning to plan edges

Plan NSX Edges:

On this screen we can plan the NSX Edges we intend to upgrade in the environment. Maybe you sit in an environment for where you are not responsible to upgrade the NSX Edges or the Edges are used in productiontraffic that requires a maintenance window since you have Edges that are standalone in that environment that cannot tolerate a networkloss due to the upgrade and redeployment of that Edge appliance. Then this screen is important to make sure to exclude the edges.

Review Plan:

When the planning of the Edges are completed we proceed to the last screen to Start the Upgrade

Upgrade Status:

The upgrade has now started and we can click on View Details for the Upgrade Plan Progress to see the status for each of the components.

I also went into vSphere and checked the Controller status i the Management pane in NSX and saw that the Update was in progress.

Upgrade Paused:

Since I chose the option to pause between the components being upgrade the upgrade was paused after the Controllers was upgraded and successful.

Next step is the upgrade of the Hosts VIB components. And the Upgrade Coordinator will take care of everything here. That means taking the hosts down one by one in Maintenance Mode. Install the NSX VIBs and then continuing with the next host in the cluster until all are completed. Pretty smart!

Upgrade Complete:

All the components were now upgraded and successful.

Upgrade History:

There is also a history saved for all the upgrades that have been performed in the environment. Clicking that we can see that we have went from v 6.3.5 to 6.4 and the date when it was.

That is it I hoped you enjoyed this deepdive and walkthough of the Upgrade Coordinator.

So this post is a follow-up and somewhat related to my prevoius post regarding upgrade of NSX Controllers not retaining syslog conf.

I also noticed that the current DRS-Anti-Affinity regler are deleted when upgrading the NSX Controllers to 6.3.4. This is documented at Vmware Upgrade docs for the NSX Controllers

Important:
In NSX 6.3.3 the underlying operating system of the NSX Controller changes. This means that when you upgrade from NSX 6.3.2 or earlier to NSX 6.3.3 or later, 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.

When the controllers are deleted, this also deletes any associated DRS anti-affinity rules. You must create new anti-affinity rules in vCenter to prevent the new controller VMs from residing on the same host. VMware Docs

So with this in mind I wanted to find out how to quickly find if I did not have any Rules left and in that case recreate the Anti-Affinity rules for the NSX Controllers. And I went on creating Powershell code that I will share:

$credentials = Get-Credential
$VCenters="vcenter01"  ##### Replace with your VCenter Server Names
##A Function for Get-DRSAffinity
Function Get-DRSAffinityEverywhere {
foreach ($Vcenter in $VCenters)
    {
     Connect-VIServer $VCenters -Credential $credentials
     $Clusters= get-cluster
     foreach($Cluster in $Clusters)
         {
             Get-DrsRule -Name "*Controller*" -Cluster $Cluster | Select Name, Enabled, Type, 
                @{Name="VM"; Expression={ $iTemp = @(); $_.VMIds | % { $iTemp += (Get-VM -Id $_).Name }; 
                  [string]::Join(";", $iTemp) }} 
         }
    Disconnect-VIServer -Force $VCenters 
    }
}
$credentials = Get-Credential
$VCenters="vcenter01"

So If we where to find any Anti-Affinity Group that has the name and contains Controllers then we do not need to do anything, if now we would need to recreate the rule and add the NSX Controllers to that rule.
Get-DRSAffinityEverywhere
Name          Port       User 
----          ----       ---- 
vcenter01     443        local\vcuser

Since it was empty we now run the following script to create fetch the Cluster where the NSX Controllers are in my case it ends with 01 so I filter on that.

## Separate NSX Controllers with Anti-Affinity Rule

$credentials = Get-Credential
$VCenters="vcenter01"
Connect-VIServer $VCenters -Credential $credentials

## Get the Cluster that has name containing 01.
$cluster = GET-Cluster -Name "*01*"
$cluster

## Get the VMs that contains Controller
$antiAffinityVMs = Get-VM -Name "*Controller*"
$antiAffinityVMs

## Create a new DRS Rule that separates (KeepTogether=false) the VMs 
New-DrsRule -Cluster $cluster -Name "Separate NSX Controllers" -KeepTogether $false -VM $antiAffinityVMs
Disconnect-VIServer -Force $VCenters

We can now Run the command Get-DRSAffinityEverywhere once more to check that the VMs have been added to the Anti-Affinity Rule.

Get-DRSAffinityEverywhere

Name         Port     User 
----         ----     ---- 
vcenter01    443      local\vcuser

Name : Separate NSX Controllers
Enabled : True
Type : VMAntiAffinity
VM : NSX_Controller_0101010101;NSX_Controller_101010101;NSX_Controller_1111000001111

Or check in VMware vSphere WebClient.