Xtravirt — A view on VMware Cloud Foundation

By Ian Cook

Introduction

VMware vSphere comprises one or more virtual centre servers and multiple ESXi hosts. Virtual networking using distributed switches and NSX, and virtual storage (VSAN) can all be managed through the virtual centre server. The VMware update manager is also integrated. vSphere 6.5 comes with many features that enable customers to easily manage their private, public and hybrid cloud environments.

 Customer Background and Issues

During a recent engagement for a renowned healthcare provider, a vSphere 6.5 Cluster issue was encountered with VCSA and external PSC.

The customer’s environment is built on Cisco UCS FlexPods with FCoE (Fibre Channel over Ethernet) - all flash storage. There are two tier 3 datacentres, two VMware Virtual Centre Server appliances (one at each site) running vSphere 6.5 in enhanced linked mode. The Platform Service Controllers are external, which is a requirement for linked mode. There are six clusters, with three blades in each cluster, three clusters in each site.  

The customer was seeing numerous issues with one of the six clusters including:

1)     No management of VM’s possible (power on/off, create or delete snapshots, edit settings was greyed out on every VM)

2)     vMotion failing

3)     DRS non-functional due to vMotion failure

4)     HA wasn’t enabling/disabling correctly (one of the three hosts in the cluster would function, two would not)

5)     Unable to disconnect/connect a host from the vCenter using the GUI

6)     Tasks showing as ‘running’ in tasks on the vCenter server, but not showing as running on the host when directly connected

During troubleshooting with VMware GSS, it was discovered that the database entries for the hosts/cluster were corrupt.

The Solution

After further investigation, we identified that the problem was linked to the vCenter and not the hosts, as all of the commands could be run when connected directly to the host console. VMware GSS were engaged, and they agreed with the initial findings, that the vCenter vPostgres entries were corrupt.  The decision was made to disconnect the hosts from the vCenter and then reconnect, with the aim to refresh the agents and force the database to update. Because we could not disconnect or reconnect from the web interface, the hosts from the vCenter were forced to disconnect, using the vPostGres database commands. This was completed during a pre-planned, out of hours change window, where the fix below was applied:

1)     SSH to VCSA

2)     /opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres press <Enter>

3)     Should give VCDB=# prompt

4)     Select id,dns_name,enabled from vpx_host;

5)     Will list all hosts and the id number of the host.

6)     Update vpx_host set enabled = 0 where id = <Host ID from table above>;

7)     Response should be UPDATE 1

8)     Select id,dns_name,enabled from vpx_host;

9)     Should show the host removed with a 0 under enabled

10)  Repeat for any other hosts

11)  \q

12)  Stop vpxd – service-control –stop vmware-vpxd press <Enter>

13)  Start vpxd - service-control –start vmware-vpxd press <Enter>

14)  Refresh/log in to vSphere web client and reconnect the disconnected hosts by right click on host, Connection > Connect

 The Results

Once the fix had been applied, the cluster within the customer’s environment returned to a manageable state, with zero downtime for the customers virtual machines. The fix was also applied with zero impact to the services, resulting in the functions that would not previously work now working without fault.

 Xtravirt is a leading VMware specialist and has the ultimate combination of deep experience and agility to design and deliver IT transformations. If you need assistance in getting the best from your VMware vSphere estate, please contact us, and we’d be happy to use our wealth of knowledge and experience to assist you.

About the author

 Ian Cook joined the Xtravirt consulting team in December 2015 as a Technical Consultant. He has over 20 years’ experience in the IT industry, with an in-depth understanding of VMware Virtualisation product sets and NetApp, along with experience in data centre migration and delivery and upgrading of virtualisation solutions.

by Curtis Brown

In a time where security is top of mind, patch management for both the health and security of a VMware vSphere® estate has never been more important.

VMware vSphere® Update Manager™ is an essential, but often under-appreciated part of VMware vSphere. However, punching VMware vCenter® straight out to the internet may not be an attractive option for several reasons, most notably security, but also scaling. If you have a large estate with many vCenter servers and Update Managers, do you want all of them pulling down updates straight from VMware?

VMware Update Manager Download Service is a software solution that provides the means to place an intervening server between Update Manager (or multiple Update Manager installations) and the internet.  It can be used as a host for updates itself, or it can be configured to publish the updates on an upstream web server.

Previous releases only supported Windows, however, we can now deploy a Linux derivative, permitting a more solid appliance to be constructed.  The guidance in this article is a combination of VMware’s documentation, guidance from noted VMware blogger William Lam and my own testing.

 Installation of UMDS on Linux

The first step is to prepare a Linux server.  For this deployment, Ubuntu 14.04 was used.  Ideally, this should be provided with a static IP address for ease of use. I tested a multi-homed configuration with an external and internal connection which worked fine.

The next step is to prepare the VM for UMDS and then install it.

Install the following pre-requisite components for Linux:

• perl

• tar

• sed

• psmisc

• unixodbc

• postgresql

• postgresql-contrib

• odbc-postgresql

William Lam has a really elegant script that automates this: (http://www.virtuallyghetto.com/2016/11/automating-the-installation-of-vum-update-manager-download-service-umds-for-linux-in-vsphere-6-5.html)

Once these are in place, it creates a PostGreSQL database and sets up a local ODBC connection to it, including establishing authentication to allow UMDS to access the database.  The script creates an answer file to configure the UMDS installation prior to installing it. This is explained very well in William’s blog post referenced above.

At this point we have a UMDS server up and running, which can be confirmed by running:

/usr/local/vmware-umds/bin/vmware-umds -v

Configuration of UMDS

Once UMDS is in place, it needs to be configured.  The commands are identical to the Windows release of UMDS.

Existing configuration can be checked by running the following command:

/usr/local/vmware-umds/bin/vmware-umds -G

This will show the following:

·        Configured URLs – where UMDS is configured to pull patches down from.  We can add vendor URLs to this, but the default VMware depots are listed.

·        Patch Store location – where UMDS will download files to.  The default is /var/lib/vmware-umds.

·        Export Store Location – we can specify a remote location where UMDS can export patches to – we won’t be using this here, but vmware-umds -o [ –default-export-store] (path) can configure this.

·        Proxy Server – where needed, proxy server values can be configured using vmware-umds -p.

·        Patch Content – we can select whether to enable Host and Virtual Appliance patching and define which Host Releases we wish to support.

Let’s go through some of these, firstly deciding what content to download.

Selecting whether to enable Host or VA support is simple – we run vmware-umds with the -S option.  For example, the following will prevent download of VA patches but enable Host patches:

/usr/local/vmware-umds/bin/vmware-umds -S –enable-host –disable-va

For Host patches, we can refine which releases we wish to support.  Again, this uses the -S switch.  The example below disables ESX 5.0 patching.  To enable a release, substitute -d for a -e:

/usr/local/vmware-umds/bin/vmware-umds -S -e embeddedEsx5.0.0-INTL

Next, we might want to add third party download sources for vendor-specific patches.  Obviously, you’ll need the URL for their repository. Use –remove to remove a URL.  

/usr/local/vmware-umds/bin/vmware-umds -S –add-url https://host_URL/index.xml –url-type HOST

To select where to download to, we use:

/usr/local/vmware-umds/bin/vmware-umds -S –patch-store your_new_patchstore_folder

The default in 64-bit Windows is C:\Program Files (x86)\VMware\Infrastructure\Update Manager while the default location in 64-bit Linux is /usr/local/vmware-umds.

Running the -G command again gives us the following:

In our example, we’ve left the default configuration for the URLs and patch store, but have restricted ourselves to just ESXi 6.5 host patches.

Once all this is set as required, we need to download the patches from VMware.  The command for this is straight forward:

/usr/local/vmware-umds/bin/vmware-umds -D

This can be set up as a scheduled task in Linux by configuring crontab.  If we need to, we can re-download patches using -R and specifying a date range as per the following example.

/vmware-umds -R –start-time 2010-11-01T00:00:00 –end-time 2010-11-30T23:59:59

At this point we have a populated UMDS server. A simple listing of our UMDS patch store shows our content:

We then need to either export the content to an upstream location or host it on our UMDS server for collection by the VMware Update Manager installation.  VMware Update Manager can only use a local path or a Web Server URL as a local repository - the latter option is preferred.  If we have an upstream repository set up, we can use the **-E **command to upload the content.

We’ll focus on setting up a web server on our UMDS server.

Setting up Nginx to serve UMDS content

VMware provide this guidance as part of their validated design – and it’s relatively simple to use to provide a persistent web server.

Firstly, we install Nginx. A simple one-liner will suffice (though you’ll need the root password!)

sudo apt-get -y install nginx

Once complete, we need to allow access to our UMDS Patch Store:

sudo chmod -R 755 /var/lib/vmware-umds

Next, we copy out the default Nginx configuration file to create one for UMDS.  We then edit this using a text editor such as vi or nano – I’ll use vi:

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/umds

sudo vi /etc/nginx/sites-available/umds

The amendments we make are highlighted in green below.  We amend the root path to our UMDS patch store, add the DNS short name and Fully Qualified Domain Name, and turn on autoindexing.

**               server {**

**             listen 80 default_server;**

**             listen [::]:80 default_server ipv6only=on;**

**                       root /var/lib/vmware-umds** ;      

**             index index.html index.htm;**

**                       # Make site accessible from http://localhost/**

**             server_name localhost exampleumds exampleumds.domain.local;**

**                       location / {**

**                     # First attempt to serve request as file, then**

**                             # as directory, then fall back to displaying a 404.**

**                                            try_files $uri $uri/ =404;**

**                             # Uncomment to enable naxsi on this location**

**                             # include /etc/nginx/naxsi.rules**

**                               autoindex on;**

**             }**

We then delete the default configuration, enable our UMDS configuration and restart Nginx.

sudo rm /etc/nginx/sites-enabled/default

sudo ln -s /etc/nginx/sites-available/umds /etc/nginx/sites-enabled/

sudo service nginx restart

We should then be able to browse our UMDS patch store.

Configuring VMware Update Manager

Configuring VMware Update Manager to use a Shared Repository is a straight forward process.

From the Home Menu, select VMware Update Manager; then select the Update Manager from the Server list and go to the Settings Tab.

Pick Download Settings from the left-hand menu and select Edit Download Sources.  As per shown below, select Shared Repository and enter a URL.

VUM will validate this setting.  After that, we can download our patches into Update manager and then it’s business as usual. Set up Baselines, scan and remediate as you would do when Update Manager pulls directly from VMware.

Closing Thoughts….

With this approach, we can provide a secure gap between VMware vCenter and the internet and still retrieve updates.  One downside of the new VMware Update Manager integration with VMware vSAN in VMware vSphere 6.5 Update 1 is that vSAN requires a direct connection to VMware in order to establish vSAN Baselines.  Currently, proxying of this through UMDS is not possible, so if this functionality is required, then vCenter will still need some internet connectivity, though at least the patch downloads are segregated.

If you need assistance in getting the best from your VMware vSphere estate,  please contact Xtravirt, and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2017.

by Curtis Brown

Introduction

VMware vSAN™ is the storage component for VMware®’s Hyper-Converged Infrastructure offering. It can be deployed (albeit with its own licensing), as a part of a VMware vSphere® cluster.  The release of vSAN is generally tied to a specific release of VMware vSphere, so the 6.5 Update 1 release includes 6.6.1.

Testing VMware vSphere in a lab can be desirable for many reasons, for example training or development. However, it can be quite hardware intensive, and adding in vSAN makes matters more complicated.  To properly test vSAN, we need multiple nodes and good networking (10Gb for all-flash). However, it’s possible to use VMware Workstation (or VMware Fusion® for you Apple fans) to test this in a nested environment, where a set of virtual machines running VMware vSphere are hosted on one physical system.

One of the key features in VMware Workstation 14 (and Fusion

is the addition of Virtual Machine Hardware version 14. This is significant for this exercise, as one the features of this version is the ability to add virtual NVMe drives to Virtual Machines. This is also useful as we don’t need to mess about with the host VM or guest vSphere configuration to spoof the software into thinking it has SSDs.

What’s the Shopping list?

Well, you’re going to need a machine with a decent CPU (an Intel i7 or similar) and 32GB RAM with some fast disk (SSD).  It’s worth remembering that you’re going to be standing up quite a bit if you squeeze this in one machine. From my experience, you will need:

• 6GB RAM
  
• 2 vCPU
  
• 15GB disk (for vSphere ESXi binaries)
  
• 2 NICs
  
• For vSAN, I added a 5GB NVMe as my Cache layer and a pair of 20GB NVMe as my data tier
  

Using this toolkit, I can build out my own vSphere cluster.  In addition to this, I also use a Distributed Switch with a Management port group and a VM port group (more for tidiness than anything else).  Each host needs a VMKernel for Management (adding vMotion to this also works for efficiency) and I added a separate one purely for vSAN.

Enabling vSAN

This is pretty simple – browse through the vSphere Web Client to the Cluster, go to the Configure tab, select vSAN>General and hit Configure. This will then launch a wizard that takes you through the process of enabling vSAN.  

Feature wise, to keep the load down I didn’t enable de-duplication & compression or encryption.  So long as vSAN is enabled on a VMKernel port on each host, the network validation should be fine.

The disk claiming is spot on.  As you can see, the NVMe disks are recognised correctly as flash disks and selected for the relevant tiers based on size.

This will complete the configuration and you’ll have a vSAN:

Fixing Some Warnings…

There will be a few amber warnings that require attention.

For the simpler warnings, you’ll want to enable the Performance Service as well as update the vSAN HCL Database. If you’re not connected to the internet you can download and apply this manually using ‘update from file’.  The file can be downloaded from https://partnerweb.vmware.com/service/vsan/all.json

The remaining Amber warnings are trickier.  The first warning that you will encounter will be that the hardware isn’t on the vSAN HCL. (This shouldn’t be much of a surprise given we’re running this in Workstation.)

The second will be the vSAN Build Recommendation Engine Health component. This requires an internet connection and that the service is logged into my.vmware.com with credentials.  For a disposable lab, this is unlikely to be desirable.

These warnings can be silenced via the Ruby vCenter Console (RVC. via either SSH or the console, log on as root and access the Shell. Then log onto RVC using vCenter credentials directed at the vCenter FQDN…)

Mark a shortcut to the vSphere cluster with vSAN:

mark (vcenter FQDN)/(datacenter object)/computers/(Cluster)

To silence the given service:

vsan.health.silent_health_check_configure -a (service) ~vsan

For example:

The following services will need attention:

• vumconfig - vSAN Build Recommendation Engine Health check
  
• controllerdiskmode – Controller Disk Group Mode
  
• controllerdriver - Controller Driver is VMware Certified
• controllerfirmware - Controller firmware is VMware certified
• controllerreleasesupport - Controller is VMware certified for ESXi release
• controlleronhcl - SCSI Controller is VMware certified
  

For example, the vSAN Build Recommendation Engine Health Check:

You can use the command vsan.health.silent_health_check_status ~vsan to check the status.  -a switch can be used for specific entries.

Expanding the Cluster

If you want more nodes, then you will need to add them as additional hosts. This will allow you to test RAID5 and RAID6 Erasure Coding (four and six hosts respectively) and add capacity and performance, but you need more tin for this.

Shutting Down

To shut down the lab, you should simply:

1. Check that all re-sync operations are complete:

1. Place the hosts in Maintenance Mode with ‘No Data Evacuation’ selected and don’t move powered off VMs
   
2. Power off the hosts
   

With respect to setting up a vSAN lab, it’s “job done” – go celebrate!

If you’re interested in exploring the ways in which you can modernise your datacentre but not sure where to start, please contact Xtravirt, and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2017.

By Curtis Brown

Introduction

This little post is a ‘how to guide’ for enabling encryption on VMware vSAN.  To do this, we’ll need a few ingredients:

• A VMware vSphere 6.5 cluster with VMware vSAN enabled
  
• A Key Management Server Solution (KMS)
  

The Key Management Server (not to be mistaken for Microsoft’s license key solution) provides encryption keys for vSAN encryption.  This should be a robust solution (ideally, multiple nodes) as without this, vSAN becomes inaccessible!  Also, a tip – don’t put your KMS solution in the vSAN you’re about to encrypt, that would be a really bad idea!

In the case of the estate stood up for this blog post, HyTrust KeyControl 4.1 was deployed.  It’s an easy to use product that does exactly what’s required.

Registering the KMS in VMware vSphere

VMware vCenter supports the KMIP standard (VMware have certified a number of products) for connected KMS servers.  In the case of our HyTrust KeyControl appliance, we have to enable the KMIP server service and set the protocol to version 1.1.

We also need to set up a service User account on here.  It’s important not to set a password for this account.  We’re using certificates to authenticate and setting a password prevents vSphere from using the account with the HyTrust solution.  We download the SSL certificate for the user (this is a ZIP file containing the CA certificate and user certificate as PEM files).

Logged on as an administrator in the VMware vCenter Web Client, we open up the configuration of the vCenter server and add our KMS:

We enter a name for the cluster and the details for the first node (we can add other nodes under this cluster later).  The port is 5696 for most solutions.  

We then have to trust the certificate for the Server:

At this point, we have the configuration, but it’s yet to establish a trusted connection.  We need to establish the trust using the menu option below:

There are a few ways of achieving this (see the screenshot below), but we’ll be uploading the certificates snagged earlier:

In our case, we upload the User PEM twice:

And, voila, we’re ready to go forth and enable vSAN encryption

Enabling VMware vSAN Encryption

Here’s the easy bit.  We’ll assume that you already have vSAN up and running and will be enabling vSAN encryption.  If this is a pre-existing cluster, remember to leave room in the cluster to accommodate the emptying and reformatting of a host.  This operation will temporarily remove a host from the cluster as the disk formatting is changed.

We open the Cluster Configuration and select vSAN>General.

Edit the settings to enable Encryption.  We can erase the disks before use if we wish, but the key item is selecting the KMS server and clicking OK.  Allowing reduced redundancy reduces the number of VM data moves while the process to encrypt is under way.

At this point the cluster will reconfigure, enabling de-duplication.  This can take a little while so be patient. And that’s it done.

Closing Thoughts

This is a relatively simple feature to enable, providing a measure of data security for little effort.

If you’re considering developing a VMware vSAN based estate and need assistance, please contact Xtravirt, and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with strengths in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2018.

By Curtis Brown

Introduction

In the wonderful world of VMware based virtualisation, there has been a concerted effort in recent years to not just virtualise the compute side of matters but expand out into networking (with VMware NSX) and the provisioning of storage (VMware vSAN). This all results in a single VMware Hyper-converged infrastructure offering.

An important factor within this is security.  VMware vSphere itself has considerable security with its small footprint, hardened hypervisor and the move towards a hardened Linux based appliance as the preferred option for the VMware vCenter management server.  VMware NSX can be argued to be a security product in and off itself – providing not only edge firewalling capabilities but per-VM based firewalling with the Distributed Firewall and support for agentless malware protection solutions with the Guest Introspection framework.

But what of VM storage? SAN solutions can offer security measures, subject to the SAN vendor, but how does this apply in a VMware vSAN environment?

There are two options available:

• VM Encryption
  
• VMware vSAN Encryption
  

Each has some pros and cons – so let’s take a look.

VM Encryption

 Fundamentally, this is the encryption of virtual machines themselves.  There are third party (and, for that matter, in-guest) encryption offerings, but we’ll focus on the built-in VM encryption capability that was released in VMware vSphere 6.5.

It’s pretty straightforward to set up, requiring only two things – the deployment of an encryption Key Management Server (compatible ones are listed here and in the Interoperability guide) and a VMware vSphere Storage Policy.  After that, apply the policy to a given VM and – hey Presto!

So, what’s the catch? The encryption works on all IO operations for the VM itself at the top level – as it’s written to the Virtual Disk. This means that all IO operations in transit are encrypted as well as at rest on the physical disk.

From a security standpoint, this is very secure, and as it’s on a per-VM basis, it’s granular – you don’t need to encrypt everything (though you could argue that this is a management overhead).  However, the downside in a vSAN environment is that the encryption occurs before de-duplication, so no space saving is possible.

There are further caveats with VM encryption to be aware of:

• The VM Snapshot ‘Capture the virtual machine memory’ function is not compatible.
  
• vSphere Fault Tolerance does not work with VM encryption.
  
• Suspending (and resuming) encrypted VMs is not supported.
  

In addition, not all vSphere integrated backup solutions can support VM level encryption.

vSAN Encryption

 VMware vSAN Encryption uses the same Key Management Server, but this time the VMware vSAN storage is itself encrypted.  It’s applied at the cluster level, so anything stored in the vSAN cluster is encrypted – no management overhead as such, but no granularity.

All data travel is in an unencrypted state – it is encrypted when the data hits the caching tier, decrypted when it is de-staged from the cache for de-duplication and writing to the data tier.  This means that data-deduplication can be applied in combination with encryption, however the down-side is that encryption is therefore limited to data at rest (i.e. written to disk) as opposed to end-to-end as would be the case for VM encryption.

As encryption is at the storage tier, it is essentially invisible to VM operations – so vSphere operations such as Fault Tolerance and snapshots are fully supported and most vSAN aware backup solutions aren’t impacted.

Comparing the options

 To compare these two options:

Closing Thoughts

 Both mechanisms have their use cases.  VM encryption is the more secure when you consider that it is capable of full end-to-end encryption.  It also benefits from being able to support traditional SAN datastores as well as vSAN. However, some VMware vSphere functionality is impaired when compared to vSAN and there is more of a management overhead.  In a modern all-flash estate, IO drops caused by encryption are negligible in both cases, so performance should not be a concern.

VM Encryption is worth considering, though it does add a layer of complexity to an estate. If the deployment of a robust KMS (Key Management Server) solution is a must, then there is configuration of the solution itself.

If you’re considering implementing or upgrading a VMware vSphere environment and data security is a concern, please contact Xtravirt, and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with strengths in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2018.

by Guilliano Bertello

** Please Note: The NSX for vSphere 6.2.3 release has been pulled from distribution. The current version available is NSX for vSphere 6.2.2. VMware is actively working towards releasing the next version to replace NSX for vSphere 6.2.3. For more information, please visit click here.**</>

On 9th June 2016 VMware released VMware NSX (for vSphere) 6.2.3. NSX is VMware’s solution to virtualising network and security for the software-defined data centre. This 6.2.3 release is considered a minor release but it does bring in a lot of enhancements. One big new feature introduced is the support for 3rd-party hardware L2 gateway integration. This is useful when migrating physical workloads into an “NSX enabled” environment (don’t forget the controllers see issue 1477280). Another key feature is the VXLAN UDP port which has changed from 8472 to 4789. I will not list all the new features (you can use the release notes for that) but will give a quick overview of new features that I consider to be the most interesting and the issues to keep an eye on.

• NSX Edge on Demand Failover: giving users the ability to run on demand failover it’s a good option not only for testing
• Edge Firewall SYN flood protection: disabled by default, can be enabled via REST call. Particularity useful when the ESG is exposed publicly on the WAN
• SNMP v2c support, for the NSX Manager, Edges and Controllers
• Global Dashboard to quickly monitor the overall health of your NSX environment
• Desired/Live location attribute is now displayed for ESGs and DLRs
• It is possible to apply a NAT rule to a vNIC interface, used to be an IP address only
• You can configure DHCP options on NSX Edges, a very useful one is 121 which allows you to inject a static route into the DHCP client
• A new license model implements the default license upon install which is “NSX for vShield Endpoint”, enabling the use of NSX for deploying and managing vShield Endpoint for anti-virus offload capability only
• Fixed issue 1456172: good to have some warnings displayed, NAT has been part of the firewall service however people tend to forget that if the firewall is disabled so is the NAT
• Fixed issue 1619570: In a large-scale DFW configuration with millions of rules and Service Composer, rule publishing may require several seconds to complete after a reboot. During this time, new rules cannot be published
• Fixed issue 1467774 whereby a route learned from an eBGP peer advertised to an iBGP in the same AS was retaining a previous (wrong) administrative distance

• Issue 1529178: Uploading a server certificate which does not include a common name returns an “internal server error” message
• Issue 1534606: Host Preparation Page fails to load when NSX Managers are running different versions
• Issue 1386874: Networking and Security Tab not displayed in vSphere Web Client
• Issue 1604506: Cannot deploy DLR without NSX Edge VM if using default gateway for static routing use case see KB 2144551
• Issue 1556924: connectivity through some of the DLR LIF’s could be affected is the VXLAN layer on the hosts is not properly configured
• Issue 1493611: L2 VPN could be configured with VLAN ID 0; the GUI will let you do so however this is not supported and traffic will not traverse the tunnel so be careful
• Issue 1474238: After vCenter upgrade, vCenter might lose connectivity with NSX when using the root embedded SSO account

About the author

By Michal Grzeszczak

OLD WORLD

The landscape of modern IT is constantly evolving and an aggressive shift towards the software defined data centre is arising. Nowadays, virtualisation of storage and networking is becoming as, or even more important than the virtualisation of compute. In this rapidly transforming realm, traditional networking and security can’t keep up with location-agnostic and application-centric workloads and even if they could, there are now simply better ways to solve the problems occurring in traditionally managed data centres. Security, agility, automation and visibility are the key areas where there is a need for new tooling. During a recent customer engagement, we faced all of these issues and to mitigate them, VMware NSX® and VMware vRealize® Network Insight™ (vRNI) were deployed in the environment.  

BACKGROUND

The customer’s main business objective is to provide IT services to a number of hospitals. Security regulations in the health care world (the likes of HIPPA) can be difficult to comply with, especially with traditional security methods such as using perimeter firewalls for east-west traffic control. The customer had an old data centre that contained both virtual and physical workloads, 200+ undocumented applications, Cisco 6500s core switches and Cisco ASA firewalls. As they were facing multiple challenges with this setup, the decision was made to engage Xtravirt to migrate to a new NSX based data centre.

CHALLENGES

The main challenge the customer had in their previous environment was application traffic visibility, namely the 200+ applications without proper documentation outlining necessary ports to be open in the firewall. The communication between the networking team and application team wasn’t as smooth as one could hope for either which created unnecessary holes in the overall security posture of the company’s IT department. Multiple DMZs from the Cisco ASA firewall did not scale well and the rule sprawl was becoming a problem. The security team was working reactively instead of pro-actively - a known issue with the traditional approach. All of these issues led to the environment becoming unmanageable.

To sum up the challenges:

• Lack of visibility of the East-West traffic - resulting in poor understanding of the application flows and complicating the security policy, therefore becoming difficult to manage.
  

• Communication breakdown between IT teams - back and forth email exchange proves time consuming and slows down the deployments or changes, identifying a need for a tool to provide a “source of truth” of what is actually happening in the environment. 
  

• Hair-Pinning to the perimeter firewalls and routers - sending traffic for inspection to the physical firewalls and routing to the core switches, even if the workloads reside on the same host. That is a waste of bandwidth. Also, latency sensitive applications might be affected. 
  

 GOALS

The customer decided to build a new data centre with NSX for micro-segmentation and vRNI for visibility and security planning. The next step was to migrate the applications from the old environment to a new one, then monitor traffic flows of the applications to create an adequate security policy.

 Goals communicated before the engagement:

• Use vRNI to monitor applications and services that are running in the current data centre to get a clear picture of the network flows before the migration of the applications to the new data centre. 
  
• Use vRNI to plan security policies for the environment based on the observed flows as opposed to the (lacking) documentation from the application team. 
  
• Design a security policy using NSX, based on the vRNI outcome. 
  
• Monitor the entire network, both virtual and physical workloads to get the full picture of what is happening in the environment. Then design an alert system using vRNI that will help with monitoring and troubleshooting. 

D-DAY

After adding Virtual Distributed Switches as Data Sources in the vRNI we watched traffic flows of the applications. With a few clicks, we were able to see all the traffic - ports, protocols, IP addresses - to and from any selected application. To define an application in the vRNI we simply specify the workloads that are relevant. Then the visual graph shows all necessary information as well as recommended firewall rules. We could export interesting data in the CSV file format readable in Excel and use that as a base for Security Rules creation. It is recommended to collect the flows of the application for some time, like a day or two, as not all the ports of the applications are used in the given moment. It could be a good idea to send a request to the DevOps team to sweep through all the functionality of the application, just to make sure all the traffic needed to be allowed in the firewall is actually there in the output graph of vRNI. By default, vRNI collects data every 5 minutes. 

Next steps involved creating a Security Policy using a distributed firewall - kernel based East-West firewall used for micro-segmentation. The decision was made to use Security Tags for all of the virtual workloads and IPsets for external ones. 

• The Security Tags allow for dynamic assignment of VMs. For example - you could create a Security Tag called “Web” and configure a Security Policy that will automatically add VMs with the name that contains “Web” to a specific Security Group. This is a useful feature as workloads quite often change IP addresses and location. We are simply shifting from network-based security to an object-based one that allows for agile and location-agnostic applications. 
  
• IPsets are sets of IP Addresses, subnets or a group of subnets that specify the scope of affected workloads for a given Security Group. In the customer’s environment, the zero-trust model was implemented which means that only necessary traffic is allowed on the Distributed Firewall and everything else is dropped. This type of design ensures maximum security. 

Next, the vRNI notification system was used for monitoring the new Data Centre. There are two types of notifications:

• System notifications, which are pre-defined. The list of notifications contains 100 of the most commonly appearing issues customers face during a deployment. For example, this could be a loss of network connection of the NSX Edge routers.  
  
• User notifications are defined by user and are very simple to set up. One can simply use a search bar to search for a specific query, for example, Change in the Application “App1” - and create a notification alert with the click of a mouse. Both System and User notifications are customisable. You can specify the severity of the alerts and tags to make searching for the problem easier and quicker, and contact recipients by email to notify a specific person or a team about an issue.  

RESULTS

Quite simply, they are spectacular. In my opinion, none of the solutions available on the market could solve the customer challenges like NSX and vRNI. All the goals were met and challenges mitigated. The customer now has a new health care compliant and scalable data centre with full visibility of both physical and virtual traffic. The customer also has a solution that is centrally managed and application-centric with an agile security policy, plus a customised notification system for monitoring and troubleshooting. 

ONE STEP AHEAD

VMware appears to be reading the future pretty well; by being flexible and adjusting to the market needs, this virtualisation pioneer managed to create a one stop shop for every IT requirement. With the acquisitions of Nicira and Arkin respectively, VMware expanded their catalogue with two extremely powerful and market changing solutions - NSX and vRNI. The first providing micro-segmentation, logical switching/routing and load balancing to name a few, and the second allowing for full visibility of physical/virtual networks and assisting in security planning. The fact that these two work together and give so many unique features is a game changer in the industry. Adding to the mix products like vSAN for storage virtualisation and vRA for automation, makes it even more interesting - all in software, all managed from your browser, location-agnostic and application-centric. This is a software defined revolution and it is happening right now. Join it and stay ahead of the game. 

Xtravirt is a leading VMware NSX specialist and has the ultimate combination of deep experience and agility to design and deliver your IT transformation. If software-defined networking is on your roadmap then contact us today.

To find out more visit: https://xtravirt.com/nsx/

About the author

Michal Grzeszczak joined the Xtravirt consulting team in September 2017. He has an in-depth understanding of NSX along with experience in software-defined networking, virtualization and data centre support.

by Curtis Brown

VMware NSX® network virtualisation platform has been around for a little while now delivering an operational model for networking that forms the foundation of the Software-Defined-Data-Centre.  It’s often associated more with server virtualisation or as a component within a Cloud Automation solution and with good reason; it’s readily able to deliver a scaled, secure environment, while providing several mechanisms to deliver advanced network functionality such as firewalling, load balancing and anti-malware protection.  However, one area where its application is frequently overlooked is in the world of End User Compute – more specifically virtual desktop infrastructure.

Wouldn’t it be nice if…

Consider a full-on Horizon deployment (though, to be fair, these components could be replaced in the most part for an element of your choice) –

•  Horizon View – This will publish Virtual Desktops in Pools, with these pools assigned to Active Directory based Groups/Users.
• App Volumes – This gives you a mechanism for delivering defined stacks of applications to the Virtual Desktops.Again, you can assign using Groups or users.
• User Environment Manager – You use this to manage environmental and application settings.

 So, you have the mechanisms in place to deliver Virtual Desktops, complete with some granular application and settings delivery.  This is all pretty good, but wouldn’t it be nice if you could provide some intelligent network capabilities too?

Finetuned Firewalling.

Now take VMware NSX - this has some nice features that you can leverage in a VDI estate.

One of the key areas of concern is hardening the estate.  There’s been a pretty big play in the NSX world around using NSX to provide segmentation – both at a macro level, separating workloads into different VXLANs on virtual switches – and at the micro level using the Distributed Firewall to provide firewall rules at the Vmnic. Both strategies can be used here.

You can also separate Pools at a macro level or a micro level if you wish to, with the latter being particularly interesting.

The Distributed Firewall can provide a great deal of flexibility when defining firewall rules and can leverage several different identifiers, including vSphere entities and Active Directory objects.  Using these, you can generate a rule bases to lock down traffic quite tightly, in conjunction with the VDI solution and application delivery mechanism.  Take this example:

You can set up a standard DFW ruleset that applies to your desktops that will prevent traffic between the virtual desktops, while still providing the core services and application support for anything required for the desktop. This means you can control LDAP traffic between the desktops and Domain Controllers or PCoIP between the desktops, the Connection Servers or direct to physical endpoints if you wish.

 With App Volumes, you can define an AppStack with several applications which may well have discrete client/server network traffic requirements.  The DFW can apply rules based upon the user logged into the desktop, so you can create and apply rules specific for these client server applications and tie them to the same Active Directory object that applies the AppStack.

 The net result is that you end up with a combined ruleset applied to a desktop that is not just tied to a broad pool, but also to discrete needs for users within the pool. This provides strict granular access based upon the needs of the desktop and the application set for the user.  And let’s remember that this is applied at the desktop’s connection to the network – not at any perimeter level.

Malware Protection

NSX also provides the ability to integrate a compatible antivirus/antimalware solution into the mix. This is not, however, limited to the more publicised Guest Introspection where virus scanning is offloaded at the hypervisor level.  NSX can also integrate with both virtual and physical appliances such as Fortigate for intrusion detection, perimeter firewalling and more.

At the Infrastructure Level

As with any VDI estate, you have the upstream infrastructure to consider, several services can be provided here too.  

Using VMware NSX Edge Gateway appliances, you can provide perimeter firewalling between networks.

For Horizon View, both Connection Servers as well as Access Gateways/Security Servers require Load Balancers, as do App Volumes Managers.  The NSX Edge appliances are capable of being configured to provide load balancing services.

Perimeter firewalling using NSX Edge can also be provided, so you can have a DMZ layer for the Security Servers/Access Gateways as well.

Generally speaking, you could deploy something like this for the Horizon View management environment:

Our external traffic accesses the estate via a pair of NSX Edge Gateways, serving as firewall and load balancer for a pair of VMware User Access Gateways.  These are configured as two-legged, tunnelling into the vSwitch beneath, where you have a dedicated NSX Edge appliance load balancing the Connection servers.  This internal load balancer is also used by internal users who connect in via an L2 bridge or NSX Edge as appropriate.

 You then deploy NSX for the Desktop blocks as well, in order to provide the previously mentioned firewalling and malware protection for a secure end-to-end solution.

Closing Thoughts…

With NSX, it’s possible to turbo-charge the security for a VDI desktop environment in a manner that can be applied regardless of the choice of broker solution – the above would work just as well in a third party VDI solution such as Citrix XenApp or, perhaps more importantly, XenDesktop, not just VMware Horizon.  The ability to dynamically set and operate firewalling on egress outside of the guest Operating System means that such firewalling cannot be tampered with from within the VDI desktop, which might be useful in environments where desktops are used with untrusted users (public kiosks for example).

If you’re interested in exploring the combination of VMware NSX network virtualisation in a VDI estate, please contact Xtravirt, and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2017.

By Curtis Brown

The somewhat anticipated release of VMware vSphere 6.7 Update 1 is now with us.  So, the burning question now is “Can I upgrade?”.  The answer is not quite as simple as a yes or no as this is always a mine field, particularly where interoperability is concerned.  My intention with this article is to save you some of the leg work with respect to investigating product interoperability.

However please note, this article doesn’t dig into hardware compatibility, or compatibility with third party products, simply because of the vast array of possible scenarios.

Compatibility with Horizon View 7

The most common starting point is VMware Horizon 7 itself.   By checking the VMware product Interoperability Matrix, we can see that the minimum release of VMware Horizon that is validated with VMware vSphere 6.7 Update 1 is the latest release, 7.6.

VMware Horizon 7.6 - COMPATIBLE

VMware App Volumes

VMware App Volumes 2.14 and the more recent patch release are both listed as a valid configuration.  This would also be the recommended release for use with VMware Horizon 7.6, although it has quite a generous level of backward compatibility.

One observation of note is that the poorly adopted cul-de-sac release 3.0 product has not been validated against 6.7, but as this was explicitly incompatible with 6.5, so this is not particularly surprising.

VMware App Volumes 2.14.2 - COMPATIBLE

VMware vRealize Operations for Horizon

With respect to VMware vRealize Operations support in general, release 6.6.1 or later is required.  This is driven by vSphere rather than Horizon which can work with older vROps releases.

For a VMware Horizon environment running on VMware vSphere 6.7 Update 1, the VMware vRealize Operations for Horizon plugin needs to be on 6.6.0 to support VMware Horizon 7.6 to retain compatibility through to VMware vSphere.

However, care should be taken with the compatibility between the Horizon plugin and vRealize Operations itself.  As the Horizon component only supports Horizon 7.6 directly on release 6.6.0 of the plugin, the interoperability matrix dictates that VMware vRealize Operations should be running on release 6.7.

VMware vRealize Operations Manager 6.7 - COMPATIBLE
VMware vRealize Operations for Horizon 6.6 - COMPATIBLE

Of course, for features, guest operating system compatibility, the latest version is recommended.

VMware User Environment Manager 9.5 - COMPATIBLE

VMware NSX for vSphere

Although not every VMware Horizon deployment uses VMware NSX, it’s included to flag a possible concern. With respect to straight VMware vSphere interoperability, VMware NSX for vSphere 6.4.2 and 6.4.3 both support for vSphere 6.7 Update 1.  However, the supported Horizon release (7.6) has yet to be validated with NSX 6.4.2 or 6.4.3.  This is  unlikely to cause an issue, and validation is likely to be only a matter of time, though it may be enough to cause a pause for thought.

VMware NSX for vSphere 6.4.3 - SUBJECT TO CONFIRMATION BY VMware REGARDING HORIZON 7.6

Upgrading Desktop Templates

With respect to upgrading templates, the back-end components should be upgraded prior to the agents within the image.  As such, upgrading this rather depends on how many change windows are being used to upgrade the above components.  In all cases, VMware have limited support for backward compatibility for agents, so there is flexibility here.  The VM templates have the following components/dependencies:

• VMware App Volumes Agent – used for registering the VM and the logged in user to App Volumes manager.
  
• VMware UEM Agent – used for managing the user persona via UEM.
  
• VMware vRealize Operations for Horizon Agent – although a version is integrated as part of the VMware Horizon Agent, for full functionality in line with the release of vRealize Operations for Horizon, the dedicated agent is recommended.
  
• VMware Horizon Agent – this is used to provide components for managing deployment, assignment and the remote desktop protocol to the desktop.  It is recommended that this is installed after VMware Tools has been upgraded.
  
• VMware Tools – required for interaction with vSphere, as well as providing optimised device drivers for the guest OS.
  
• The VM virtual hardware version – this is defined by the VMware ESXi release. Upgrading should only be carried out once VMware Tools are upgraded but can be beneficial for performance reasons.
  

Where hardware GPUs are deployed, there are further considerations.  For example, if the templates are deployed using a vDGA (Dedicated Graphics) or Nvidia vGPU configuration, further investigation into supported Nvidia drivers should be carried out.

What to upgrade first?

Where to start upgrading will be driven from your starting point, so it’s well worth looking at compatibility of the release that you’re starting at with the relevant components.

Upgrading VMware vRealize Operations and the Horizon plugin is likely to be the best starting point as this supports all the monitored components backwards for a number of releases. In addition, it is the least disruptive activity for users.

After this, updating App Volumes Managers would be the next step.

Upgrading VMware Horizon follows the order it has always followed – VMware Composer, followed by Connection Servers and Security Servers.  The recommendation, however, would be to take the time to retire any Security Servers and replace them with VMware Unified Access Gateway appliances instead.

Where deployed, VMware NSX would be next on the list..

After this, the vCenter upgrade followed by the VMware ESXi hosts should take place.  In the case of the latter, as mentioned previously, pay close attention where hardware GPUs are deployed as this may need upgraded drivers and software in-line with the vSphere release.  If vSAN is deployed, this would take place as the closing step of upgrading all the ESXi hosts in the cluster, ensuring that there is enough space to carry out such an upgrade.

With respect to the desktop templates, upgrading of components can be staged, but the supporting services must be in place first.

Closing Thoughts

Although there are a fair few items to consider, so long as the components are upgraded with consideration to each other and in the proper order, it’s possible to uplift the entire stack to support VMware vSphere 6.7 Update 1.  The only caveat is the lack of interoperability testing  between releases of VMware Horizon 7.6 and NSX 6.4, though it should be remembered that there is no direct connection between the two products and VMware have yet to actually publish test results for this combination.

If you are looking to get the best from VMware infrastructure and understand your upgrade and compatibility options, please contact us, and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He was awarded VMware vExpert 2018 and is a graduate of the VMware Advanced Architecture Course 2018.

About Xtravirt

Xtravirt are an experienced consulting firm dedicated to delivering outcomes to help customers solve their IT challenges. We design and build strategies to help customers unlock the full potential of cloud, datacentre and workspace technology.

We are the VMware Global and EMEA Professional Services partner of the year.

www.xtravirt.com

by Michal Grzeszczak

My name is Michal Grzeszczak and I am a senior consultant at Xtravirt (www.xtravirt.com), an independent cloud consulting business and VMware Master Services Competent Partner.  In this blog, I’d like to share with you my experience of L2 bridging with VMware® NSX-T Data Center and help you to understand some of the differences between NSX-T and NSX-V, as well as cover some NSX use cases.  

Customer background:

The customer is one of the leading organisations in the betting and gambling industry and have been using NSX-V for some time now. When it came to their new greenfield environment, they decided to deploy NSX-T 2.4 Data Center. This decision was largely based on the fact that NSX-T Data Center provides bridging firewalls natively for L2 software bridging, which was their main requirement. Also, given that NSX-T will be the de facto network and security virtualisation platform offered by VMware going forward, by specifying it for this environment the customer is able to future proof the deployment. 

Future upgrades are also accounted for as upgrading from NSX-T 2.4 to future NSX-T releases is simpler than performing upgrades from a previous version of V or T.

NSX-T 2.4 was a major update and brought many changes to the architecture of the product, the main ones being:

• The NSX Manager and NSX Controllers were merged into one appliance deployed in a Cluster of 3 Nodes therefore minimising the footprint of the solution and operational complexity. 
• The other major change was the introduction of the new Simplified UI which “requires just the bare minimum of user input, offering strong default values with prescriptive guidance for ease of use. This means fewer clicks and page hops are required to complete configuration tasks.”

NOTE: In NSX 2.4 two UIs are presented - one is the new Simplified UI, the other one is Advanced. The latter is taken from NSX-T 2.3. The future plan is to remove the Advanced UI and provide all of the functionality via the Simplified UI.

 What are the key benefits of choosing NSX-T over NSX-V?

 There are many benefits of NSX-T over NSX-V, to name a few:

• NSX-T doesn’t require vCenter, however it can be added to NSX-T as a Compute Manager and allows for up to 16 Compute Managers per NSX 2.4 solution . There is no longer a 1:1 requirement like there was with NSX-V. 
• KVM Hypervisor support
• Bare Metal Edges provide sub-second failover 
• Data Plane Development Kit (DPDK) Optimising Forwarding - DPDK is a set of data plane libraries and network interface controller drivers for fast packet processing
• New, more flexible Overlay technology - Geneve replaces     VXLAN  https://docs.vmware.com/en/VMware-Validated-Design/4.3/com.vmware.vvd.sddc-nsxt-design.doc/GUID-CF3C47CA-9BEB-4213-8F08-1494261BF3EC.html 
• Bi-directional Forwarding Detection support
• BGP (Border Gateway Protocol) expanded functionality with features like Route Maps
• Much clearer User Interface (UI)

What were the specific use cases for this case customer and the design considerations?

USE CASE 1 - NSX-T Edge L2 Bridging - Integration of physical, non-virtualised database servers that require L2 connectivity to the virtualised environment. 

Design considerations:

• In NSX-T 2.4 two options are possible to bridge L2 workloads - using ESXi Bridge Clusters or Edge Bridge Profiles. The latter is recommended to use as the former will be deprecated in future. 
• Ideally the use of dedicated Bare Metal Edges, however this is not a requirement. 
• The possibility to deploy Edge Bridges in collapsed vSphere Clusters >     Management + Edge or Compute + Edge
• Consider having active and standby Edge Nodes on different hosts to avoid throughput drop, because VLAN traffic needs to be forwarded to both Edge Nodes in promiscuous mode.
• Overlay traffic can be tagged on a Distributed Port Group or Uplink Profile, but please avoid double tagging. 
• VLAN traffic should not be tagged on the Uplink Profile.
• Distributed Port Group for VLAN traffic connecting to the Edge Node should be in a Trunk Mode. The reason for this is due to the fact that Edge doing Bridging adds 802.1Q tag when transposing Overlay traffic to VLAN. 
• Consider having the same MTU value across your environment - if you can, choose MTU of 9000 for better performance. 
• Several Bridge Profiles can be configured, and a given Edge can belong to several Bridge Profiles. By creating two separate Bridge Profiles, alternating active and backup Edge in the configuration, the user can easily make sure that two Edge nodes simultaneously bridge traffic between Overlay and VLAN

Constraints:

• Edge Cluster with minimum 2 Edge Nodes in Active/Standby mode is needed.
• Standby uplinks are not supported on the Edge Node.
• Source Based Load Based Teaming is not supported on the Edge Node.
• The port group on the VSS/VDS sending and receiving traffic on the VLAN side should be in promiscuous mode, allowing MAC Address changes and Forge Transmits.

Deployment:

• Follow the deployment guide here - https://youtu.be/IwpujflzJhY 
• Or here https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.3/com.vmware.nsxt.admin.doc/GUID-7B21DF3D-C9DB-4C10-A32F-B16642266538.html 

Validation:

• Log in to the Edge Node with your credentials.
• Type “nsxcli”.
• “Get l2bridge-ports-config” will show the Bridge Port State (Active Edge will have Forwarding, Standby will have Stopped), VLAN ID configured and Bridge UUID which can be copied and used to do a packet capture on the Edge Node.
• To do the packet capture type “start capture interface “copied Bridge UUID” and hit enter, ping from VM to Physical Server to see the flows. 

USE CASE 2 - NSX bridging firewall - Secure communication between physical database servers and Overlay workloads.

• The configuration of the bridging firewall can be done currently only on the Advanced UI.
• Security rules are configured per Logical Switch aka Segment in Simplified UI. 
• NSX-T grouping objects like NSGroups can be used to provide abstraction from the IP based approach.

USE CASE 3 - vRealize Network Insight - Monitoring tool that can provide visibility into both Physical and Virtual environments. 

• NSX-T 2.4 is fully supported with the latest vRealize Network Insight version 4.1.
• Make sure you are allowing ports for communication between vRNI and other devices after the deployment. For example, ESXi Hosts to vRNI Collector on UDP 2055. The full list of ports needed can be found here - https://docs.vmware.com/en/VMware-vRealize-Network-Insight/3.9/com.vmware.vrni.install.doc/GUID-FDDA5F2F-7C3B-472A-A17D-39582FBD5996.html 
• There is a new website that provides in-depth information about new features in vRNI, definitely worth visiting - https://vrealize.vmware.com/t/vmware-network-management/  

What were the outcomes?

Overall, this deployment was a complete success as we were able to satisfy all of the requirements that the customer had. All the production physical databases were able to communicate on the same L2 segments, virtualised and connected to NSX-T segments workloads. On top of that, communication between those workloads was secured by NSX-T Bridging Firewall. vRealize Network Insight was used to provide visibility into the environment. Its ability to quickly troubleshoot network and firewall related issues in both virtual and physical realms allows admins to take a breath in the never-ending battle of making the networks stable.

I hope you enjoyed my blog, if you’d like to talk to Xtravirt about your business’s networking and security requirements, then please send an email to info@xtravirt.com

Some Useful links:

You can read more about the NSX-T 2.4 release here: https://blogs.vmware.com/networkvirtualization/2019/02/introducing-nsx-t-2-4-a-landmark-release-in-the-history-of-nsx.html/