Xtravirt — NSX in an End User Compute Environment

By Michal Grzeszczak, Senior Consultant, Xtravirt

As a Senior Consultant at Xtravirt, I recently spent time with a customer, a major European airline, to plan and oversee the deployment of VMware NSX^®.

In the aviation industry, a data breach could have catastrophic repercussions.  Concerned about data security, the customer chose VMware NSX for its security capabilities.  This is because NSX allows for micro-segmentation, a practice through which workloads are individually cordoned off to prevent any East-West movement in the event of a breach.  In contrast to most IT networks, where one firewall protects the entire perimeter, a breach in a micro-segmented network can only impact a small subset of data.

With the objective to increase environment security and control East-West traffic, the project was managed in five key phases:

Phase 1 – Discovery and Planning

Xtravirt kicked off the project with a 2-day planning workshop with key technical staff and subject matter experts.  In this phase we confirm and capture the full scope of requirements and ensure we fully understand the current environment.  This process reveals any prerequisites, potential roadblocks and validates the use case.

In this instance, the customer has two data centres, one vCenter Server (version 6.5) and uses vRealize Network Insight (vRNI) to monitor their environment.

During the initial discovery phase, it became apparent that vRealize Network Insight (vRNI) could be used to better understand East-West traffic and to map the customer’s applications to the security policy that could be provided by NSX Distributed Firewall (NSX DFW).

Both solutions, vRNI and NSX DFW, are quite unique in the market and help solve many typical problems associated with securing workloads in modern data centres. In this instance, they helped to:

- gain a better understanding of the flows of the applications, how they communicate with the outside world as well as within the application itself

- secure East-West traffic and avoid reliance on the perimeter firewall to segment those workloads.

Phase 2 – Installation and configuration of vRNI

The installation and configuration of vRNI onto the customer’s environment involved adding the “Data Sources” to the vRNI, where the data (flows) would be collected. There are many data sources supported by vRNI, including for example - vCenter, NSX-V, NSX-T, as well as third party devices like Cisco, AWS and Arista.   A list of supported solutions can be found here: https://docs.vmware.com/en/VMware-vRealize-Network-Insight/3.6/com.vmware.vrni.install.doc/GUID-4BA21C7A-18FD-4411-BFAC-CADEF0050D76.html

After adding the necessary sources, vRNI collected all the flows for a 30-day monitoring period.  Other VMware solutions such as Application Rule Manager, allow for a maximum of 7-days monitoring and provide a great option for small applications. However, vRNI’s 30-day monitoring period is especially useful when applications in the environment are particularly active during specific times, like a payroll application.

Phase 3 – Defining workloads

The next step was to define which workloads were part of which application.  In this particular case, we had 4 main requirements:

- micro-segmentation of Application “A” which consisted of 3 tiers. Each tier needed to talk to other tiers only on needed ports, thus securing flows within the application.

- micro-segmentation of Application “B” which consisted of 3 sub-applications.  The goal here was to secure traffic between sub-applications and not within each sub-application.

- mapping of the shared services (active directory, monitoring etc.) that are necessary for the applications to function properly.

- mapping of the users that need access to those applications.

As the users and shared services communicate with all applications in the environment, we started with the first two requirements.

It is very easy to create a logical application in vRNI. You simply add workloads to the tiers that make each application. In the case of Application “A”, the action was to create three tiers, each with corresponding workloads. In the case of application “B”, even when dealing with multiple applications, the process was the same as the requirement was to secure Inter-Application flows. We simply added workloads from each sub-application to the corresponding Tier in vRNI.

Phase 4 – Security planning

The next step was to go to the “Plan Security” section of vRNI and select our new logical application. That presented us with a “pizza” view of the tiers of the application, in both application cases. We then selected each tier of the pizza/application and extracted incoming and outgoing flows to a .csv file. This part of the application mapping can be done directly in vRNI.  However, due to the complexity of the applications, we needed to view these flows in an Excel sheet.

The most time-consuming part of the implementation at this point had been to map flows from vRNI to the design document section for security rules / security groups / IPSets in NSX DFW. Use of filtering options in Excel and colour coding the types of traffic allowed us to have a clear visual representation of the flows in the environment. We divided the flows into Shared Services, Inter-Application communication between applications that we were mapping, Intra-Application communication between workloads that we were mapping as well as user access.

Phase 5 – Application Mapping

Establishing communication between mapped applications and unmapped applications is the final stage. Under the scope of the engagement our role was to map 2 out of 70 applications. Our role as consultants was to ensure knowledge transfer and develop a repeatable process so the customer could complete their own application mapping.

Once the whole environment is mapped, then Security Groups / IPSets in DFW can be created for all applications.  Specific rules will be put in place to cover necessary flows between applications.

During the process of application mapping we were able to get necessary information about Shared Services and Users. The former was mapped into a separate NSX DFW section on top of all the other sections to be checked by DFW first (rules in NSX DFW are checked top to bottom). These sections will need to be constantly updated as more applications will be mapped and will require additional ports to be open to communicate with Shared Services. The latter was divided into floors, buildings and countries with corresponding IPSets to provide more controlled access. Those IPSets were added to two Security Groups - “Super Users” and “General Users” and were added to each application’s section to allow for management traffic.

Conclusion

By scoping out the project with the customer from the offset and having a clear and concise goal in place we were able to decide on the right tools for the job and move forward with minimal stumbling blocks. vRNI gave us a clearer picture of the road ahead and defined the East – West traffic that needed to be segmented and controlled to ensure that any potential data breaches could be stopped fast and with minimal leakage.

vRNI and NSX DFW created the perfect combination for a creating a market leading security solution and better still working to a planned and repeatable process made the whole operation smooth from beginning to end.

Find out more

If you would like to learn more about how Xtravirt can help you improve the security of your IT environment, contact us and we’d be happy to use our wealth of knowledge and experience to assist you.

Xtravirt (www.xtravirt.com) are the VMware Global Services Partner of the Year and have achieved the VMware Master Services Competency for Network Virtualization – a testament to our expertise in delivering NSX environments.  

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

As those of you who have the joy of supporting end-users will know (and this old techie has worn that badge of honour!), any tool that can make getting to grips with an issue easier is always welcome, particularly if it means getting your hands on the user’s desktop to see the problem in action.

So it’s welcome news that the latest release of VMware Horizon® 7.2 brings into play a fully integrated helpdesk tool, specifically for supporting VMware Horizon desktop sessions. It provides session information, as well as several remote operational abilities such as resetting sessions, remote control, logging off users etc.

Setting up Helpdesk

You don’t need to do anything fancy to install it as it’s a part of the Connection Server installation, however there are several recommended additional steps to get best use from it.

You will need to configure the Events database – this provides session information to the HelpDesk console, so it’s pretty important. To track logon events properly, a further command should be run on each Connection Server:

vdmadmin -I -timingProfiler -enable

Oh, and ensure that the VMware Horizon Agent installed in the desktop templates is also a 7.2 release – otherwise you’ll miss desktop side session information.

Getting into the Help Desk Tool

There are two ways of accessing the Helpdesk tool.  In either case, a user will require Admin access to Horizon – Inventory Admins should be sufficient for most operations.

The first option is to log into the Admin console for horizon (HTTPS://(ConnectionServer URL)/admin). Once logged in, there is a new Help Desk button in the top bar of the console – click on this to access the helpdesk tool – the credentials pass through, all Single Sign-On style!

Alternatively, you can access the console directly (via HTTPS://(ConnectionServer URL)/helpdesk) and then log on with the right credentials.

Doing Help Desk stuff.

So, once you’re all set up and logged in, you can use the tool to do all sorts of heroic Help Desk stuff. The front page offers a search function.

Punch in the name of the user, for example, “Curtis” and it’ll pull in the Active Directory credentials of the user – if the Active Directory E-mail and phone number fields are filled in, these are also displayed.

If you click on the user, you’ll get a new page with a summary of running sessions and entitlements.

Under ‘Sessions’, you’ll see the highlights of all running sessions - the green ones are connected sessions.  It’s even Cloud Pod aware – the L status refers to a session in the local Pod, and the G status refers to a session in the global Cloud Pod environment. If you then click on the Computer name, you can drill down further.

If the Agent is 7.2+, you get detailed session info, including CPU performance, memory usage and more.  Further, you can do some active tasks on the session.

You can send messages to the specific session or offer Remote Assistance.  The latter plugs into Microsoft’s Remote Assistance functionality, so this will need to be enabled and configured in the VM.

On VDI sessions (not RDS Published Desktops or Application Sessions), you can issue a restart command to the desktop – this will reboot the VM.  You can also disconnect or log off users.  The Reset function differs from Restart in that the latter is a graceful shutdown and restart – Reset should only be used if the VM has hung.

Closing Thoughts….

So, a welcome set of useful capabilities has been added to this point release – and one that focusses on supportability rather than the usual performance or user-centric capabilities.

If you’re in need of assistance with a troublesome Horizon solution or perhaps want some support upgrading or implementing a new one, 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 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 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 Curtis Brown

Introduction

As a highly respected, award winning VMware partner, Xtravirt has had the opportunity to send consultants on VMware’s Advanced Architecture Course at their headquarters in Palo Alto.  The first two consultants attended earlier this year, and I got my opportunity in September 2018.

This article (a somewhat non-technical one) describes the purpose of the course and my experience attending it.

What is the Advanced Architecture Course?

VMware have always been a technology company.  As the product portfolio has grown outwards far beyond the original hypervisor product, VMware have realised that while the technology is perfectly good, what is more important is the purpose to which the technology is applied.

Often, solutions get purchased (or for that matter, sold) based purely on the technology and its capabilities.  This rather misses the more important point of ‘what benefit will this solution be to the business and why should we use it?’  As such, in the worst cases, such acquisitions can end up as ‘shelf-ware’ – acquired, tested but ultimately deemed of little value and not used.  This is harmful to the customer and, significantly, harmful to how VMware is perceived by the customer.

The Advanced Architecture Course is a product of VMware’s desire to change the emphasis to being business needs driven.  The course aims to take experienced consultants and architects and provide them with a business needs oriented approach to discovering requirements and proposing solutions to meet those requirements.  A key part of this involves educating consultants on how to present to C level executives – all of which is quite a departure from the comfort zone for technically focused consultants.

My Adventures in Palo Alto

I’ll gloss over the journey out there (which was quite an adventure in itself – avoiding Hurricane Florence, almost missing a connection and losing a suitcase…) and focus on the course itself.

The course was a nine-day affair and to pass the course as a whole, we had to accrue a score of greater than 70% on all the objectives.  This included points for the pre-course online study (on matters ranging from ITIL and TOGAF through to VMware Workspace ONE), points for passing the end of day tests on content and the final presentation – which I’ll describe later.

It all started early on a sunny California Monday morning (at 7am!).  The first day focussed on VMware’s model for developing a business’ journey from basic virtualisation through to hybrid cloud and microservices as well as their model describing application of Digital Workspace technologies to business.  The approach consciously avoids specific products – so, for example, for Digital workspace, it describes the journey from traditional identity management through multi-factor authentication to single-sign-on.

Day 2 focused on the importance of requirements gathering, but broadening from just the traditional technical viewpoint outwards to business requirements – ‘we need to increase business revenue by… ’.  The importance of adapting the operating processes as well as IT were emphasised on Day 3.  A key message was that technology is only a part of the solution, without adapting to accommodate new abilities, those new abilities will still be hog-tied by legacy approaches to new needs.

We then had a particularly interesting day being taught presentation techniques, covering presenting to large audiences, conflict resolution and useful tips and tricks.

From here on out, the focus was on new technology, but with a business as a driver slant.  It’s not possible to replay much of the course content here for non-disclosure reasons, though, again, the idea was to broaden the knowledge of consultants.  As such, the breadth of technical areas covered was vast.  It included Cloud and DevOps, through network virtualisation and End User Compute to emerging solutions such as serverless computing, app containerization and Kubernetes.

The final day, although the briefest was the most challenging.  At the beginning of the course, the attendees were broken down into groups and given a case study.  From this, the groups had to work out a requirements matrix and put together a 20-minute final presentation (plus 10 minutes of questions) covering requirements, conceptual and logical design for a global solution encompassing both Software Defined Data Centre and End User Compute technologies.  This led to many long days putting in additional hours throughout the two weeks as well as some weekend work.  The presentation was to be given to a panel consisting of senior VMware staff (senior vice presidents and the likes) serving as the C-level execs of this fictional corporation.  This contributed most of the points on the course – so a pass here was important.

Fortunately, I was surrounded by thirty-seven of the smartest consultants and architects from all four corners of the world.  It was a real pleasure to work with these guys and I have to say that, despite the difficulty of the course, I wasn’t too surprised that we all passed.

Closing Thoughts

It was without doubt a tough course, intended to take the attendees out of their comfort zone to both broaden skills while also attempting to equip them for dealing with a bigger picture than just technology.  For me, it certainly has taught me a great deal, disproving the line “you can’t teach an old dog new tricks”.

Certainly, I consider myself fortunate to be working in a company that provides the opportunity to attend courses such as this.  It’s an investment for the company, of course, but one that ultimately benefits the customer.

(The day trip up to San Francisco was rather nice too, I can recommend the calamari and chips at Pier 39…).

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 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 Curtis Brown

A brief update

Following my visit to VMworld Europe in 2017 I wrote a blog post on VMware Horizon Cloud on Azure. Much has changed in a year, so it seems rather timely, given that VMworld Europe 2018 has just concluded, that I update the blog.

Where we were….

Going back a year to 2017, VMware Horizon Cloud on Azure had only just launched and at the time, it was capable of publishing full clones of Remote Desktop Session Host servers for publishing Shared Desktops and applications.  A pretty good start, all things considered, albeit slightly functionally limited compared to the VMware Hosted offering that could also offer dedicated VDI desktops.

A year on, where are we now?

Things have definitely moved on in the last year.  Not only is feature-parity between Azure and VMware Hosted offerings somewhat closer, but in one area, graphics, the Azure offering is actually superior!

Deployment

The deployment model has remained the same – you bring your own Azure subscription rather than lean on VMware for the hosting.  In this sense, it is still the case that a cost/benefit analysis needs to be undertaken

The cost of deploying Horizon VMs on Azure can be more expensive when compared to the VMware hosted offering.  To be fair, Azure is more oriented towards a server offering than desktops, so perhaps this shouldn’t be too much of a surprise.  To counterbalance this however, one must also consider connectivity in the equation.  If you already have an established Azure tenant with backhaul connectivity to on-site, then deploying VMware Hosted with its own connectivity overhead may counter the VM costs to a degree – certainly, the operational upkeep of additional environments and connectivity is a consideration.

An additional point to consider may be functionality.  From a deployment perspective, Horizon Cloud on Azure is now starting to offer dedicated and floating full desktops, not just shared.  However, at present, Instant Clones are not supported so deployment is limited to essentially persistent desktops.

Features

There is, as yet, no support for VMware App Volumes AppStacks in Horizon Cloud, so legacy deployment mechanisms will need to be considered.  As desktops are currently persistent in nature, legacy tooling such as Microsoft System Center Configuration Manager remain viable in this sense, though streaming application virtualisation tools such as VMware ThinApp and Microsoft App-V would be attractive too.

One feature that stands out over Hosted Horizon Cloud is that Azure offers enhanced graphics using Nvidia vGPU technology.  So, if you have a need for graphically intensive workloads in the Cloud, then Azure is currently the better choice.

Otherwise, with respect to connectivity protocols, management interfaces and other functionality such as the Skype for Business Virtualization Pack, the two offerings are now aligned.

What about VMware Cloud on AWS with Horizon?

VMware and Amazon Web Services have joined up to offer their VMware Cloud on AWS solution.  This allows customers to deploy a full VMware vSphere infrastructure in AWS data centers.  On top of that, it is possible to deploy VMware Horizon, so in a sense there is now a third Cloud desktop offering.

VMware consider this as an IaaS solution with desktops on, rather than a Desktop-as-a-Service offering as the customer has to look after the management tier of Horizon here, as opposed to Horizon Cloud.

The million-dollar question is - which is best? Well, there’s no easy answer to that.  Functionality wise, Horizon View has been around longer, has far greater scalability and the ability to federate multiple instances for greater resilience.  In an on-prem capacity, vGPU is supported, however this has yet to reach AWS.  The economics are more complex too given the different acquisition model involved.

There are a considerable number of use-cases where Horizon on VMware Cloud on AWS makes much more sense. For example, you have an on-prem VDI (and other services) that you wish to provide an instantaneous Cloud based DR or scaling offering, this is much more seamless and flexible than Horizon Cloud.

Closing Thoughts….

While the choice between on premises and then several cloud offerings is undoubtedly great, never has it been more apparent that an analysis prior to deciding is not just a ‘nice to have’ but a necessity.  The wrong decision can have expensive repercussions.  Such an analysis needs to consider:

• The business needs:
  

1. How does the business function currently and what are the issues to address?
   
2. How will a given solution benefit the business?
   

• Technology needs:
  

1. Compatibility with the existing environment
   
2. What connectivity do I have, and what will I need?
   
3. What resilience and security features are required?
   

• User needs:
  

1. Where are the users working?
   
2. What devices do they use and how do we manage them?
   
3. What and where are application services that users need?
   

For some customers, on-premises will remain the best approach to VDI, while others may benefit from the VMware Cloud on AWS approach offering both hybridity and flexibility and yet more may find a Desktop-as-a-Service the suitable answer.

Horizon Cloud on Azure has evolved rapidly and offers a convincing use case for customers who can gain a tangible benefit from it, but it’s not suitable in all cases.  If you need a DaaS solution and have Azure already or have graphical requirements that can’t be met in Horizon Cloud Hosted, then this might be your answer. But consider all possibilities and use cases before committing.

If you’re considering a VDI solution or digital workspace transformation, whether Cloud or On-Premises, we can help. We provide advisory, design and implementation services to create the right solution for your organisation. 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 Curtis Brown

Introduction

VMware PowerCLI has been in existence for quite some time and over the last 2 years it has been moving at quite a rapid pace.  It has traditionally been used to provide PowerShell based command and control functionality within VMware vSphere environments, with particular focus on the ability to create scripted functions for automation purposes.  Used in conjunction with automation and orchestration tooling, a great many bespoke capabilities are available.

During 2018, there has been a release around every 2 months, the current release, version 11 was released in October and provides support for the following:

• vSphere 6.7U1
  
• VMware Horizon 7.6
  
• NSX-T 2.3
  
• VMware Cloud on AWS
  

Being based on PowerShell, it is also compatible with third party modules, such as those administering Active Directory, to provide an integrated solution across a wide range of products.

In this blog, I look at PowerCLI’s ability to support VMware Horizon.

Installing VMware PowerCLI

Installing PowerCLI was once a case of downloading an installer from the VMware Portal and installing the components.  However, PowerCLI is now published from the PowerShell Gallery on the internet (https://www.powershellgallery.com/packages/VMware.PowerCLI/11.0.0.10380590) permitting installation on a connected PC straight from the PowerShell interface, simply by running:

Install-Module -Name VMware.PowerCLI

You might get something like this (accept the default):

Then it’ll install…

To allow execution of local scripts:

Set-ExecutionPolicy RemoteSigned

Then, run the following to confirm it’s all installed successfully.

Once installed, it’s worth configuring the Customer Experience Program participation by Enabling or Disabling this (It stops nag messages).

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $true $false

After that, the basic PowerCLI is ready to go.

What can we do for Horizon?

‘Out of the box’, PowerCLI only provides  the ability to connect or disconnect to the Connection Server, so providing a conduit for accessing the Horizon APIs.  To connect to Horizon Connection Server:

Connect-HVServer -Server connectionserverFQDN -user adminuser@domain -Password XXXX

However, VMware maintain example scripts at https://github.com/vmware/PowerCLI-Example-Scripts that can be used as a basis for automation of Horizon and the other supported components.  

By downloading the scripts as a ZIP file, it is possible to install them.  First, check $env:PSModulePath to locate the modules directory paths (usually, there’s the user specific path, plus system ones)

For Horizon, we extract VMware.hv.helper from the ZIP and drop this into C:\Program Files\WindowsPowerShell\Modules.

In PowerShell, we then unblock the newly exported folder by running

dir ‘C:\Program Files\WindowsPowerShell\Modules\VMware.Hv.Helper\’ | Unblock-File

With this in place, we can now use a whole raft of useful PowerShell commands (they can be listed by using Get-Command -Module ‘VMware.Hv.Helper’). These can be used for automation of tasks and generating reports.

For example, Get-HVPoolSummary will list configured pools, including their type, assignment type and status:

And we can see how many VMs are available:

Get-HVHealth shows a basic status:

By leveraging the ‘New‘ and ‘Remove’ commands, it is possible to provision and destroy new Pools (desktops and applications), entitlements, RDS Farms and Cloud Pod objects such as Sites and Entitlements.  For Example, setting up Shared Desktop pool ‘Teachers 1’:

Closing Thoughts

What we have here is a set of powerful tools that are not just capable of managing the VMware vSphere infrastructure, but can also expand into the realm of delivering desktop pools – all from scripting and automation.  For example, it would be possible to create a script that would leverage PowerShell to create an Active Directory Group and populate it, then create a desktop pool and grant the members of the group access to it.  Further, this could be used in concert with vRealize Automation and Orchestration to provide a portal for self service requests for generating desktop pools and services.

Given that the current release supports VMware Cloud on AWS as well as VMware Horizon, this offers the tantalizing prospect of being able to programmatically manage a federated on-prem and AWS hosted Horizon Cloud Pod Architecture.  The sky is the limit!

If you’re planning to deploy a Virtual Desktop solution, we can help. Xtravirt provide design and implementation services to create the right solution for your organisation. 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 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/