Objective 4.3 – Upgrade an existing vCNS/NSX Deployment

Principles

  • Based on a given upgrade scenario, identify requisite steps and components for upgrading to NSX 6.x
  • Upgrade vCNS 5.5 to NSX 6.x
  • Upgrade vCNS Virtual Wires to NSX Logical Switches
  • Upgrade to NSX Components
  • Upgrade to NSX Firewall
  • Upgrade to NSX Edge
  • Upgrade vShield Endpoint from 5.5 to 6.x
  • Upgrade to NSX Data Security
  • Upgrade NSX Manager from 6.0 to 6.x
  • Update vSphere Clusters after NSX upgrade
  • Understand the impact of availability to the aspects of NSX during an upgrade

References

  • NSX Administration Guide

http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_admin.pdf

  • NSX Installation Guide

https://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_install.pdf

  • NSX Upgrade Guide

https://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_upgrade.pdf

Based on a given upgrade scenario, identify requisite steps and components for upgrading to NSX 6.x

Deployment upgrade process flow:

  1. NSX Manager
  2. NSX Controllers
  3. NSX Host Clusters
  4. NSX Edges

Thigs to consider

  1. Downgrades are not supported
  2. Perform a backup of the current configuration through the NSX Manager UI
  3. Verify vSphere and ESXi hosts meet interoperability requirements for upgrade
  4. Check Guest Introspection services compatibility
  5. Remove Data Security before upgrading
  6. Take a snapshot the NSX Manager
  7. Create an NSX Tech-Support log bundle
  8. Check forward and reverse name resolutions
  9. Ensure the bypassVumEnabled flag is set to true in vCenter (if configured)
  10. Check license requirements

Upgrade vCNS 5.5 to NSX 6.x

Preparation

  • vCNS must be at v5.5 before upgrade
  • Check any installed vCNS partner services are compatible with NSX
  • Uninstall Data Security
  • Migrate networks from Nexus 1000v to vDS
  • Upon upgrade vCNS license is converted to an NSX for vShield Endpoint license
    • Default licence from NSX 6.2.3 onwards
    • Allows the deployment of vShield Endpoint for anti-virus offload only
    • Host Prep, DFW, VXLAN and Edge deployment not permitted
    • Existing vCNS prepared hosts, virtual wires, vShield App and vShield Edge continue to work but no further deployment or changes possible
    • License upgrade need to utilise NSX properly

Installation Order

  1. vShield Manager to NSX Manager
  2. Deploy NSX Controller Cluster – optional
    1. Required for DLRs and changing transport control plane to Hybrid or Unicast
  3. Upgrade Clusters and Hosts
  4. Update Transport Zone – optional
    1. Only needed if NSX Controller is deployed and control plane to be changed to hybrid or unicast
    2. Edit the Transport Zone and change the replication mode to Unicast or Hybrid as desired and select the “Migrate existing Logical Switches to the new control pane”
  5. vShield App to Distributed Firewall
  6. vShield Edge to NSX Edge
  7. vShield Endpoint to NSX Guest Introspection

Upgrade vCNS Virtual Wires to NSX Logical Switches

  1. Clusters must undergo Host Preparation to install NSX VIBs and convert existing Virtual Wires to NSX Logical Switches
  2. Following Host Preparation “install” appears under Installation Status – click to convert Virtual Wires to NSX Logical Switches
  3. Virtual Wires deployed with vCNS use DHCP or Static as the IP assignment method
  4. Update VXLAN Port
    1. vCNS uses UDP 8472
    2. NSX uses UDP 4789
    3. Recommend this is updated to align with future cross-vcenter installation which requires all hosts use the same port

Upgrade to NSX Components

Upgrade to NSX Firewall

  1. Pre-requisites:
    1. vShield App version 5.5
    2. vShield Manager has been upgraded to NSX Manager
    3. Virtual Wires have been upgraded to NSX Logical Switches
  2. Do no delete vShield App until rules have been migration to DFW
  3. DFW can be upgraded from the “Host Preparation” Tab following VIB installation and VXLAN preparation
  4. A new section is created in the DFW for existing vCNS rules
  5. Existing vShield App VMs can be shutdown and then removed after the ruleset has been verified and all alarms cleared

Upgrade to NSX Edge

  1. Pre-requisites:
    1. Pre 5.5 vShield Edges cannot be managed or deleted after upgrading to NSX so upgrade them beforehand
    2. vShield Manager has been upgraded to NSX Manager
    3. A local segment ID Pool has been configured
    4. Verify sufficient hardware resources are available to support the temporary deployment of NSX Edges alongside vShield Edges
  2. New NSX Edges are deployed alongside existing vShield Edges
  3. Following installation Existing Edges are disconnected and new NSX Edges are connected
  4. New Edge sends out a GARP to update the connected switch ARP tables
  5. Packet forwarding is suspended temporarily during upgrade
  6. OSPF Adjacencies are withdrawn unless graceful restart is configured
  7. L2 VPN configurations must be deleted prior to installation
  8. Check any static routes configured on an Edge have the correct next hop assigned before starting the upgrade
  9. NSX Edge Firewall does not support Source Port so rules are modified as following during the upgrade:
    1. If no applications are used in the rule a new service is created with protocol=any, port=any, sourcePort=<existingRuleSourcePort>
    2. If applications or application groups are used in the existing rules, they are re-created with source port added
  10. Re-configure L2 VPNs

Upgrade vShield Endpoint from 5.5 to 6.x

  1. Guest Introspection VMs can be upgraded from vSphere Web Client
  2. “Upgrade Available” is shown under Service Deployments
  3. Click to upgrade and set the Datastore, Network and IP Assignment method

Upgrade to NSX Data Security

  • NSX Data Security deprecated from NSX 6.2.3
  • Can continue to be used but will be removed from future releases
  • NSX Data Security should be uninstalled before upgrade
  • Use REST API to uninstall old version if already upgraded and then redeploy Data Security

Upgrade vShield Manager from 5.5 to 6.x

  1. Do not uninstall vShield Manager
  2. Upgrade is conducted from vShield Manager
  3. Following upgrade default license “NSX for vShield Endpoint” is applied
    1. Permits NSX vShield Endpoint Deployment only
    2. Does not permit Host Preparation, VXLAN, DFW, Edges

Update vSphere Clusters after NSX upgrade

  1. Clusters must undergo Host Preparation to install NSX VIBs and convert existing Virtual Wires to NSX Logical Switches
  2. Following Host Preparation “install” appears under Installation Status – click to convert Virtual Wires to NSX Logical Switches
  3. Virtual Wires deployed with vCNS use DHCP or Static as the IP assignment method
  4. A host reboot is performed following the upgrade
  5. DRS manages the order of installation if enabled

Understand the impact of availability to the aspects of NSX during an upgrade

Order of upgrade:

  1. vShield Manager
  2. Host clusters and virtual wires
  3. vShield App
  4. vShield Edge
  5. vShield Endpoint

vCenter Upgrade

  • If upgrading from vCenter 5.5 with embedded SSO with vCenter 6.0 vShield Manager may lose connection to vCenter if registered with “root”
  • From NSX 6.2 registering with root is deprecated
  • Change vShield Manager vCenter registration to administrator@vsphere.local prior to upgrade

vShield Manager Upgrade

If upgrading to vShield Manager 5.5 prior to NSX the following applies during upgrade:

  • Configuration blocked
  • API unavailable
  • Existing VM communication continues to function
  • New VMs cannot be connected to virtual wires

All changes are permitted after upgrade is complete

Host Cluster upgrade and Virtual Wires

  • New VIBs installed on Hosts -> requires a reboot
  • Existing Virtual Wires are renamed Logical Switches
  • VMs cannot be provisioned on hosts undergoing upgrade as they will be in maintenance mode
  • DRS manages order of upgrade if configured
  • Logical Switches can continue to be provisioned during host preparation (partial upgrade)

vShield App migrated to Distributed Firewall

  • vShield App migrated to DFW during upgrade
  • Existing filters continue to work during migration
  • Do not add or modify filters during migration
  • Remove vShield App via Service Deployment page in NSX following migration

vShield Edge Upgrade

  • Can be upgraded independently of host upgrades
  • Configuration changes are blocked during upgrade and packet forwarding is halted
  • After upgrade configuration changes are not blocked but any new features introduced in NSX will be not available until Controllers are deployed and host preparation is complete
  • L2 VPN must be reconfigured after upgrade
  • SSL VPN client must be reinstalled after upgrade

vShield Endpoint migrated to Guest Introspection

  • vShield Endpoint renamed Guest Introspection in NSX 6.x
  • Go to Networking & Security -> Installation -> Service Deployments and select “Upgrade”
  • Guest Introspection virtual appliance and host agent deployed on each host
  • If VMs are modified during the upgrade protection is temporarily affected
  • Following upgrade all VMs are protected

Migrate Local Admin user to CLI Admin User

  • In NSX: prior to 6.x the “admin” user was in the local database. From 6.x it became a CLI user
  • In vCNS the cli “admin” and UI “admin” users are different
    • CLI = OS account
    • UI = vCNS (VSM) user database account
    • VSM user database deprecated from NSX 6.x
  • Following an upgrade the CLI And UI admin account is present in both the CLI And Web UI databases as separate accounts
    • In a fresh (greenfield) NSX deployment the admin account is a single entity that can be used to login to the CLI And Web UI
  • To make the upgraded environment behave as a new one either:
    • Change internal admin password with REST API call
      • Requires ongoing maintenance i.e. whenever the CLI password is changed, update the Web UI password and vice versa
    • Add super_user role to CLI admin account and remove old Web UI Admin account
      • Requires a second super_user account to be added before existing Web UI “admin” account can be removed

NSX Services that cannot be upgraded directly

  • NSX Data Security
    • Should be uninstalled before upgrade
    • Use REST API to uninstall old version if already upgraded and then redeploy Data Security
  • SSL VPN
    • NSX 6.2 only accepts TLS
    • From NSX 6.2.3 TLS 1.0 is deprecated to connections from existing clients will fail
    • Uninstall SSL VPN Clients and install the NSX 6.2.x version to enable support
  • NSX L2 VPN
    • Existing L2 VPN configurations must be deleted from vShield Edges prior to upgrade and re-created after