VMware – DefinIT

vRealize Lifecycle Manager 1.2 VC data collection fails when NSX-T hostswitches are in use

18/04/2018 by Sam Leave a Comment

When vRealize Lifecycle Manager 1.2 was released recently, I was keen to get it installed in my lab, since I maintain several vRealize Automation deployments for development and testing, as well as performing upgrades. With vRLCM I can reduce the administrative overhead of managing the environments, as well as easily migrate content between environments (I’ll be blogging on some of these cool new features soon).

However, I hit a snag when I began to import my existing environment – I couldn’t get the vCenter data collection to run.

[Read more…]

Three Tier App for vRealize Automation

26/03/2018 by Sam 3 Comments

One question I’m asked quite a lot is what I use for a 3-tier application when I’m testing things like NSX micro-segmentation with vRealize Automation. The simple answer is that I used to make something up as I went along, deploying components by hand and generally repeating myself a lot. I had some cut/paste commands in my note application that sped things up a little, but nothing that developed. I’ve been meaning to rectify this for a while, and this is the result!

A lot of this is based on the excellent blog posts published on the VMware HOL blog by Doug Baer. Doug wrote five parts on creating his application on Photon OS and they’re well worth a read (start at part 1, here). I have changed a few things for my vRA Three Tier App, and some things are the same:

I’m using CentOS7, as that’s what I see out in the wild with customers (RHEL7) and I am most familiar with
The app itself is the PHP MySQL CRUD Application from Tutorial Republic
The DB tier uses MariaDB (MySQL) not SQLite
The App tier is an Apache/PHP server
The Web tier is still NGINX as a reverse proxy
I am including NSX on-demand load balancers in my blueprint, but you don’t actually need them for single-VM tiers
Finally, I want to be able to deploy my 3-tier application using vRA Software Components (though you can also use startup scripts in the customisation spec)

Based on this, my final application will look something like the image below, with clients connecting to the NSX load balancer on HTTPS/443, multiple NGINX reverse proxy servers communicating with the NSX load balancer on HTTP/8080, which is in front of multiple Apache web servers running the PHP application which all talk to the MySQL databased back end over MySQL/3306.

When in use, the application looks like this:

[Read more…]

Retrieve Blueprint or Virtual Machine Custom Properties using the vRealize Automation API

02/02/2018 by Sam Leave a Comment

Just a quick post today, as I was working with a customer recently and we were trying to retrieve the Custom Properties assigned to a vRealize Automation 7.3 deployed Virtual Machine, similar to the one in the image below. It’s not as intuitive as you’d like it to be because of the split between IaaS APIs and Cafe APIs. Below you can see I’ve deployed a simple CentOS blueprint with a custom property at the Blueprint level (called “BlueprintLevel” with a value of “CustomProperty”) and a custom property at the VM level (called “CustomProperty” and a value of “Test123”).

[Read more…]

NSX 6.x Network Communications Diagram

26/01/2018 by Sam 1 Comment

There are a few NSX Communications network diagrams floating around, but none have really displayed the info in a way I found to be clear or complete enough. To that end, I have been working on a diagram that covers as much of the communications between NSX Components as I can. I’ve currently only covered single site NSX (not Cross vCenter) but I’ll publish an updated version soon including that.

[Read more…]

vRealize Automation 7.3 and NSX – Micro-segmentation strategies

19/01/2018 by Sam 2 Comments

vRealize Automation and NSX integration has introduced the ability to deploy multi-tiered applications with network services included. The current integration also enables a method to deploy micro-segmentation out of the box, based on dynamic Security Group membership and the Service Composer. This method does have some limitations, and can be inflexible for the on-going management of deployed applications. It requires in-depth knowledge and understanding of NSX and the Distributed Firewall, as well as access to the Networking and Security manager that is hosted by vCenter Server.

For customers who have deployed a private cloud solution using vRealize Automation, an alternative is to develop a “Firewall-as-a-Service” approach, using automation to allow authorised end users to configure micro-segmentation. This can be highly flexible, and allow the delegation of firewall management to the application owners who have intimate knowledge of the application. There are disadvantages to this approach, including significantly increased effort to author and maintain the automation workflows.

This blog post describes two possible micro-segmentation strategies for vRealize Automation with NSX and compares the two approaches against a common set of requirements.

This post was written based on the following software versions

Software Component	Version (Build)
vRealize Automation	7.3 (5604410)
NSX	6.3.5 (7119875) – 6.4
vSphere	6.5 Update 1d (7312210)
ESXi	6.5 Update 1 (5969303)

These are some generic considerations when deploying micro-segmentation with vRealize Automation.

An application blueprint is designed to be deployed multiple times from vRealize Automation, the automation shouldn’t break any micro-segmentation or firewall policy when that happens.
vRealize Automation blueprints can scale in and out – this should be accommodated within the micro-segmentation strategy to ensure that required micro-segmentation is the same as implemented micro-segmentation.
vRealize Automation is a shared platform, so the micro-segmentation of one deployment should be limited in scope, but should also consider intra-deployment communications between applications, for example, of the same business group or tenant.

Application XYZ requirements

For illustration purposes, an example 3-tier application deployment is shown below “Application XYZ“. It consists of a Web, App and DB tier and a load balancer for the Web and App tiers.

Application XYZ Allowed Flows

[Read more…]

NSX-T 2.0 Lab Build: Upgrading to NSX-T 2.1

22/12/2017 by Sam Leave a Comment

Posts in this series

Yesterday saw the release of NSX-T 2.1, with some new features and also some usability enhancements. You can check out the release notes here https://docs.vmware.com/en/VMware-NSX-T/2.1/rn/VMware-NSX-T-21-Release-Notes.html

As I’m mid-way through this blog series, I thought I’d stick in the upgrade as a little bonus!

Download the upgrade bundle

Validate the version and status of NSX-T components

Check the Controller cluster status and Manager connections are up.

Validate the hosts are installed, and have a connection to the controller and manager.

Ensure the Edges

Finaly, check that the transport nodes are all in a “Success” state

You can also validate the state of NSX-T via the command line

SSH to the controller and use “get control-cluster status verbose”

Uploading the NSX-T Upgrade bundle

Navigate to System > Utilities > Upgrade, then click the “PROCEED TO UPGRADE” button

Select the upgrade .mub file and click “UPLOAD”

Since the upgrade bundle is fairly hefty (3.7GB) the upload will take a while, and once it’s uploaded it is extracted and verified, which again takes some time

Once the package has uploaded, click to begin the upgrade. The upgrade coordinator will then check the install for any potential issues. In my environment there are two warnings for the Edges that the connectivity is degraded – this is because of the disconnected 4th VMNIC on my Edge VMs and is safe to ignore.

Click Next to view the Hosts Upgrade page. Here you can define the order and method of upgrade for each host, and define host groups to control the order of upgrade. I’ve gone with the defaults, serial (one at a time) upgrades over the parallel (up to 5 at once). All three hosts in this environment are in an automatic group for Pod200-Cluster-1. Click START to begin the upgrade, and the hosts will be put in maintenance mode, then upgraded and rebooted if necessary (a reboot shouldn’t be necessary!) Bear in mind you need to have DRS enabled and the VMs on the hosts must be able to vMotion off of the host being put in maintenance mode. Once the host has upgraded, and the MPA (Management Plane Agent) has reported back to the Manager, the Upgrade Coordinator will move on to the next host in the group.

Once the hosts are upgraded, click NEXT to move to the Edge Upgrade page

Edge Clusters can be upgraded in serial or parallel, but the Edges within are grouped by the Edge Clusters and upgraded serially to ensure connectivity is maintained. I have a single Edge Cluster with two Edge VMs, so this will be upgraded one Edge at a time. Click START to begin the upgrade, and select the Edge Cluster to view the status of the Edge VMs within the Cluster.

Once the Edge Cluster upgrades are complete, click NEXT to move to the Controllers. You can’t change the upgrade of the controllers, these are done in parallel by default. Click START to begin the upgrade – this step took by far the longest in my lab, so be patient!

Once the upgrade has completed, click NEXT to move to the NSX Manager upgrade page. The NSX Manager will become unavailable about 2-4 minutes after you click START, and may take 10-15 minutes to become available again afterwards – don’t worry about errors that come up in the meantime!

Once the Manager upgrade has completed you can re-validate the installation as I did at the start, checking that we have all the green lights, and the versions have increased.

Over the next few posts I will be exploring some the new features introduced in 2.1

One Node vSAN Lab Host

12/12/2017 by Sam Leave a Comment

A little while ago I replaced my three ageing Intel NUC hosts with a single (still ageing) Dell T7500 workstation. The workstation provides 24 processor cores and 96GB RAM for a really reasonable price, while still being quiet enough to sit in my home office. One of the driving factors in retiring the old NUCs was vSAN – I know in the newer generations of NUC you can get an M2 and a SATA SSD in, but my 1st gen. models could only do a single M2.

This new single host presents a challenge though – a single node vSAN is not a supported configuration! To get it working, we have to force vSAN to do things it doesn’t want to do. To this end, let me be very clear: this is not a supported configuration. It is not for production. Don’t do it without understanding the consequences – and don’t put data you can’t afford to lose on it. Back up everything.

Enabling vSAN on a single host

Firstly, enable vSAN on either the existing VMKernel interface, or create a new VMKernel interface for vSAN. If the host is currently standalone (and you’ll deploy vCenter to vSAN later, for example), you can use an esxcli command to “tick the box” using the VMKernel ID (e.g. vmk0):

esxcli vsan network ipv4 add -i vmk0

NewImage

Next, we need to update the default vSAN policy to allow us to use a single host vSAN. Querying the default policy via esxcli shows that the cluster, vdisk, vmnamespace, vmswap and vmem classes are all configured with a hostFailuresToTolerate (FTT) value of 1, and only vmswap and vmem are configured to forceProvisioning (that is, provision if policy is not met).

[root@t7500:~] esxcli vsan policy getdefault
Policy Class Policy Value 
------------ --------------------------------------------------------
cluster (("hostFailuresToTolerate" i1))
vdisk (("hostFailuresToTolerate" i1))
vmnamespace (("hostFailuresToTolerate" i1))
vmswap (("hostFailuresToTolerate" i0) ("forceProvisioning" i1))
vmem (("hostFailuresToTolerate" i0) ("forceProvisioning" i1))

Using esxcli we can update the policy to set the hostFailuresToTolerate to zero, which means vSAN will not attempt to replicate data to mitigate a host failure, and enable forceProvisioning on the cluster, vdisk and vmnamespace objects.

esxcli vsan policy setdefault -c cluster -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))"
esxcli vsan policy setdefault -c vdisk -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))"
esxcli vsan policy setdefault -c vmnamespace -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))"
esxcli vsan policy setdefault -c vmswap -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))"

Now, re-running the getdefault command shows the policy has updated.

From here you can create your vSAN cluster and claim the disks on the host using esxcli:

esxcli vsan cluster new
esxcli vsan vsan storage add -s <SSD identifier> -d <HDD identifier>

The vSAN storage is now available, and you can deploy your vCenter (or other VMs) to the datastore.

And finally…

If you are running a single node vSAN under vCenter, you’ll want to enable vSAN from within vCenter, and also update the default vSAN policy to match the settings:

Create vSAN One Node Policy

NSX-T 2.0 Lab Build: Transport Zones and Transport Nodes

23/10/2017 by Sam 4 Comments

Posts in this series

NSX-T 2.0 Lab Build: Deploying NSX Manager
NSX-T 2.0 Lab Build: Deploying Controller Cluster
NSX-T 2.0 Lab Build: ESXi Host Preparation
NSX-T 2.0 Lab Build: Adding a vCenter Compute Manager and Preparing Hosts
NSX-T 2.0 Lab Build: Edge Installation
NSX-T 2.0 Lab Build: Transport Zones and Transport Nodes
NST-T 2.0 Lab Build: Logical Router Configuration
NSX-T 2.0 Lab Build: Upgrading to NSX-T 2.1

Disclaimer! I am learning NSX-T, part of my learning is to deploy in my lab – if I contradict the official docs then go with the docs!

Lab Environment

This NSX-T lab environment is built as a nested lab on my physical hosts. There are four physical ESXi hosts, onto which I will deploy three ESXi VMs, a vCenter Server Appliance, NSX Manager, an NSX Controller cluster, and two NSX Edge Nodes.

Physical, virtual and nested components of the NSX-T lab

Deployment Plan

I will follow the deployment plan from the NSX-T 2.0 documentation:

Install NSX Manager.
Install NSX Controllers.
- Join NSX Controllers with the management plane.
- Initialize the control cluster to create a master controller.
- Join NSX Controllers into a control cluster.
Join hypervisor hosts with the management plane.
Install NSX Edges.
- Join NSX Edges with the management plane.
Create transport zones and transport nodes.

When this post series is complete, the network topology should be something like this, with two hostswitches configured. The ESXi Hosts will have a Tunnel Endpoint IP address, as will the Edge. The Edge will also have an interface configured for a VLAN uplink.

The NSX-T Transport Node network configuration

In this post I will walk through configuring the Transport Zone, Transport Nodes, Edge Cluster and other configuration required to support the deployment.
[Read more…]

NSX-T 2.0 Lab Build: Edge Installation

23/10/2017 by Sam 2 Comments

Posts in this series

Disclaimer! I am learning NSX-T, part of my learning is to deploy in my lab – if I contradict the official docs then go with the docs!

Lab Environment

Physical, virtual and nested components of the NSX-T lab

Deployment Plan

I will follow the deployment plan from the NSX-T 2.0 documentation:

Install NSX Manager.
Install NSX Controllers.
- Join NSX Controllers with the management plane.
- Initialize the control cluster to create a master controller.
- Join NSX Controllers into a control cluster.
Join hypervisor hosts with the management plane.
Install NSX Edges.
- Join NSX Edges with the management plane.
Create transport zones and transport nodes.

The NSX-T Transport Node network configuration

In this post I will walk through configuring the Transport Zone, Transport Nodes, Edge Cluster and other configuration required to support the deployment.
[Read more…]