Learning vSphere 6.5-Part-10-VCHA failover testing

Last 2 post of this series were revolving around the high availability feature for vCenter that is introduced in vSphere 6.5 and we discussed the VCHA architecture and also learnt how to configure VCHA.

In this post we will be testing the HA feature and will see what happens when the Active Node of VCHA cluster goes down.

If you have missed earlier post of this series, you can read them from below links:

1: Installing and Configuring Esxi

2: VCSA Overview

3: vCenter Server and PSC Deployment Types

4: System Requirements for Installing vCenter Server

5: Installing vCenter Server on Windows

6: Deploying vCSA with embedded PSC

7: Deploying External PSC for vCSA

8: Understanding vCenter Server High Availability (VCHA)

9: Configuring vCenter Server High Availability (VCHA)

Lets jump into lab and test this awesome feature.

We will be testing failover via 2 method:

  • Automated failover (let system do the magic)
  • Manual failover (user will intentionally bring down active node of VCHA cluster)

Automated Failover Testing

1: To test the failover, login to vCenter web client and navigate to Configuration > vCenter HA and before performing a failover look at the Active/Passive node info and note which IP is active at the moment.

To start failover, hit the Initiate Failover button at top right corner.


2: System will ask you that if you want to initiate the failover process and if you want to start failover immediately. If you check this box, then the recent DB changes from Active to Passive will not be replicated to Passive node.

I think it should be best to let database commit the running transactions to the passive node and because of that I chose not to check mark the immediate failover option.



3: Once failover is initiated and if you try access IP/FQDN of active node you will see below screen


4: Once the failover is completed, you will notice that the previous passive node now had become active. Compare this screenshot with screenshot shown in step 1 and you will notice the difference in IP for the active node.


5: If you click on HA monitoring tab, system will report you that all nodes are up and running and overall health status of VCHA cluster is good and application state/ DB replication etc are all in place and working fine.

So what happens in automated failover testing is that the Active node is forced to fail by system so that the Passive node will become Active and the active node will become passive once it is recovered from failed state (recovery is done by system itself)


2: Manual Failover Testing

A: To perform a manual failover testing, lets power off the Active node intentionally.


B: After few seconds of powering off the Active node, if you try to access the vCSA IP you will see message about “Failover in Progress”


c: Once the failover is completed and vSphere web client allow you to login again, you will observe that  health status of VCHA cluster is deteriorated and now you have a new active node and the previous active node had become passive and is currently down (because we have not powered on the node yet)


D: Also if you go to Monitoring tab for VCHA, you will see that system is reporting that VCHA cluster has lost one of its node and the DB replication between Active node and Passive node is not happening.  Also you will notice Application state out of sync.


At this point I hope you have understood the difference between the Automated failover test and Manual failover test and what happens when during failover.

I hope this post is informational to you. Feel free to share this on social media if it is worth sharing. Be sociable 🙂

Posted in Vmware | Leave a comment

Learning vSphere 6.5-Part-9-Configuring vCenter Server High Availability (VCHA)

In last post of this series we discussed about the High Availability feature for vCenter 6.5 and saw the architecture of VCHA and how it works. In this post we will go ahead and actually configures that in lab.

If you have missed earlier post of this series, you can read them from below links:

1: Installing and Configuring Esxi

2: VCSA Overview

3: vCenter Server and PSC Deployment Types

4: System Requirements for Installing vCenter Server

5: Installing vCenter Server on Windows

6: Deploying vCSA with embedded PSC

7: Deploying External PSC for vCSA

8: Understanding vCenter Server High Availability (VCHA)

Before jumping into lab and start configuring VCHA, its important to understand the deployment options and prerequisites  for VCHA first.

vCenter HA Deployment Options

You can set up your vCenter HA environment with an embedded PSC or with an external PSC. If you decide to use an external Platform Services Controller, you can place it behind a load balancer for protection in case of Platform Services Controller failure.

To know more about deployment option please refer  VMware documentation for vSphere 6.5

vCenter High Availability (VCHA) Prerequisites

  • An instance of the vCenter Server Appliance deployed.
  • Separate datastores to deploy all three nodes. (If possible)
  • At the least three ESXi hosts to deploy the three nodes.
  • A public IP Address that will be used to connect to the active node. (provided during the installation of the appliance).
  • Three private IP addresses (1 IP per node) for replication and internal communication called the internal cluster network.
  • Separate port group for vCenter HA network. When you configure vCenter server 6.5 HA, second vNIC  will get added (eth1) during the configuration.This vCenter HA network is used for internal communication between the vCenter HA nodes.

Network Configuration

Before proceeding with deployment ensures networking has been setup correctly. VMware recommends to have a separate network configured for VCHA traffic. To set the foundation for the vCenter HA network, you add a port group to each ESXi host, and add a new virtual NIC (eth1) to the vCenter Server Appliance that later becomes the Active node.


Requirements for vCenter HA network

  • The vCenter HA network IP addresses for the Active, Passive, and Witness nodes must be static and map to FQDNs.
  • The vCenter HA network must be on a different subnet than the management network. The three nodes can be on the same subnet or on different subnets.
  • Network latency between the Active, Passive, and Witness nodes must be less than 10 milliseconds.

Lets jump into lab and see the actual deployment process.

1: To configure vCenter HA login to the vCSA appliance and select vCenter from top and navigate to Configuration > vCenter HA and click on configure button.


2: In select configuration option you get 2 choices i.e go with Basic or Advanced option. Lets discuss a little bit about these before moving forward.

Basic Configuration Workflow

Basic configuration automatically clones the Active node. You must meet one of the following requirements to perform Basic configuration.

  • Either the vCenter Server Appliance that will become the Active node is managing its own ESXi host and its own virtual machine. This configuration is sometimes called a self-managed vCenter Server.
  • Or the vCenter Server Appliance is managed by another vCenter Server (management vCenter Server) and both vCenter Server instances are in the same vCenter Single Sign-On domain. That means they both use an external Platform Services Controller and both are running vSphere 6.5.

If you meet the requirements the Basic workflow is as follows.

1: Deploy the first vCenter Server Appliance, which will become the Active node.

2: Adds  second network (port group) for vCenter HA traffic on each ESXi host.

3: Sart the vCenter HA configuration, selects Basic and supplies the IP addresses, the target ESXi host or cluster, and the datastore for each clone.

4: The system clones the Active node and creates a Passive node with precisely the same settings, including the same host name.

5: The system clones the Active node again and creates a more light-weight Witness node.

6: The system sets up the vCenter HA network on which the three nodes communicate, for example, by exchanging heartbeats and other information.

Advanced Configuration Workflow

If you environment do not meet criteria for  Basic option or you want more control over your deployment, you can perform Advanced configuration.

With this option, you are responsible for cloning the Active node yourself as part of vCenter HA setup. If you select this option and remove the vCenter HA configuration later, you are responsible for deleting the nodes that you created.

For the Advanced option, the workflow is as follows.

1: Deploy the first vCenter Server Appliance, which will become the Active node.

2: Add a second network (port group) for vCenter HA traffic on each ESXi host.

3: Add a second network adapter (NIC) to the Active node.

4: Login to the vCenter Server Appliance (Active node) with the vSphere web client and start the vCenter HA configuration, selects Advanced, and supplies IP address and subnet information for the Passive and Witness nodes. Optionally youcan override the failover management IP addresses.

5: Login to the management vCenter Server and creates two clones of the vCenter Server Appliance (Active node).

7: Return to the configuration wizard on the vCenter Server Appliance and completes the configuration process.

8: The system sets up the vCenter HA network on which the three nodes exchange heartbeats and replication information. The vCenter Server Appliance is  now protected by vCenter HA.

In my lab I chose to go with Advanced option.


3: Provide the IP for the Passive Node and Witness node.

Note: This IP should be in different subnet than your management network to which first NIC of vCSA is connected.


4: On the clone VM page do not hit finish.

Keep this page opened until additional steps is completed.


5: Return to the management vCenter server and chose the vCSA appliance and create a clone of this VM.


6: Chose where you want to deploy the cloned VM and hit Next.


7: Select the cluster/host where you want to deploy the clone. You can chose individual Esxi host for deployment or leave the selection to cluster if you have a DRS enabled cluster.


8: Select destination datastore for cloned VM. Its recommended to keep Active, passive and Witness nodes on different datastores.


9: On select clone options page, check mark ‘customize the OS’ and ‘Power on VM’ option.


10: On customize guest os page, click the + button to create a new guest os customization specification template.


11: Provide a name for the template and hit Next.


12: Under computer name, give the same hostname which you had set on vCSA that is going to be active Node. Also provide the domain name same as Active vCSA node.


13: Ensure the timezone is consistent with the Active node.


14: Under configure Network option, select “Manually select custom settings’. Select NIC 1 and click on pencil button to edit the settings.


15: Select IPv4 and chose 3rd option and enter the IP information for the passive node.

Provide the same IP address here which you have set on management NIC (eth0) of the Active vCSA node. 

If you give any other IP address here, the VCHA deployment is going to fail.


16: For NIC 2 of the passive node, enter the same IP address which you had given in step 3.

Do not enter any gateway IP for NIC 2


17: Hit Next when you have configured both NIC cards for passive node.


18: Under DNS settings, enter Primary DNS server and in search path provide your domain name and hit Next.


19: On ready to complete page, review your settings and hit Finish.


20: Now under customize guest os page you can see the newly created customization specification template. Chose that and hit Next.

The cloned VM will take the values (which you provided in step 12-19) from this template.


21: Under customize vApp properties, review the values that is going to be applied on the cloned VM and hit next.


22: On ready to complete page, have a good look on the values again because this is best chance to modify any values that you might have supplied wrong. Once you hit finish and realize that you have missed something, then again creating a clone is the only option.

Hit finish post reviewing your settings.


23: Repeat Steps 5-22 for witness node.

24: Once both Passive and Witness node have been deployed and are up and running, go back to Active vCSA where you have to finish the HA configuration which you paused in step 4.


25: Now you will see the message on vCenter HA page that “vCenter HA is being configured”


26: Under Tasks you can monitor the status of configuration. You will see a new HA cluster being configured which comprises of your Active Node, Passive Node and Witness node.



27: Once the configuration is completed, You can see the message that vCenter HA is enabled and also can see the status of Active, passive and Witness node here.


28: Clicking on vCenter HA monitoring, will take you to the monitoring tab where you can see more details about VCHA like replication status etc. You can also monitor tasks and events or if there are any issues with VCHA config from here.


I hope this post is informational to you. Feel free to share this on social media if it is worth sharing. Be sociable 🙂

Posted in Vmware | 1 Comment

Learning vSphere 6.5-Part-8-Understanding vCenter Server High Availability (VCHA)

In last post of this series learned how to External PSC for vCSA. In this post of vSphere 6.5 series, we will look into one of the best feature which is included in v 6.5 i.e high availability for vCenter Server.

If you have missed earlier post of this series, you can read them from below links:

1: Installing and Configuring Esxi

2: VCSA Overview

3: vCenter Server and PSC Deployment Types

4: System Requirements for Installing vCenter Server

5: Installing vCenter Server on Windows

6: Deploying vCSA with embedded PSC

7: Deploying External PSC for vCSA

Customers were demanding a lot for high availability solution for vCenter Server for quite some time and VMware listened to customers and made this happen in version 6.5 of vSphere.

What is vCenter High Availability (VCHA)?

vCenter High Availability (vCenter HA) protects vCenter Server Appliance against host and hardware failures. The active-passive architecture of the solution can also help you reduce downtime significantly when you patch vCenter Server Appliance.

Note: vCenter HA is only available with vCSA and not windows based vCenter Server.

VCHA Architecture

High Availability for vCSA is achieved by creating a three-node cluster which comprises of one Active node, one Passive node, and one Witness node.

Active node is nothing but the original vCSA appliance that you deploy in your environment post deployment of external PSC. This is the primary node where you connect using the vSphere Web-Client.

The Passive Node is a clone of Active node and since this is a clone it is identical to the Active node in every aspect i.e same CPU, Memory, and disk.

The Third node is the Witness node, a lightweight node that is there to form the Cluster Quorum. Witness node is responsible to verify the heartbeat interval in order to ensure failover occurs as a result of VM unresponsiveness or a host crash.



Active & passive node share a common public ip. During the failover, passive node would activate its nic which is assigned with same public ip taking over the complete charge whenever active node fails. Rest of the time NIC status is down in order to avoid ip conflict.

All the three nodes communicate via an internal IP also called as cluster ip. These three nodes would share a same subnet in order to communicate internally.

A minimum of two nodes must be online. You cannot suffer the loss of more than one node in the VCHA cluster and expect to continue to have service.

When the active node suffers failure, the passive node becomes active and thus help minimizing downtime for the vCenter server. Below diagram illustrates the process of failover.


Note: The Witness is not capable of ever taking over the role of active and becoming a usable vCenter Server instance.

How VCHA works?

When VCHA is configured and HA cluster is formed, replication starts between the active node and the passive node. The embedded database i.e vPostgres captures the state of the appliance and info about the config.

There are two different types of replication that takes place in VCHA cluster:

File-level replication: This basically consists of all the configuration and log related data being replicated which is achieved using the mechanism known as “rsync” keeping the data upto date.

vPostgres DB replication: This is done to replicate the VCDB database and the VUM database. Database replication is needed to ensure during the failover we do not lose any changes that are being actively performed on vCenter DB.

If the active node has a failure, then the current Passive node takes on the role of the Active node. The Public IP address is switched from the Active to the Passive node and the clients now connect to the now active node, once the vCenter Services are started.


When a failover occurs, the state of replication is reversed as the former active node which is now passive (because of failure) comes back online and re-joins the VCHA Cluster and becomes active again.

Note: Replication always flows from the current active to the current passive.


I hope this post is informational to you. Feel free to share this on social media if it is worth sharing. Be sociable 🙂

Posted in Vmware | 2 Comments

Learning vSphere 6.5-Part-7-Deploying External PSC for vCSA

This is part 7 of the vSphere 6.5 learning series and in last part of this series we learned how to install vCSA with embedded PSC and touched on some basic settings which is needed to be done post deployment.

In this post we will learn how to deploy external PSC for vCSA. The goal here is to deploy external PSC first and then install vCSA which will use the external PSC.

If you have missed earlier post of this series, you can read them from below links:

1: Installing and Configuring Esxi

2: VCSA Overview

3: vCenter Server and PSC Deployment Types

4: System Requirements for Installing vCenter Server

5: Installing vCenter Server on Windows

6: Deploying vCSA with embedded PSC

In last post we discussed and saw how easy VMware has made deployment process of vCSA and the process has changed a bit. The steps needed to deploy external PSC is no different then what we learned in last post.

1: Post downloading the vCSA iso and mounting it in DVD drive, we need to navigate to  ‘vcsa-ui-installer\win32’ and click on installer exe to launch the deployment wizard.


2: The deployment wizard will tell you that installation is a 2 step process.


3: Accept EULA and hit Next.


4: Select Platform Services Controller and hit Next.


5: Select esxi host or vCenter as deployment target for PSC and provide credentials to connect to this target and hit Next.


6: Accept the SSL certificate presented to you.


7: Select folder in which you want to deploy the appliance.


8: Chose cluster/host where PSC will be deployed and hit next.


9: Chose a hostname for PSC and enter the root credentials.


10: Select destination datastore for the deployment.


11: Enter networking information for the appliance and hit Next.


12: On ready to complete page, review your settings and hit and finish to start the deployment.


13: Let the wizard do the rest for you and complete first phase of installation.



14: Hit continue post phase 1 of deployment is completed.


15: Hit Next to start configuration phase of the installation.


16: Enter NTP settings for PSC appliance and enable SSH for remote access via CLI.


17: If you have any existing SSO domain, you can make PSC part of that domain or can create a new one if don’t have any existing domain.


18: If you want to take part in customer Experience Improvement Program check mark the Join CEIP button and hit Next.


19: On final screen review your settings and hit finish to start second phase of deployment.


20: Wait for deployment to finish.



21: Login to PSC by accessing https://psc_fqdn/psc and login with user@sso-domain which you created just a while back.


22: Next is to make PSC part of your organization domain.

Under Appliance Settings click on manage tab and click on Join button to add your domain info.


23: Populate your domain info and hit OK. PSC will be rebooted for changes to take effect.


24: You can also manage additional settings related to PSC appliance by clicking on ‘View Platform Services Appliance’


25:  Login to PSC VAMI page using root credentials.


26: You can monitor the overall health of PSC fro m this page and can also configure additional settings related to Network/ NTP syslog etc.


27: Go back to PSC page and click on Configuration > Identity Source to add identity source to your PSC by clicking on ‘+’ button.


28: If you have windows based AD select AD (integrated Windows Authentication) and enter your domain information and hit OK.


There is nothing more than this to configure on PSC appliance at the moment.

I hope this post is informational to you. Feel free to share this on social media if it is worth sharing. Be sociable 🙂

Posted in Vmware | 3 Comments

Learning vSphere 6.5-Part-6-Deploying vCSA with embedded PSC

In last post of this series we learnt how to install vCenter with embedded PSC on windows server.

In this post we will learn about deploying and configuring vCSA with embedded PSC.

If you have missed earlier post of this series, you can read them from below links:

1: Installing and Configuring Esxi

2: VCSA Overview

3: vCenter Server and PSC Deployment Types

4: System Requirements for Installing vCenter Server

5: Installing vCenter Server on Windows

In vSphere 6.5 VMware has made the installation of vCenter appliance a lot easier than before. Earlier, deployment of vCSA needed client integration plugin to be installed on your system and the deployment was done through a browser. Client integration plugin had multiple compatibility issues. Now with vSphere 6.5 client integration plugin is no longer required. The deployment is going to be via an ISO which would have an installation wizard that can be executed on Windows, MAC or Linux.

The vCenter Server Appliance consists of a 2-stage deployment.
1. Deploying vCSA 6.5
2. Configuring vCSA 6.5

Since vSphere 6.5 is now GA, vCSA can be downloaded from here. Download the vCSA iso on any of the machine which can communicate with your existing virtual infrastructure and navigate to directory ‘vcsa-ui-installer\win32’ and click on installer exe to launch the deployment wizard.

1: Click on install button to start the wizard.


2: The deployment wizard will tell you that there are two steps involved in the installation. The first step will deploy a vCenter Server appliance and the second step will be configuring this deployed appliance.


3: Accept EULA and hit Next.


4: In the deployment type choose the one which suits your need. If you want to know more about available deployment type and requirements, you can read this article which I posted earlier.


5: Next is to choose the target for deployment. You can either choose Esxi host as target or any existing vCenter server. In my lab I already have a windows based vCenter server and I choose that as target.

Note: If you select Esxi host as target, provide username as root and password of Esxi host. With vCenter you can chose a windows account that have access to vCenter server.


6: Accept the thumbprint of the SSL certificate presented.


7: Select the folder where you want to deploy vCSA and hit next.


8: Chose cluster/host where vCSA will be deployed and hit next.


9: Provide a name for the vCenter appliance VM and set the root password.


10: Based upon your environment size, select the sizing of the vCenter appliance.


11: Select the destination datastore where appliance will be deployed and hit next. You can chose to deploy appliance in a thin provisioned mode by checking the box “Enable Thin Disk mode’


12: Configure the networking of vCenter appliance.  Make sure to use a valid IP which can be resolved both forward / reverse prior to this to prevent any failures during installation.


13: On ready to complete page, review your settings and hit and finish to start the deployment.


14: Let the wizard complete first phase of installation.




14: If you have chose existing vCenter as target during deployment, you can watch the deployment progress there.


16: Hit continue to begin second phase of deployment once phase 1 of deployment is completed.


17: Hit Next to start with phase 2 of deployment i.e configuring vCSA.


18: The first option that appears in phase 2 is to configure NTP  settings for the appliance and enable SSH access.


19: Next we have to define the SSO domain name, the SSO password and the Site name for the appliance.

20: If you would like to enable Client Experience Improvement Program, you can do so, else you can skip and proceed to completion.


21:  On Ready to Complete page, review your settings and hit finish to start the phase 2 of deployment.


At this point the deployment wizard gives you one more chance to review your settings by clicking cancel. Hitting OK will trigger the appliance configuration as per your selections made above.


22: You can sit back and relax now and let the wizard do the magic. It will take 5-7 minutes typically for configuration to finish.



23: Post completion of deployment, hit close. You can manage the appliance now by opening URL https://vcsa_fqdn:443/vsphere-client/


24: Login to appliance using user@sso_domain_name and password


25: On logging in, you will be presented with a warning message that your vCenter server needs to be licensed. You can go ahead and assign the license immediately or can dismiss the message if your are planning to use vCenter in evaluation mode or will apply license later.


26: The next thing you wanna configure is to make vCSA part of your company’s domain so that domain users (vsphere admins) can access vCenter using their own credentials. You can do so by clicking on “System Configuration” within home page.


27:  Select Nodes and select your vCSA and click on Manage tab. Under settings page,select Active Directory. Click on Join button to supply your domain information.


28: Define your domain name and a user using which vCSA will be attached to domain. The username is preferred to be a service account. Wizard will warn you that a reboot is required post adding vCSA to domain for changes to take effect.


29: To reboot, right click on the vCenter and select reboot.


30: If you wish you can provide a reason for why you are rebooting the appliance.


31: Post reboot of appliance, you can verify that its now joined to the domain.


32: If at this point you are hoping that you can now login to vCSA using your Active directory account, you are wrong. We have not yet finished the configuration.

Next step in this is to define the identity source for your appliance. From home page go to Administration > Configuration. Click on green ‘+’ button to add an identity source.


33: Select the identity source type. I have my domain running as AD in windows.


34: Provide the domain name here and chose use machine account and hit next.


35: Hit finish to complete adding identity source.


36: Now under Global permissions hit + button to provide access to your domain users on this vCSA instance.


37: Click on Add button to start adding the user/users and assign appropriate role to the user.


And that’s it. Now we can login to vCSA using the ad account which were added in previous step.

I hope this post is informational to you. Feel free to share this on social media if it is worth sharing. Be sociable 🙂

Posted in Vmware | 4 Comments

Learning NSX-Part-11-Replacing NSX default SSL Certficates with CA Signed Certificates

I am a big advocate of not using the default SSL certs on any VMware products and I prefer using Signed certs from my CA server on my lab components. I have my CA server running in Windows Server 2012.

Earlier in my lab I had replaced the vSphere (Esxi + vCenter) SSL certs and if you want to know how to do it, you can read them from below links:

1: Replacing Esxi SSL Certificates

2: Replacing vCenter Server SSL Certs

If you are like me and new to replacing SSL certs and looking for how to setup a CA server, you can read it from Here for a step by step installation/configuration of CA server.

1: Introduction to VMware NSX

2: Installing and Configuring NSX Manager

3: Deploying NSX Controllers

4: Preparing Esxi Hosts and Cluster

5: Configure VXLAN on the ESXi Hosts

6: Logical Switching

7: Distributed Logical Router Tidbits

8: Installing Distributed Logical Router

9: NSX Edge Services Gateway

10: Upgrade NSX Manager From 6.2 to 6.2.4

All right lets dive into lab and look into how to replace the default SSL certs of VMware NSX.

Before starting with certs replacement, we need to create a customized certificate template in CA server prior to submitting the Certificate Signing Request (CSR) created on the NSX Manager.

You can follow VMware KB-2112009 to learn how to create certificate template. I have already created mine when I replaced SSL certs in my vSphere 6 infrastructure.

1: Login to NSX manager with the admin user. At the top you can see the Red triangle sign which indicates that certificate is not a signed cert.


2: Go to Manage > SSL Certificates and click on Generate CSR


3: Populate the information needed to generate CSR and hit OK


4: Now you download the CSR by clicking on ‘Download CSR’ button.


Note: The download does not give you a .csr file but instead gives you a file with the type “File.”

5: Open the downloaded file in a notepad. It should look like below. Copy entire contents from this file including –Begin Certificate Request— and —End Certificate Request— line


6: Login to your CA server by browsing https://FQDN_or_IP/certsrv and click on “Request a certificate”


7: Click on advanced certificate request.


8: Paste the content which you copied in step 5 under Saved Request and select the correct Certificate Template and hit Submit.


9: Select Base 64 encoded and click on Download certificate chain


10: Right click on downloaded chain file and select open, then drill down to certificates directory and in right hand side you will see your cert.

Right click on the cert which corresponds to NSX and click on Export.


11: Select Base-64 encoded X.509 in Certificate Export Wizard and hit Next.


13: Save the file as .cer file on your computer.



14: Now we need to download CA Server root certificate. From the CA Server webpage click on home on right hand side upper corner and click on “Download a CA certificate” option.


15: Select Base 64 option and click on “Download CA certificate


16: At this point you should have 2 .cer files


We need to join these file to create a single .cer file. You can use below command to do that

copy nsxmgr.cer+Root64.cer  new.cer

17: Once you have the new.cer file, log back into the NSX Manager Web Interface and select Import and provide your new.cer file.


Browse to the location where you have stored your new.cer file and hit Import buttonnsx-ssl18

You should now see your new certificate and root certificate as show below. Also the NSX Web UI will display a message that appliance needs a reboot for new certs to take effect.


18: Reboot the NSX appliance. Once NSX manager is UP again, log back into the UI and you should see the certificate is now showing in green color. If its shows red eve after appliance reboot just refresh the page and you should immediately see red changing to green.



And that’s it. We have successfully replaced the default self-signed certificate of NSX manager with a signed certificate obtained from our Certificate Authority.

I hope this post is informational to you. Feel free to share this on social media if it is worth sharing. Be sociable 🙂

Posted in NSX | Leave a comment

Learning NSX-Part-10-Upgrade NSX Manager From 6.2 to 6.2.4

This week I was trying my hands on upgrading NSX to version 6.2.4 which was released earlier this year in August.

I had no experience earlier with upgrading NSX manager and associated components, so I spent a lot of time in reading blogs and watching videos on how to perform the upgrade.

Before starting with upgrade process please consult the NSX 6.2.4 Release Notes and also follow VMware KB-2144295 which explains recommended minimum versions for VMware NSX for vSphere, ESXi, vCenter Server and Guest Introspection Driver (GID).

To keep track of latest versions you can use vTracker or the Latest Versions page hosted on http://www.virten.net

You can follow the below upgrade matrix to find out the upgrade path available in your environment.


While going through the blogs on how to start upgrading NSX to 6.2.4, I came across screenshot of a cool table which Anthony has posted on his Blog.

This table gives you important info on how and when to upgrade from previous versions of NSX and also it gives a great overview of the pathways required to get to 6.2.4.


Below screenshot provides a high level overview of the upgrade procedure:


Pre Upgrade Considerations:

  1. Consult NSX release notes.
  2. Download NSX upgrade bundle and check MD5.
  3. Take backup of the NSX infrastructure. Snapshot the NSX manager VM prior to upgrade, take backup of configuration from Web-Client.

Additionally you can:

  • Take backup of vCenter Server database.
  • Snapshot vCenter Server and vCenter Server database.

To start with the upgrade process, go to the NSX download page and download the upgrade file ‘NSX for vSphere 6.2.4 Upgrade Bundle’


Verify the download upgrade bundle file name ended with tar.gz Some browser may remove the gz extension, if the file look like:


Change it to:


Lets start with upgrade process.

*******************NSX Manager Upgrade**************************

1: Login to NSX manager admin console and click on Upgrade button.


2: From the Manage page, click on upgrade button.


3: Click “Browse” and open the download upgrade file and click Continue:


4: System will take some time to upload the file.


Note: NSX Manager will reboot during upgrade process, traffic flow of existing VM workloads will not affected during this step.

5: Post upload of file you will be presented with below page. Choose if you want to enable SSH and participate in Customer Experience Improvement Program .

Click Upgrade to proceed.


6: Wait for upgrade to complete.


7: Post upgrade is complete you can verify the NSX manager version.


8: Make sure all services are running on NSX manager before proceeding with Next steps of upgrade.


*************************NSX Controller Upgrade*************************

Next part of the upgrade process is to upgrade the NSX controllers.

1: To update NSX controller cluster, login to vSphere Web Client and go to Networking&Security > Installation and Click on Upgrade Available button.


2: Click on “YES” to proceed with Controllers upgrade.


3: Wait for upgrade to complete. In my case it took more than 20 minutes to complete the upgrade process.


4: The controller nodes will be rebooted during the upgrade process. Patience is key here.


5: Post upgrade process is complete, you can verify the version.


****************************Upgrade Compute Cluster***********************

Next task in upgrade process is to upgrade NSX VIB’s on host cluster. During the upgrade cluster task, Esxi hosts requires reboot. reboot of host will not have any effect on the data planes as DRS is there to move VM around when host reboot will take place.

Important Note before proceeding with host cluster update: If you running with only 2 or 3 hosts cluster (probably in lab environment) and if you have created DRS anti-affinity rules to separate the NSX controller nodes, it will prevent DRS from evacuating VM’s off this host and thus halt host reboot process (overall upgrade will be halted).

Please disable anti-affinity rule for control cluster nodes or DLR/Edge VM’s (if you have created any).

1: To start upgrading the compute cluster, navigate to Networking & Security > Installation > Host Preparation tab and click on Upgrade available.


2: Click on ‘Yes’ to start with compute cluster upgrade.


3: On expanding the cluster you can see upgrade is in progress. In vSphere Client uninstalls and install tasks will be visible , basically process uninstalls old VIB’s and install new VIB’s.

Because old VIB’s are uninstalled, Esxi hosts needs a reboot to complete the uninstall of old VIB’s.


4: If you see Installation Status as ‘Not Ready’, click on red error and hit resolve all.


5: In vSphere Client you will see that DRS has starting migrating the VM’s, putting host in MM and reboot the host.


6: Post reboot of Esxi hosts you can see the host update is completed


***********************Upgrade DLR and ESG’s****************************

1: To update DLR/ESG’s version, navigate to Networking & Security > NSX Edges and select the DLR or ESG and right click on it and chose Upgrade version.


2: Click on ‘Yes’ to start upgrading edge version.

You get a warning that there will be service disruption. Please refer NSX documents carefully to understand the impact of the upgrade.


3: During the upgrade process new ESG VM is deployed alongside the existing one, when the new ESG is ready, old ESG vnic are disconnected and new ESG vnic’s connected.

You can see all these tasks in vCenter Inventory.


4:  Post upgrade verify that DLR/ESG status is deployed and at correct version.


I hope this post is informational to you. Feel free to share this on social media if it is worth sharing. Be sociable 🙂


Posted in NSX | 1 Comment